Ich habe dieses Produkt vollständig allein gebaut, größtenteils abends, an Wochenenden und an mehr Feiertagen, als ich zugeben möchte. Lange fühlte es sich trotzdem wie ein privates Projekt an, das zufällig im Web verfügbar war.
Mit dem Aktivieren der Zahlungen änderte sich dieses Gefühl sofort. Der Code wurde nicht plötzlich anspruchsvoller, aber meine Verantwortung für das Produkt änderte sich. Sobald jemand bezahlen kann, ist ein kaputter Flow nicht mehr nur ein unfertiger Edge Case. Onboarding, Moderation, Retention, Vertrauen und Zuverlässigkeit sind keine Themen für später mehr. Sie gehören zu dem, was das Produkt jetzt verspricht.
Das ist die wichtigste Lektion, die ich aus dem Launch mitgenommen habe: Ein funktionsreiches Solo-Projekt zu bauen und ein echtes Produkt zu betreiben sind zwei verschiedene Aufgaben.
Bei Solo-Entwicklung wurde Aufmerksamkeit zum Engpass
Während ich gebaut habe, bin ich fast vollständig aus Social Media verschwunden. Das war keine Launch-Strategie. Produktentscheidungen, Implementierung, Edge Cases, Flow-Tests und Release-Vorbereitung konkurrierten alle um dieselben begrenzten Stunden.
Diesen Teil der Solo-Entwicklung verstehe ich heute deutlich besser. Der Engpass ist nicht immer, wie schnell ich Code schreiben kann. Entscheidend ist, wie viel Aufmerksamkeit ich der wachsenden Zahl von Zuständen, Übergängen und Fehlermöglichkeiten im Produkt geben kann.
Ein erfolgreicher Build beantwortet diese Fragen nicht. Eine erfolgreiche Zahlung ebenfalls nicht.
Zahlungen haben die Bedeutung eines Bugs verändert
Vor den Zahlungen konnte ich manche Ecken noch als Dinge betrachten, die ich später repariere. Nachdem Zahlungen live waren, funktionierte dieses Denkmodell für mich nicht mehr. Ein bezahltes Produkt muss nicht bugfrei sein. Aber die Kosten eines bekannten, ungelösten Problems sind andere, wenn ein anderer Mensch dem Produkt bereits Geld anvertraut hat.
Dasselbe gilt für Onboarding und Moderation. Während der Entwicklung wirken sie leicht wie unterstützende Systeme rund um das „eigentliche“ Feature. In Produktion sind sie Teil des Features, weil Nutzer sie unmittelbar erleben. Bei Retention ist es ähnlich: Eine gute erste Session beweist noch nicht, dass das Produkt einen Grund liefert, wiederzukommen.
Die Zahlungen haben nicht bewiesen, dass das Produkt fertig war. Sie haben gezeigt, wie viel Arbeit sich hinter dem Wort „fertig“ versteckt hatte.
Der Launch lieferte eine andere Art von Information
Nach dem Release kam die weniger fotogene Arbeit: Bugs, die erst nach Veröffentlichung sichtbar werden, kaputte Flows, Moderationsprobleme, die mit echten Nutzern real werden, und Retention-Fragen, die deutlich schwieriger sind als ein guter erster Eindruck.
Ich versuche, diese Signale nicht zu überinterpretieren. Ein Bug nach dem Release bedeutet nicht automatisch, dass die Architektur schlecht ist. Ein Retention-Problem ist für sich genommen keine Diagnose des Product-Market-Fit. Ein Moderationsproblem beweist nicht, dass das gesamte System unsicher ist. Ein Symptom zeigt mir, wo ich untersuchen sollte; es erklärt nicht automatisch die Ursache.
Verändert hat sich die Qualität der Evidenz. Vor dem Launch kann ich testen, was Nutzer meiner Erwartung nach tun werden. Nach dem Launch muss ich mit dem umgehen, was sie tatsächlich tun. Ein Release ist nicht der Moment, in dem Unsicherheit verschwindet. Es ist der Moment, in dem ein Teil der wichtigsten Unsicherheit endlich beobachtbar wird.
Der Post-Launch-Loop, den ich heute nutze
Mich interessiert inzwischen die Arbeit nach dem Launch mehr als eine perfekt polierte Launch-Geschichte: Erkenntnisse aus Zahlungen, kaputte Flows, Moderationsprobleme, Nutzerverhalten, Retention-Überraschungen und die kleinen Korrekturen, die das Produkt Schritt für Schritt verlässlicher machen.
- Den echten Flow beobachten. Nicht annehmen, dass der von mir entworfene Weg genau der ist, den Nutzer tatsächlich nehmen.
- Symptome und Ursachen trennen. Ein fehlgeschlagener Schritt zeigt, wo etwas schiefging, aber nicht automatisch warum.
- Vertrauensrelevante Fehler priorisieren. Zahlungen, Zugriff, Onboarding und Moderation sind für mich dringlicher als kosmetische Unsauberkeiten, weil die Folgen eines Fehlers größer sind.
- Zuerst das kleinste bestätigte Problem beheben. Ich entferne lieber eine nachgewiesene Reibungsquelle, als ein System aufgrund einer Vermutung neu zu entwerfen.
- Nach dem Fix die Nutzererfahrung erneut prüfen. Eine Codeänderung kann technisch korrekt sein und trotzdem das Problem des Nutzers nicht lösen.
Das ist kein universelles Framework. Es ist schlicht die Arbeitsweise, die für mich seit dem Übergang vom Bauen zum Betreiben des Produkts am meisten Sinn ergibt.
Der Launch änderte meine Quelle der Wahrheit
Die wichtigste Unterscheidung ist für mich heute die zwischen das Produkt gebaut haben und bereit sein, das Produkt zu betreiben. Beim Bauen frage ich, ob das System das kann, wofür ich es entworfen habe. Beim Betrieb frage ich, was passiert, wenn echte Menschen es nutzen, missverstehen, verlassen, wiederkommen, dafür bezahlen oder einen Weg nehmen, den ich nicht erwartet habe.
Deshalb sehe ich den Launch nicht mehr als Ziellinie. Vor dem Launch stammen die meisten Hinweise aus meinen eigenen Annahmen und Tests. Danach antwortet das Produkt durch reales Verhalten, Fehler und wiederkehrende Nutzung.