Build in Public: Warum wir zeigen, wie unsere Systeme arbeiten

Wir schreiben öffentlich auf, wie viel Zeit unsere Automatisierungen sparen, was sie kosten und wo sie kaputtgegangen sind. Manche Kollegen halten das für einen Fehler.

Ihr Argument: Damit gibst du dein Geschäftsmodell weg. Nach zwei Jahren kann ich sagen, dass es umgekehrt läuft.

Build in Public heißt, die Arbeit sichtbar zu machen, während sie passiert. Zahlen, Aufbau, Rückschläge. Ich schreibe hier auf, warum wir das tun, wo unsere Grenze verläuft und was es tatsächlich kostet.

Warum Offenheit im Automatisierungsgeschäft besonders wirkt

Automatisierung ist ein Vertrauensgeschäft mit einem strukturellen Problem: Der Kunde kann das Ergebnis vorher nicht beurteilen.

Wer eine Website kauft, sieht am Ende eine Website. Wer eine Automatisierung kauft, bekommt etwas, das im Hintergrund läuft und im besten Fall nie auffällt. Bewertet wird es an einem Versprechen. Genau deshalb ist die Branche voll von Versprechen.

Offenheit ersetzt das Versprechen durch einen Beleg. Wenn wir schreiben, dass bei mate die Bestellabwicklung von 4 Stunden pro Tag auf 15 Minuten gefallen ist, dann steht daneben, wie das gebaut wurde. Wer es nachbauen will, kann es. Wer es lieber kauft, weiß jetzt, dass wir wissen, wovon wir reden.

Der zweite Effekt ist die Vorqualifizierung. Wer sich durch einen Artikel über Kosten gearbeitet hat, kommt nicht ins Gespräch mit der Frage, ob das drei Wochen dauert. Er kommt mit einer konkreten Frage. Unsere Gespräche sind dadurch kürzer und die Abschlussquote höher.

Was wir zeigen

Vier Dinge, konsequent.

Zahlen aus dem eigenen Betrieb. Rund 65 Prozent unserer Support-Anfragen laufen automatisch. Etwa 40 Prozent aller Anfragen sind Wo ist mein Paket. Über alle Prozesse sparen wir 33 bis 46 Stunden pro Woche. Bei MUSTAX ging das Reporting von 2 Tagen auf 2 Stunden. Diese Zahlen stehen überall gleich, weil wir sie an einer Stelle pflegen.

Den Aufbau, nicht nur das Ergebnis. Welche Systeme reden miteinander, an welcher Stelle sitzt eine Freigabe, wo bricht es. Unsere Artikel zu Human in the Loop und zum Kundenservice-Guide sind so gebaut, dass jemand mit etwas Technikverständnis den Nachbau schafft.

Die Fehler. Bei nano gingen vor der Automatisierung regelmäßig Bestellungen falsch raus. Eine unserer Automatisierungen hätte fast eine Erstattung für eine Retoure ausgezahlt, die nie im Lager ankam. Ein Modell hat einmal eine Rückgabefrist zugesagt, die wir nie hatten, und wir haben sie eingehalten.

Was wir nicht empfehlen. Wir haben einen ganzen Artikel darüber, wann Automatisierung keinen Sinn macht, und einen darüber, wann eine Agentur die falsche Wahl ist. Beide kosten uns rechnerisch Aufträge. Sie bringen uns bessere.

Wo die Grenze verläuft

Offenheit ohne Grenze ist Fahrlässigkeit. Vier Dinge gehen bei uns nie nach draußen.

• Kundendaten in jeder Form. Keine Namen, keine Shops, keine Screenshots mit erkennbaren Bestellungen. Wenn wir über Kundenprojekte schreiben, dann als eine Möbelmarke oder ein Kunde aus dem Lebensmittelhandel. Auch dann prüfen wir, ob die Kombination aus Branche und Zahl jemanden identifizierbar macht.
• Alles, was Zugang gibt. API-Schlüssel, Endpunkte, interne URLs, Kontostrukturen. Das klingt selbstverständlich und geht in der Praxis über Screenshots verloren. Wir schwärzen konsequent.
• Preise im Einzelnen. Wir nennen Größenordnungen und Amortisationszeiten. Wir veröffentlichen keine Kalkulation je Projekt. Ein Preis ohne den Umfang dahinter erzeugt falsche Erwartungen bei allen Beteiligten.
• Fremde Zahlen. Die Zeitersparnis eines Kunden gehört dem Kunden. Wir veröffentlichen sie nur mit ausdrücklicher Freigabe, und meistens fragen wir gar nicht erst.

Dazu kommt eine Regel, die weniger offensichtlich ist: Wir zeigen nichts, was noch nicht stabil läuft. Ein Aufbau, den wir zwei Wochen später verwerfen, ist als Vorlage für andere gefährlich. Wir schreiben über Dinge, die bei uns seit Monaten im Betrieb sind.

Was es kostet

Der unbequeme Teil dieses Textes betrifft den Preis, und der wird in Build-in-Public-Beiträgen fast nie genannt.

Zeit. Ein brauchbarer Artikel über einen echten Aufbau kostet uns einen halben bis ganzen Tag. Das ist Zeit, die nicht in Kundenprojekte geht. Bei einem Zweipersonenbetrieb ist das spürbar.

Angriffsfläche. Wer Zahlen nennt, wird an ihnen gemessen. Wenn unsere Automatisierungsquote in einem Monat auf 55 Prozent fällt, steht das gegen unsere eigene veröffentlichte Zahl. Das diszipliniert und es macht unruhig.

