Zum Inhalt springen

Case Study · LeafConnect

Ein Shop, der sich selbst repariert.

Ein dreisprachiger Onlineshop im regulierten Handel, gebaut als headless Webanwendung auf Next.js und betrieben als Cloudflare Worker. Der eigentliche Fall beginnt nach dem Start: Automatisierungen beheben Fehler mit Pflichttest und messen jede SEO-Änderung gegen eine Kontrollgruppe.

69automatische Fehlerkorrekturen
112automatische Änderungen für Suchmaschinen
49 TageMessfenster je SEO-Änderung
14 Tagestille Frist bis „behoben“

Alle Zahlen aus dem Zeitraum Juni bis September 2026.

Ausgangslage

Ein Shop in drei Sprachen, mit wenig Spielraum für Fehler.

LeafConnect verkauft online in Deutsch, Englisch und Tschechisch und liefert in mehrere Länder. Was verkauft wird, steht hier bewusst nicht: Der Case ist für den Namen freigegeben, nicht für das Sortiment.

Regulierter Handel heißt: Zuverlässigkeit und Rechtssicherheit sind keine Ziele, sondern Voraussetzung. Preise, Steuersätze, Zahlungswege und Lieferbedingungen müssen in jeder Sprache und in jedem Land stimmen – dauerhaft, nicht nur am Tag des Livegangs.

Genau das band Aufmerksamkeit. Betrieb und Weiterentwicklung liefen nebenher mit. Jeder kleine Fehler, jede Anpassung an einer Textstelle, jede Prüfung nach einem Update kostete jemanden Zeit, der eigentlich das Geschäft führen wollte.

Rahmenbedingungen

  • Drei Sprachen, mehrere Lieferländer, eine Codebasis.
  • Zahlungen und Steuersätze müssen jederzeit nachvollziehbar stimmen.
  • Ausfälle auf der Kaufstrecke sind teuer und fallen ohne Überwachung spät auf.
  • Betrieb und Weiterentwicklung banden dauerhaft Aufmerksamkeit.

Umsetzung

Was wir gebaut haben. Und worauf es dabei ankam.

Ein headless Aufbau: schnelles Frontend vorne, bewährtes System hinten. Das Team arbeitet weiter dort, wo es sich auskennt.

Das Frontend ist eine Next.js-Anwendung, die als Cloudflare Worker ausgeliefert wird. Führendes System für Produkte, Bestellungen und Kunden bleibt WooCommerce. Kartenzahlung läuft inklusive 3-D Secure. Eine Bestellung wird erst freigegeben, wenn die Zahlung bestätigt ist – nicht schon, wenn der Kunde aus dem Bezahlfenster zurückkommt.

Dazu kam ein eigener Adminbereich. Dort sind Bestellungen, Kunden, Inhalte und die Automatisierungen selbst sichtbar: jede mit Status, Verlauf und Schalter.

Bausteine

  • Frontend: Next.js, ausgeliefert als Cloudflare Worker.
  • Daten: WooCommerce als führendes System.
  • Zahlung: Karte inklusive 3-D Secure, Freigabe erst nach Bestätigung.
  • Drei Sprachen und mehrere Lieferländer in einer Anwendung.
  • Adminbereich für Betrieb, Inhalte und Automatisierungen.
Adminbereich: alle laufenden Automatisierungen mit Status, letztem Lauf und Schalter.

Der Kern

Drei Automatisierungen, die im Betrieb laufen.

Interessant ist nicht die Technik, sondern was nach dem Start passiert. Drei Automatisierungen übernehmen den Betrieb. Sie folgen demselben Muster: Ein Agent darf handeln, aber nur in engen Grenzen – und jede Änderung muss sich beweisen.

„Bugfixes, die niemand von uns geschrieben hat“

Fehler aus dem Betrieb werden protokolliert und gruppiert. Tritt derselbe Fehler wiederholt auf, übernimmt ein Agent: Er liest die Spur, entwickelt eine Korrektur – und muss einen Regressionstest mitliefern, der den Fehler ohne den Fix reproduziert. Fehlt dieser Test oder erkennt er den Fehler nicht, wird der Fix verworfen. Kein Test, kein Fix.

Danach gilt der Fehler noch nicht als behoben. Erst wenn er 14 Tage lang nicht wieder auftritt, wird er geschlossen. Diese stille Frist ist der eigentliche Prüfstein: Sie trennt eine echte Korrektur von einer, die nur das Symptom verdeckt.

Beleg: 69 automatische Fehlerkorrekturen, Juni bis September 2026.

Fehlergruppen mit Häufigkeit, zugehörigem Fix, Regressionstest und laufender 14-Tage-Frist.

„Wir optimieren 82 % der Seiten. Die anderen 18 % sind der Beweis.“

