Hallo Patrick — schön, dass du reinschaust.

Den laufenden Betrieb führt meine Frau, die das Studio leitet — die Kundenkommunikation findet auf Thai statt, da bin ich raus. Ich baue gelegentlich eine neue Funktion ein, mehr nicht. Es geht mir nicht um ein fertiges Produkt, sondern um den Nachweis: Ich setze mit Claude Code eigenständig ein produktives System um.

Die Idee stammt nicht von mir. Am 18. Juli habe ich einen Podcast mit dem Gründer von Leaders of AI gesehen — überzeugt hat mich weniger die Technik als der Gedanke dahinter: ein Unternehmen bewusst klein und flach halten und alles Weitere über KI-Mitarbeiter abbilden statt über zusätzliche Ebenen. Genau das lese ich aus eurer Ausschreibung heraus, und am selben Wochenende habe ich angefangen zu bauen.

Der Aufwand steckte nicht in den Agenten selbst, sondern im Unterbau: eine gemeinsame Laufzeitumgebung mit Werkzeugen, Gedächtnis, Freigabe-Logik, Dateiablage und automatischem Deployment. Das war die eigentliche Arbeit. Sie fällt einmal an — jeder weitere Agent kostet danach Tage statt Wochen.

Ich nenne das Tempo bewusst mit Datum. Nicht alles davon ist fertig. Aber ihr seht daran, wie ich arbeite, wenn mich ein Thema überzeugt — und was in eurem ersten Monat realistisch möglich ist.

Ich mache die Buchhaltung für TM Services und für das Studio meiner Frau. Diese doppelte Perspektive — Anwender und Automatisierer zugleich — ist der Grund, warum ich bei Buchhaltungs-Automatisierung weiß, wo die echten Fallstricke liegen und wo eine Maschine still Unsinn bucht.

Die beste Automatisierung ist wertlos, wenn das Team sie nicht bedienen kann oder ihr nicht traut. Ich habe jahrelang genau an dieser Schnittstelle gearbeitet: technische Abläufe so übersetzen, dass Menschen ohne IT-Hintergrund sie sicher benutzen. Für KI-Werkzeuge gilt das noch stärker als für eine Mitgliederverwaltung.

Der Unterschied ist wichtig: No-Code-Werkzeuge wie n8n decken viel ab, stoßen aber an Grenzen, sobald eine Schnittstelle nicht vorgesehen ist. Weil ich beides beherrsche, bin ich nicht darauf angewiesen, dass ein fertiger Baustein existiert — ich baue ihn im Zweifel selbst.

Lesson 1: Der Workflow für automatische Antworten auf Google-Reviews ist gebaut, läuft aber nicht. Die API-Freigabe habe ich am 21. Juli beantragt, Google braucht 5 bis 10 Werktage und garantiert nichts. Gelernt: die Schnittstellenfrage vor die Bauarbeit ziehen, nicht danach.

Lesson 2: lexoffice' API ist zu eingeschränkt für durchgängige Automatisierung — es fehlt vor allem der lesende Zugriff, mit dem eine Maschine prüfen könnte, ob eine Buchung wirklich angekommen ist. Ohne diesen Rückabgleich ist „automatisch gebucht“ nur geraten. Deshalb stelle ich auf BuchhaltungsButler um; die Migration läuft. Ab Montag, 3. August, kann ich live zeigen, wie die Buchhaltung dann durchläuft.

Deshalb prüfe ich zuerst, was eine API hergibt, und verspreche danach.

Ein Beispiel liefert diese Seite selbst: Sie liegt bewusst bei einem EU-Anbieter (bunny.net, Ljubljana), ist auf noindex gestellt und über eine nicht erratbare Adresse erreichbar — auch das Video streame ich von dort statt über YouTube, wo jeder Zuschauer getrackt würde. Kleine Entscheidungen, aber sie zeigen die Denkweise besser als das Zertifikat.

Was Shopify an Schnittstellen hergibt, habe ich mit Claude in Minuten aufgearbeitet — danach ist die Frage nur noch, ob wir ein vorhandenes Plugin nehmen oder für einen bestimmten Fall etwas Eigenes bauen. Fürs Team lege ich Claude-Skills an, damit die Kolleg/innen nicht bei null anfangen, inklusive Regeln, an die sich alle halten: getestet wird auf einem Staging-Shop, nicht im Livesystem.

Was mir wirklich fehlt, sind die Eigenheiten eures Shops — welche Apps drinhängen, wo die Produktdaten unsauber sind, welcher Handgriff im Alltag nervt. Das steht in keiner Dokumentation, das lerne ich nur von euch.