Drei Jahre eigene Produkte betreiben: was Reazon und Wortfreunde uns gelehrt haben

Der Samstagmorgen, an dem das Telefon ging

Im zweiten Betriebsjahr klingelte an einem Samstag um kurz nach acht das Telefon. Bei einem Nutzer von Reazon lud die Vorschau nicht mehr, eine einzelne Funktion, kein Weltuntergang. Aber es war unser Produkt, unser Server, unser Wochenende. Es gab niemanden, an den wir das Ticket hätten weiterreichen können. Genau dieser Moment beschreibt den Unterschied, um den es hier geht: Wir bauen Software nicht nur und übergeben sie, wir betreiben sie selbst, Tag für Tag.

Reazon, das CMS, in dem dieser Artikel liegt, und Wortfreunde, unser SaaS rund um Content und Sichtbarkeit, laufen seit mehreren Jahren für echte Nutzer. In dieser Zeit haben sie uns Dinge beigebracht, die in keinem Pflichtenheft und in keinem Angebot stehen. Dieser Text ist kein Hochglanz-Rückblick, sondern eine Sammlung der Lektionen, die wir nur lernen konnten, weil wir selbst am Pager hängen. Wer ein Produkt baut, das danach jahrelang laufen soll, kann ein paar davon gebrauchen, bevor er sie selbst auf die harte Tour lernt.

Der Launch ist die Eröffnung, nicht das Ziel

In der Projektwelt fühlt sich der Launch wie die Ziellinie an. Monatelang wird auf ein Datum hingearbeitet, dann ist es live, und alle atmen durch. Aus der Betreiberrolle sieht das anders aus. Der Launch ist der Moment, in dem die eigentliche Arbeit beginnt, nicht endet. Ab da reden nicht mehr Tester mit dem System, sondern Menschen, die etwas erledigen wollen und sich nicht für deine Architektur interessieren.

Bei Wortfreunde haben wir das in den ersten Wochen nach dem Start gemerkt. Die Funktionen taten, was sie sollten, und trotzdem stapelten sich kleine Reibungen: ein Formular, das bei einer ungewohnten Eingabe blockierte, ein Export, der bei grossen Datenmengen zäh wurde, eine Fehlermeldung, die für uns klar war und für niemanden sonst. Nichts davon war ein Bug im engeren Sinn. Es waren die Stellen, an denen geplante Software auf ungeplante Wirklichkeit trifft.

Dieser Reflex, ein Produkt vom Betrieb her zu denken statt vom Abgabetermin, hat verändert, wie wir bauen. Wir legen zuerst die Sicherungen, dann das schöne Stockwerk. Was das im Detail heisst, haben wir in Betrieb ab Tag eins produktionsreif aufgeschrieben. Die Kurzfassung: Ein Produkt ist nicht fertig, wenn es funktioniert, sondern wenn jemand es um drei Uhr nachts wieder zum Laufen bringen kann, ohne den Entwickler zu wecken.

Die Rechnung kommt nach dem Launch

Die zweite Lektion ist eine über Geld, und sie war für uns die teuerste. Vor dem Launch denkst du in Aufwand: Wochen, Features, ein Budget mit einem Ende. Nach dem Launch denkst du in Laufzeit. Ein Produkt verursacht Kosten, solange es lebt, und der grösste Teil davon entsteht nach dem ersten Tag. Server, Updates, Sicherheitslücken, die jemand schliessen muss, kleine Anpassungen, die sich aus dem Gebrauch ergeben.

Bei Reazon hatten wir anfangs unterschätzt, wie viel laufende Pflege ein scheinbar fertiges System frisst. Eine Abhängigkeit bekommt ein Sicherheitsupdate, das du einspielen musst, auch wenn kein Kunde danach fragt. Ein Dienst von Drittanbietern ändert seine Schnittstelle, und plötzlich musst du nachziehen, ohne dass nach aussen ein einziges neues Feature sichtbar wird. Diese Arbeit ist unsichtbar, bis sie ausbleibt, dann wird sie schlagartig sehr sichtbar.

Dieser Effekt ist kein Sonderfall, sondern die Regel, und wir haben ihn deshalb in einem eigenen Text auseinandergenommen: warum Software nach dem Launch teuer wird. Aus der Betreiberperspektive lässt sich daraus eine schlichte Faustregel ziehen: Wer nur die Baukosten plant, plant nur den kleineren Teil. Wir kalkulieren heute jeden eigenen Aufbau mit dem Betrieb im Blick, weil wir die Rechnung selbst bezahlen.

Stilles Versagen ist teurer als ein lauter Ausfall

