Aus einer Prompt-Kette im Chatfenster wurde eine Plattform, die personalisierte Reports verkauft, schreibt, rendert und ausliefert.

Ausgangslage

Sounity schreibt persönliche Reports für ihre Kunden. Lange Texte, sorgfältig gestaltet, als PDF. Am Anfang lief das per Hand: Daten eintragen, eine Folge von Prompts im Chatfenster abarbeiten, Ergebnis in ein Layout kopieren. Das kostete pro Kunde Zeit und hing an einer Person.

Das Team wollte das nicht selbst in n8n bauen. Es wollte, dass es läuft. Inzwischen bin ich bei Sounity für die gesamte Technik hinter dem Produkt verantwortlich.

Was ich hier baue

Die Report-Pipeline

Angefangen hat es im August 2025 mit einer mehrstufigen Prompt-Schleife. Ein einzelner Prompt liefert zu komprimierten, flachen Text, mehrere Schritte nacheinander halten Länge und Qualität. Daraus wurde eine Kette mit rund 40 Prompts pro Report, orchestriert in n8n, jeder Baustein als eigener Sub-Workflow, damit ich Teile einzeln testen kann. Die Prompts liegen in Google Docs und werden zur Laufzeit geladen, so schreibt das Team weiter dort, wo es gewohnt ist. Gemini ist das Hauptmodell, OpenRouter springt ein, wenn es hakt. Dazu kamen Reports für zwei Personen, die eigene Datensätze verknüpfen und eine eigene Strecke durchlaufen.

Admin und Kundenportal

Seit März 2026 hat das Team einen eigenen Admin. Dort laufen Sessions, Report-Typen, Prompts, Modelle und Reasoning-Einstellungen zusammen, ohne dass jemand Code anfasst. Jede Session zeigt den kompletten Prompt-Verlauf, fehlgeschlagene Reports lassen sich mit einem Klick neu starten. Kleine Dinge, die im Alltag zählen: abgelaufene Formular-Links erneuert das Team selbst aus der Session-Liste, und ein Shopify-Produkt ohne zugeordneten Report-Typ löst sofort einen Alarm aus, statt dass ein Kunde ins Leere kauft.

Eigener Renderer statt Layout aus dem Modell

Das LLM war beim Inhalt verlässlich, beim Layout nicht. Also habe ich die Aufgabe geteilt. Das Modell schreibt sauberes Markdown mit festen Überschriften, ein eigener HTML/PDF-Renderer macht daraus Seiten mit Cover, Hintergründen, Grafiken und sauberen Umbrüchen. Im Admin stellt das Team Coverbild, Logo und Hintergründe pro Report-Typ selbst ein. Tests prüfen, dass kein Text über den Seitenrand läuft und das Inhaltsverzeichnis zum Text passt.

Prompt-Harness

Wenn 40 Prompts zusammenspielen, bricht eine kleine Änderung leicht etwas am anderen Ende. Im Juli 2026 habe ich deshalb einen Regressionstest für Prompts gebaut: echte Entwürfe aus Produktion laufen durch, und ein Vertrag prüft, ob die Struktur stimmt. Im letzten Lauf vor der Umstellung waren alle 29 Report-Typen gültig, 50 von 50 Produktionsentwürfen kamen im ersten Anlauf sauber formatiert zurück. Erst danach ging der neue Formatierungsschritt live, mit Backups der alten n8n-Workflows für den Rückweg.

Shop, Auslieferung und Überwachung

Bezahlt wird im Shopify-Shop. Danach bekommt der Kunde einen persönlichen Link zum Formular, die Pipeline läuft los, und am Ende steht eine private Download-Seite mit allen Reports und Audio-Versionen. Für die Audio-Versionen habe ich mit Podcast- und Audio-Modellen experimentiert, die aus einem Report eine Folge zum Anhören machen. Daten erst nach dem Kauf zu sammeln war deutlich sauberer, als alles in den Checkout zu quetschen. Fehler in n8n landen automatisch in einem Ops-Repo, wo ein Agent sie vorsortiert. Ein Watchdog meldet sich, wenn jemand bezahlt, aber sein Formular nie ausgefüllt hat.

Weg von den Node-Diensten, hin zu Rails

Über die Monate waren mehrere kleine Node-Dienste entstanden: Render-API, Grafik-Renderer, Gateway, Worker. Am 7. September 2026 habe ich angefangen, sie in eine Rails-App zu ziehen. Kein Big Bang: n8n blieb, nur die kleinen Prozesse wanderten. Jede Schnittstelle blieb exakt gleich, Tests prüfen Eingabe gegen Ausgabe, die Grafiken kamen byte-identisch aus dem neuen Code. Am 18. September habe ich umgeschaltet, danach jeden Report-Typ in Produktion neu gerendert und neben historische PDFs desselben Typs gelegt. Kurz darauf lief der erste echte Kauf sauber durch. Das Monitoring prüft jetzt die ganze Pipeline, auch Worker und Queue, nicht nur ob die Startseite antwortet.

Sounity Moment: ein Messe-Prototyp

Am 24. September kam eine Anfrage für die Messe am Wochenende: kein voller Report, sondern ein kurzer Ausschnitt, der neugierig macht. Statt einer neuen Strecke habe ich daraus einen neuen Report-Typ gemacht. Gleiche Pipeline, zwei Prompts statt 40, eigenes kompaktes Layout, keine E-Mail. Besucher füllen am Tablet ein kurzes Formular aus und landen direkt auf ihrer Download-Seite. Die lesbare Version steht nach wenigen Sekunden da, das PDF kommt danach.

Die Strecke nach dem Kauf

Seit Oktober 2026 startet nach jedem Report eine persönliche E-Mail-Begleitung über vier Wochen. Ein Modell schreibt die Mails aus dem gekauften Report, Brevo versendet sie. Neue Anmeldungen bestätigen ihre Adresse, bevor etwas rausgeht. Texte und Buttons der Strecke pflegt das Team selbst im Admin und kann jede Strecke im Schnelldurchlauf testen.

Wie ich arbeite

Ich baue das meiste mit Agenten, oft mehrere parallel in eigenen Cloud-Umgebungen, und prüfe selbst, was live geht. Bei Sounity heißt das: Produktion wird erst gelesen, dann bewiesen, dann geändert. Vor jeder größeren Umstellung liegen echte Dokumente neben den alten. Ich probiere auch Dinge aus und werfe sie wieder weg. Eine eigene Job-Engine neben n8n habe ich zweimal getestet und beide Male verworfen, weil Rails dasselbe einfacher kann.

Abgesprochen wird kurz und direkt mit dem Sounity-Team, meist im Call. Aus dem Transkript wird dann direkt der Arbeitsauftrag.

Was dabei rauskam

Aus einem manuellen Ablauf ist ein Produkt geworden, das ohne Eingriff verkauft, schreibt, rendert und ausliefert. Neue Report-Typen sind Konfiguration, kein neues Projekt. Das Team ändert Prompts, Modelle, Layouts und E-Mail-Texte selbst.

Carsten Bruns hat es am Anfang so beschrieben: Ein Bericht, der sonst 20 bis 30 Minuten gekostet hat, entsteht jetzt automatisch.