Nachahmung. Ja, Wettbewerber lesen mit. Manche bauen unsere Ideen nach. Das ist der Einwand, den wir am häufigsten hören, und der am wenigsten wehtut. Der Aufbau ist der einfache Teil. Zu wissen, welchen Prozess man bei welchem Kunden zuerst anfasst, steht in keinem Artikel.

Festlegung. Wer öffentlich eine Meinung vertritt, kommt schwerer davon ab. Wir haben früh geschrieben, dass wir n8n selbst hosten. Als wir intern über einen Wechsel nachdachten, war die veröffentlichte Position ein zusätzlicher Widerstand. Wir haben sie am Ende überprüft und beibehalten, aber der Reflex war spürbar.

Für wen das nichts ist

Ich empfehle Build in Public nicht pauschal. Vier Fälle, in denen ich davon abraten würde.

Wenn dein Vorsprung im Verfahren liegt. Es gibt Geschäftsmodelle, deren einziger Vorteil ein nicht offensichtliches Vorgehen ist. Dann ist Schweigen die richtige Strategie. Unser Vorteil liegt in Erfahrung und Geschwindigkeit, und beides lässt sich nicht abschreiben.

Wenn die Zahlen noch nicht tragen. Offenheit über ein Geschäft, das gerade nicht funktioniert, wird schnell zur Selbstdarstellung des Kämpfens. Das erzeugt Sympathie und keine Kunden.

Wenn du keine Frequenz halten kannst. Drei Artikel und dann sechs Monate Stille sind schlechter als gar nichts. Sichtbare Offenheit erzeugt eine Erwartung, die du bedienen musst.

Wenn du in einer regulierten Branche arbeitest. In Medizin, Finanzen oder überall dort, wo Aussagen genehmigungspflichtig sind, wird aus einem halben Tag Schreiben eine Freigabeschleife über Wochen.

Und ein Einwand, der auch für uns gilt: Build in Public verführt dazu, das Zeigbare zu bauen statt das Nützliche. Wer merkt, dass er einen Prozess anfasst, weil er sich gut erzählen lässt, sollte aufhören. Wir prüfen das bei uns mit einer simplen Regel. Erst läuft es drei Monate im Betrieb, dann schreiben wir darüber.

Was uns das konkret gebracht hat

Damit das nicht bei Prinzipien bleibt, drei Effekte, die wir messen konnten.

Der erste betrifft die Gesprächsdauer. Vor zwei Jahren ging in einem Erstgespräch die Hälfte der Zeit für Grundlagen drauf. Was ein Workflow ist, warum eine Freigabe Sinn ergibt, warum wir nicht in drei Tagen fertig sind. Heute haben die meisten Leute vorher zwei Artikel gelesen. Das Gespräch startet bei der Frage, welcher Prozess zuerst drankommt.

Der zweite betrifft die Art der Anfragen. Wer einen Text darüber gelesen hat, wann Automatisierung keinen Sinn ergibt, meldet sich seltener mit einem Vorhaben, das keinen Sinn ergibt. Wir sagen dadurch weniger oft ab, weil weniger Unpassendes ankommt.

Der dritte betrifft uns selbst. Etwas so aufzuschreiben, dass ein Fremder es nachbauen kann, deckt Lücken auf. Beim Text über unsere Freigaben ist uns aufgefallen, dass wir für zwei Fälle gar keine klare Regel hatten. Wir haben sie beim Schreiben festgelegt. Das war kein Nebeneffekt, das war der Ertrag des Tages.

Wie wir es praktisch machen

Für den Fall, dass du es ausprobieren willst, unser Vorgehen in vier Punkten.

• Eine Quelle für Zahlen. Alle Kennzahlen stehen an einer Stelle. Wenn sich eine ändert, ändert sie sich überall. Widersprüchliche Zahlen in zwei Artikeln kosten mehr Vertrauen, als beide zusammen aufbauen.
• Schreiben aus dem Betrieb heraus. Der Anlass für einen Artikel ist bei uns immer etwas, das gerade passiert ist. Eine Automatisierung, die fertig wurde. Ein Fehler, den wir gemacht haben.
• Anonymisieren als Standard. Nicht als Einzelfallentscheidung. Wer bei jedem Text neu abwägt, macht irgendwann den Fehler.
• Fehler mit der Lösung veröffentlichen. Ein Fehlerbericht ohne den Umgang damit ist eine Warnung vor dir selbst. Mit der Lösung ist er ein Beleg für Kompetenz.

Wie wir intern damit umgehen, dass Mitarbeiter und KI-Systeme gemeinsam an solchen Inhalten arbeiten, steht in KI im Team einsetzen.

Fazit

Wir zeigen unsere Systeme, weil unser Produkt unsichtbar ist. Der Beleg muss also woanders herkommen.

Der Preis dafür ist Zeit, Angriffsfläche und die Bindung an eigene Aussagen. Der Ertrag sind Gespräche mit Leuten, die schon verstanden haben, was sie kaufen. Für uns geht die Rechnung auf. Ob sie für dich aufgeht, hängt davon ab, worin dein Vorsprung liegt.

Wenn du wissen willst, wie eine solche Automatisierung bei euch konkret aussehen würde: Sprich mit uns bei Flowhouse. Wir zeigen dir den Aufbau, auch wenn du ihn am Ende selbst baust.