SEO-Arbeit leidet daran, dass niemand sagen kann, ob die Änderung gewirkt hat oder der Markt. Deshalb bleibt ein Teil der Seiten bewusst unangetastet: eine Kontrollgruppe, die dieselben Schwankungen erlebt wie der Rest, nur ohne unsere Eingriffe.

Jede Änderung wird gegen diese Kontrollgruppe gemessen, das Messfenster beträgt 49 Tage. Was schlechter läuft als die Kontrollgruppe, wird automatisch zurückgerollt. Was besser läuft, fließt als Regel in die nächste Anweisung ein. Der Agent bekommt also mit der Zeit nicht mehr Freiheit, sondern genauere Vorgaben.

Beleg: 112 automatische Änderungen für Suchmaschinen, Juni bis September 2026.

Wochenbericht: geänderte Seiten, Kontrollgruppe, Entwicklung im Messfenster und automatische Rollbacks.

„Was der Agent nicht darf, steht nicht im Prompt – es steht im Gate.“

Ein Prompt ist eine Bitte, kein Schutz. Verlässlich wird die Sache erst, wenn die Grenze außerhalb des Modells liegt. Vier Dinge sind deshalb hart gesperrt. Ein Vorschlag, der sie berührt, kommt nicht durch – unabhängig davon, wie gut er begründet ist.

Hart gesperrt

  • Das wichtigste Keyword.
  • Die Überschrift der Startseite.
  • Datenbank-Migrationen.
  • Der Deploy-Pfad.

Jede Änderung passiert

  • Typprüfung.
  • Linting.
  • Die vollständige Testsuite.
  • Einen vollständigen Build.

Erst wenn alle vier Schritte durchlaufen sind, wird gepusht. Das ist dieselbe Strecke, die auch Handarbeit nehmen muss.

Im Hintergrund

Weitere Automatisierungen. Kleiner, aber täglich im Einsatz.

Kleinteilige Arbeit, die sonst jemand täglich erledigt – hier erledigt sie die Software.

  • Zahlungsabgleich alle 5 Minuten: Nur bestätigte Zahlungen geben eine Bestellung frei.
  • Monitoring der kritischen Seiten alle 5 Minuten, mit Alarm, bevor der erste Kunde schreibt.
  • Warenkorb- und Rückgewinnungsmails laufen automatisch.
  • Tickets schließen sich nach Inaktivität selbst und fragen dabei nach einer Bewertung.
  • Tägliche Prüfung der Steuersätze.
Fehlerüberwachung: Zahlen der letzten 24 Stunden und der Verlauf, aus dem die automatische Fehlerbehebung ihre Fälle zieht.

Ehrlichkeit

Was daran noch nicht von allein läuft.

Die automatische Fehlerbehebung und die SEO-Automatisierung sind im Betrieb erprobt. Sie laufen aber unter Aufsicht und per Schalter, nicht dauerhaft unbeaufsichtigt.

Wir schalten sie zu, wenn jemand hinsieht, und wieder ab, wenn etwas unklar ist. Die Zahlen oben sagen, wie viele Änderungen diese Strecke genommen haben – sie sagen nicht, dass niemand mehr hinsieht.

Uns ist die Unterscheidung wichtig, weil sie den Unterschied zwischen einer Absicht und einem Zustand markiert. Automatisierung nimmt Arbeit ab. Die Verantwortung bleibt bei uns.

Übertragung

Was das für Sie heißt. Übertragen auf Ihr Vorhaben.

Wenn Sie eine Webanwendung entwickeln lassen, entscheidet sich der Aufwand selten am Start, sondern in den Jahren danach.

Dieser Case zeigt Betreiben & Weiterentwickeln in Reinform – die Phase, die nach der Abnahme beginnt. Prozesse automatisieren heißt für uns nicht, eine Software anzuschaffen, die alles verspricht. Wir übergeben die wiederkehrende Arbeit Stück für Stück an Abläufe, die belegen können, dass sie funktioniert haben: mit Pflichttest, mit Kontrollgruppe, mit Rollback.

Für Sie heißt das: weniger Aufmerksamkeit für den Betrieb, mehr Tempo bei Änderungen – und eine Grundlage, auf der sich entscheiden lässt, was als Nächstes gebaut wird.

Wie die vier Schritte zusammenhängen

Nach der Abnahme

Betreiben & Weiterentwickeln

Nach dem Start überwachen wir den Betrieb, beheben Fehler automatisiert mit Pflichttest und entwickeln die Software im Takt Ihres Geschäfts weiter.

Nächster Schritt

Ihr Betrieb, dieselbe Frage. Was lässt sich automatisieren?

Erzählen Sie uns, was in Ihrem Betrieb regelmäßig Aufmerksamkeit kostet. Wir sagen Ihnen, was sich davon automatisieren lässt – und was besser Handarbeit bleibt.

Projekt besprechen