Skip to content

Case study · LeafConnect

A shop that repairs itself.

A trilingual online shop in a regulated retail sector, built as a headless web application on Next.js and run as a Cloudflare Worker. The real case begins after launch: automations fix errors with a mandatory test and measure every SEO change against a control group.

69automatic error fixes
112automatic changes for search engines
49 daysmeasurement window per SEO change
14 daysquiet period until “resolved”

All figures are from the period June to September 2026.

Starting point

A shop in three languages, with little room for error.

LeafConnect sells online in German, English and Czech and delivers to several countries. What is sold is deliberately not stated here: the case is approved for the name, not for the product range.

Regulated retail means that reliability and legal certainty are not goals but prerequisites. Prices, tax rates, payment methods and delivery terms must be correct in every language and every country – permanently, not only on the day of going live.

That is exactly what tied up attention. Operations and further development ran alongside. Every small error, every adjustment to a line of text, every check after an update cost time for someone who actually wanted to run the business.

Constraints

  • Three languages, several delivery countries, one codebase.
  • Payments and tax rates must be demonstrably correct at all times.
  • Outages in the checkout flow are expensive and, without monitoring, are noticed late.
  • Operations and further development permanently tied up attention.

Implementation

What we built. And what mattered in doing so.

A headless setup: a fast frontend at the front, a proven system at the back. The team keeps working where it is at home.

The frontend is a Next.js application delivered as a Cloudflare Worker. WooCommerce remains the leading system for products, orders and customers. Card payment includes 3-D Secure. An order is released only once the payment is confirmed – not as soon as the customer returns from the payment window.

A dedicated admin area was added. It shows orders, customers, content and the automations themselves: each with status, history and a switch.

Building blocks

  • Frontend: Next.js, delivered as a Cloudflare Worker.
  • Data: WooCommerce as the leading system.
  • Payment: card including 3-D Secure, release only after confirmation.
  • Three languages and several delivery countries in one application.
  • Admin area for operations, content and automations.
Admin area: all running automations with status, last run and switch.

The core

Three automations, running in operation.

What matters is not the technology but what happens after launch. Three automations take over operations. They follow the same pattern: an agent may act, but only within narrow limits – and every change has to prove itself.

“Bug fixes that none of us wrote”

Errors from operation are logged and grouped. If the same error occurs repeatedly, an agent takes over: it reads the trace, develops a fix – and must supply a regression test that reproduces the error without the fix. If this test is missing or does not detect the error, the fix is discarded. No test, no fix.

After that the error does not yet count as resolved. Only when it does not recur for 14 days is it closed. This quiet period is the real test: it separates a genuine fix from one that merely hides the symptom.

Evidence: 69 automatic error fixes, June to September 2026.

Error groups with frequency, associated fix, regression test and the running 14-day period.

“We optimise 82% of the pages. The other 18% are the proof.”

SEO work suffers from the fact that nobody can say whether the change had an effect or the market did. That is why a share of the pages is deliberately left untouched: a control group that experiences the same fluctuations as the rest, only without our interventions.

Every change is measured against this control group, and the measurement window is 49 days. Anything that performs worse than the control group is rolled back automatically. Anything that performs better feeds into the next instruction as a rule. Over time the agent therefore gets not more freedom but more precise guidelines.

Evidence: 112 automatic changes for search engines, June to September 2026.

Weekly report: changed pages, control group, development within the measurement window and automatic rollbacks.

“What the agent may not do is not in the prompt – it is in the gate.”

A prompt is a request, not a safeguard. Things only become reliable when the limit sits outside the model. Four things are therefore blocked outright. A proposal that touches them does not get through – regardless of how well it is justified.

Blocked outright

  • The most important keyword.
  • The heading of the home page.
  • Database migrations.
  • The deploy path.

Every change passes

  • Type checking.
  • Linting.
  • The complete test suite.
  • A complete build.

Only when all four steps have passed is anything pushed. This is the same route that manual work has to take.

In the background

More automations. Smaller, but in use every day.

Small-scale work that someone would otherwise do every day – here the software does it.

  • Payment reconciliation every 5 minutes: only confirmed payments release an order.
  • Monitoring of the critical pages every 5 minutes, with an alert before the first customer writes in.
  • Cart and win-back emails run automatically.
  • Tickets close themselves after a period of inactivity and ask for a rating when they do.
  • Daily check of the tax rates.
Error monitoring: figures for the last 24 hours and the trend from which the automatic error fixing draws its cases.

Honesty

What of this does not yet run by itself.

The automatic error fixing and the SEO automation have been tested in operation. They run under supervision and by switch, however, not permanently unattended.

We switch them on when someone is watching, and off again when something is unclear. The figures above say how many changes have taken this route – they do not say that nobody is watching any more.

The distinction matters to us because it marks the difference between an intention and a state. Automation takes work off your hands. The responsibility stays with us.

Transfer

What this means for you. Applied to your project.

If you have a web application developed, the effort is rarely decided at the start but in the years after.

This case shows operate & evolve in its pure form – the phase that begins after acceptance. For us, automating processes does not mean buying software that promises everything. We hand recurring work over piece by piece to processes that can prove they worked: with a mandatory test, with a control group, with rollback.

For you this means less attention spent on operations, more speed in making changes – and a basis on which to decide what to build next.

How the four steps fit together

After acceptance

Operate & evolve

After launch we monitor operations, fix errors automatically with a mandatory test, and keep developing the software at the pace of your business.

Next step

Your operations, the same question. What can be automated?

Tell us what regularly takes up attention in your operations. We will tell you which of it can be automated – and which is better left as manual work.

Discuss a project