Ein kompletter Ausfall ist unangenehm, aber wenigstens merkst du ihn sofort. Gefährlicher ist die Sorte Fehler, die niemand bemerkt. Ein Produkt, das niemand beobachtet, fällt nicht plötzlich aus, es war schon vorher krank, nur hat es keiner gesehen. Das ist die Lektion, die uns Monitoring beigebracht hat, und wir haben sie zweimal gelernt, bevor sie sass.

Einmal lief bei Wortfreunde im Hintergrund ein Verarbeitungsschritt über Tage hinweg seltener durch, als er sollte. Nach aussen war alles grün, die Seite lud, niemand beschwerte sich. Erst als ein Nutzer fragte, warum ein Ergebnis veraltet aussah, fanden wir die Ursache. Der Schaden war nicht der Ausfall, sondern die Zeit, in der wir blind waren. Seitdem gilt bei uns: Was nicht gemessen wird, existiert betrieblich nicht. Lieber ein Alarm zu viel als eine Woche im Dunkeln.

Das Grundgerüst, das wir daraus abgeleitet haben, ist bewusst schlank: sehen, ob das System gesund ist, Sicherungen, die im Ernstfall auch wirklich zurückspielbar sind, und eine Alarmierung, die die richtige Person zur richtigen Zeit erreicht. Mehr braucht es am Anfang nicht, aber weniger rächt sich. Wie dieses Minimum konkret aussieht, steht in Monitoring, Backups und Alerting als Minimum. Der Punkt aus erster Hand: Diese Dinge fühlen sich vor dem ersten Vorfall nach Überversicherung an und nach dem ersten Vorfall nach gesundem Menschenverstand.

Nutzer machen Dinge, die du nie eingeplant hast

Die vierte Lektion ist die schönste, weil sie immer wieder überrascht. Sobald echte Menschen ein Produkt benutzen, benutzen sie es anders als geplant. Nicht falsch, nur anders. Sie finden Wege, an die im Entwurf niemand gedacht hat, und sie ignorieren Funktionen, in die wir Wochen gesteckt hatten.

Bei Reazon haben wir Funktionen gebaut, die uns wichtig erschienen und die kaum jemand anrührte, während eine Kleinigkeit, die fast nebenbei entstand, für viele zum meistgenutzten Teil wurde. Diese Verschiebung siehst du nur, wenn du das Produkt im Betrieb beobachtest und nicht nur einmal abnimmst. Aus der Distanz hätten wir die falschen Schlüsse gezogen. Erst der laufende Gebrauch sagt dir, was wirklich der Kern ist.

Genau hier zahlt sich die Betreiberrolle für die Produktentwicklung aus. Wir bekommen ungefiltert mit, wo Menschen hängenbleiben, welche Frage im Support dreimal pro Woche kommt und welche Funktion man getrost weglassen könnte. Diese Rückmeldung ist wertvoller als jede Umfrage, weil sie aus Handeln besteht, nicht aus Meinung. Eine Agentur, die nach der Abgabe weiterzieht, sieht diese Signale nie. Wir sehen sie jeden Tag und bauen das Produkt entlang davon um.

Warum wir uns das freiwillig antun

Man könnte fragen, warum wir uns den Betrieb überhaupt aufhalsen, statt nur zu bauen und zu übergeben. Die Antwort ist einfach: Der Betrieb ist die Schule, in der man baut. Wer ein Produkt nie selbst durch einen Vorfall getragen hat, baut anders, meist sorgloser. Jede Lektion aus diesem Text steckt heute in der Art, wie wir auch die Produkte unserer Kunden aufsetzen, lange bevor irgendwo etwas brennt.

Genau das unterscheidet uns von einer reinen Projektwerkstatt. Wir reden über Betrieb nicht aus Folien, sondern aus dem eigenen Pager-Dienst. Wenn wir dir sagen, dass ein Produkt Sicherungen und Sichtbarkeit braucht, bevor es das fünfte Feature bekommt, dann nicht aus Vorsicht, sondern weil wir den Samstagmorgen kennen, an dem das Telefon klingelt. Diese Betreiberperspektive ist der Kern unseres Angebots Produkt und Betrieb.

Wenn du selbst ein Produkt im Markt hast oder eines planst, ist die nützlichste Frage nicht, was es kostet zu bauen, sondern was es kostet, es am Leben zu halten, und wer am Samstag ans Telefon geht. Wir gehen für unsere eigenen Produkte ran und für die, die wir für andere betreiben. Wenn du willst, dass jemand diese Verantwortung mitträgt statt nur Code zu liefern, sprich mit uns.