Als wir KeepFlow gründeten, standen wir vor der Wahl, vor der jedes technische Team am Anfang steht: Software für Kunden bauen oder Software bauen, die uns gehört. Der Agenturweg ist der sicherere. Kunden zahlen bei Lieferung, der Umsatz ist planbar, und wenn ein Projekt ausgeliefert ist, wird es zum Problem eines anderen. Wir haben den schwereren Weg bewusst gewählt. Jedes Produkt, das KeepFlow macht, besitzen wir von Anfang bis Ende – wir bauen es, wir betreiben es, und wir leben mit jeder Entscheidung, solange es existiert.

Das ist kein Branding-Statement. Es verändert, wie die Entwicklung tatsächlich abläuft, auf Weisen, die wir eine Weile brauchten, um sie vollständig zu würdigen. Das ist es, was Eigentum mit der Art, wie man baut, macht.

Wenn die Beziehung nicht bei der Lieferung endet

Das prägende Merkmal von Kundenarbeit ist, dass sie ein Ende hat. Man steckt ein Projekt ab, man baut es, man übergibt es, und die Beziehung schließt sich. Was auch immer danach mit dieser Software geschieht – die Fehler, die unter echter Last auftauchen, die Performance-Abgründe, der Sicherheits-Patch, der nie eingespielt wird –, gehört jetzt jemand anderem. Man ist schon beim nächsten Auftrag.

Die eigenen Produkte zu besitzen entfernt das Ende. Es gibt keine Übergabe, keinen Moment, in dem der Code aufhört, das eigene Problem zu sein. Das klingt nach einer Last, und an manchen Tagen ist es das auch. Aber es entfernt zugleich die größte Einzelquelle für Abkürzungen in Software: das Wissen, dass man nicht derjenige sein wird, der mit den Folgen umgeht. Wenn es keinen Ausstieg gibt, spart eine Abkürzung keine Zeit – man leiht sich selbst ein Problem auf Zinsen, und man ist derjenige, der es zurückzahlt.

Jeder Fehler ist Ihr Fehler

Der unmittelbarste Effekt betrifft die Verantwortung, und er ist nicht abstrakt. Jeder Fehler in einem KeepFlow-Produkt ist unser Fehler. Jede Performance-Regression zeigt sich in unseren eigenen Zahlen. Jede frustrierte Nutzerin ist ein direktes Urteil über Arbeit, die wir geleistet haben. Es gibt niemanden, dem man das Ticket weiterreichen könnte.

Das lässt eine Mauer einstürzen, deren Aufrechterhaltung die meisten Softwareorganisationen enorme Energie kostet – die zwischen den Menschen, die Software schreiben, und denen, die sie betreiben. Bei KeepFlow sind das dieselben Menschen. Der Entwickler, der eine Funktion gebaut hat, ist derjenige, der sie in der Produktion beobachtet, reagiert, wenn sie um drei Uhr morgens einen Alarm auslöst, und liest, was Nutzer über sie sagen.

Diese Anordnung ist bewusst unbequem, und das ist der Sinn. Wenn die Person, die den Code ausliefert, die Person ist, die davon geweckt wird, hören die Anreize rund um Qualität auf, etwas zu sein, das man mit Prozessen erzwingen muss. Niemand will um 3 Uhr morgens seine eigene Abkürzung debuggen. Der Druck, es beim ersten Mal richtig zu bauen, kommt aus der Struktur der Arbeit, nicht aus einem Richtliniendokument.

Für Lebensdauern bauen, nicht für Fristen

Kundenprojekte sind um Fristen herum organisiert. Eigene Produkte sind um Lebensdauern herum organisiert, und dieser Unterschied reicht in technische Entscheidungen hinein, die an der Oberfläche identisch aussehen, aber entgegengesetzt ausfallen.

Wenn Sie etwas bauen, das Sie jahrelang betreiben werden, kehrt sich das Kalkül bei nahezu jeder Wahl um:

  • Sie investieren von vornherein in Observability, weil Sie derjenige sein werden, der um 2 Uhr morgens auf die Dashboards starrt, und ein System, in das Sie nicht hineinsehen können, ist ein System, das Sie nicht betreiben können.
  • Sie schreiben die Tests, die Sie unter einer Frist versucht wären zu überspringen, weil Sie derjenige sein werden, der in zwei Jahren Änderungen an diesem Code vornimmt, lange nachdem Sie vergessen haben, wie er funktioniert.
  • Sie wählen langweilige, bewährte Technologie statt des aufregenden neuen Frameworks, weil Sie sich verpflichten, diese Entscheidung sehr lange zu pflegen, und Neuartigkeit hat die Angewohnheit, sich in eine Belastung zu verwandeln, sobald der Hype weiterzieht.

Keine dieser Entscheidungen hilft Ihnen, in diesem Quartal schneller auszuliefern. Alle sind offensichtlich richtig, sobald Ihr Zeithorizont in Jahren statt in Wochen gemessen wird. Kundenarbeit belohnt sie selten, weil die Person, die den Kompromiss eingeht, nicht die Person ist, die die Kosten erbt. Eigentum vereint diese beiden Personen zu einer.

Die Rückkopplungsschleife schließt sich

Es gibt einen subtileren Vorteil, dessen wir uns erst später bewusst wurden: Wenn Sie das Produkt besitzen, wird die Schleife zwischen dem Problem einer Nutzerin und der Lösung dafür dramatisch kürzer, weil kein Vertrag mittendrin sitzt.

In der Agenturarbeit ist das Lernen von etwas über die eigenen Nutzer oft der Beginn einer Verhandlung. Sie bemerken einen Reibungspunkt, aber darauf zu reagieren bedeutet eine Änderungsanfrage, ein Scoping-Gespräch, ein neues Leistungsverzeichnis – und bis das alles geklärt ist, ist die Erkenntnis schal geworden. Die Ökonomie entmutigt aktiv das Handeln nach dem, was man lernt, weil jede Verbesserung abrechenbar und damit umstritten ist.

Wenn das Produkt Ihnen gehört, sind Bemerken und Beheben dieselbe Bewegung. Ein Entwickler liest einen Support-Thread, erkennt das Muster hinter drei Beschwerden und liefert die Behebung noch am selben Nachmittag – keine Genehmigungskette, keine Rechnung, keine Debatte darüber, ob es im Leistungsumfang liegt. Die Menschen, die dem Problem am nächsten sind, haben sowohl den Kontext, um es zu verstehen, als auch die Befugnis, es zu lösen. Über Monate hinweg ist dieses Aufsummieren kleiner, ungeblockter Verbesserungen der größte Teil dessen, was ein Produkt, das Menschen ertragen, von einem unterscheidet, auf das sie sich verlassen.

Es verändert auch, was wir überhaupt bauen. Weil wir alles, was wir machen, selbst betreiben, spüren wir unsere eigenen fehlenden Funktionen, bevor eine Nutzerin sie je meldet. Mehrere der schärfsten Dinge in unseren Produkten begannen als Ärgernis, auf das einer von uns stieß, während er im selben Team ein anderes Produkt betrieb. Der eigene anspruchsvollste Kunde zu sein ist eine Art von Forschung, die kein Kundenbriefing kaufen kann.

Trends nicht hinterherjagen

In dieser Branche gibt es die Versuchung, das Neueste als das Beste zu behandeln – auf welchem Framework auch immer gerade im Aufstieg ist neu zu bauen, dem Architekturmuster hinterherzujagen, das gerade die Runde macht. Wir versuchen hart, dem zu widerstehen, und Eigentum macht das leichter, weil wir die vollen Kosten jedes Trends spüren, dem wir hinterherjagen. Eine Neuschreibung, die dieses Jahr in Mode ist, ist eine Wartungslast, die wir die nächsten fünf Jahre tragen.

Was wir stattdessen bauen, ist Infrastruktur, auf die Unternehmen jeden Tag angewiesen sind: Kundensupport, der antworten muss, Betrugserkennung, die richtig sein muss, Moderation, die schnell sein muss, Werkzeuge, nach denen Menschen greifen, ohne darüber nachzudenken, was darunter liegt. Diese Art von Software gewinnt Vertrauen langsam, durch die langweiligen Tugenden – Zuverlässigkeit, Beständigkeit, da sein und funktionieren. Diese Tugenden kommen nicht aus Neuartigkeit. Sie kommen daraus, sich um etwas lange genug zu kümmern, um es richtig hinzubekommen, und dann zu bleiben, um es so zu halten.

Das ist der ganze Grund, warum wir unsere eigenen Produkte bauen. Nicht, weil es leichter ist – ist es nicht –, sondern weil das Leben mit den eigenen Entscheidungen der zuverlässigste Weg ist, den wir kennen, um gute zu treffen.