Eine der überraschendsten Lektionen beim Aufbau eines SaaS ist für mich, dass der schwierigste Teil oft erst beginnt, wenn das Produkt schon funktioniert. Code schreiben, Features ausliefern, Bugs beheben und Updates deployen sind greifbare Aufgaben. Es gibt ein klares Problem, ein klares System und meist auch einen klaren nächsten Schritt.
Kunden zu gewinnen ist etwas völlig anderes. Distribution ist chaotischer. Positionierung ist unschärfer. Gute Botschaften brauchen Gefühl. Klicks, CTR, Retention und Conversion zwingen einen dazu, nicht nur wie ein Engineer zu denken, sondern gleichzeitig wie ein Marketer, Autor, Analyst und jemand, der menschliches Verhalten versteht.
Der Launch ist nur der Anfang
Viele Entwickler unterschätzen diesen Teil, weil Software sofort Feedback gibt. Ein Button funktioniert oder eben nicht. Ein Deployment läuft durch oder scheitert. Marketing funktioniert selten so. Man kann etwas Kluges veröffentlichen und trotzdem ignoriert werden. Man kann ein nützliches Produkt bauen und es trotzdem nicht überzeugend erklären.
Gerade als Solo-Builder ist diese Lücke frustrierend. Es fühlt sich an, als müsste man neben dem ersten Beruf noch einen zweiten von Grund auf lernen. Und genau darüber wird in ehrlichen SaaS-Gesprächen viel zu wenig gesprochen.
Distribution hat einen anderen Feedback-Loop
Dieser Unterschied ist wichtig, weil Marketing-Metriken Signale sind, keine fertigen Erklärungen. Ein Klick oder eine Veränderung der CTR zeigt mir, dass sich etwas verändert hat, sagt aber nicht automatisch, ob Zielgruppe, Kanal, Botschaft, Timing oder Produkt der Grund waren. Retention und Conversion helfen aus demselben Grund: Sie grenzen die Frage ein, beantworten sie aber nicht für mich. Die eigentliche Arbeit besteht darin, das Signal zu interpretieren und zu entscheiden, was ich als Nächstes teste.
Warum der kreative Teil schwerer wirkt
- Code belohnt Logik und Struktur.
- Distribution hängt von Aufmerksamkeit, Timing, Vertrauen und Wiederholung ab.
- Gutes Messaging klingt oft simpel, aber bis diese Einfachheit steht, braucht es viele Iterationen.
- Selbst starke AI-Tools helfen beim Coden oft schneller als bei origineller Positionierung oder wirklich natürlich klingender Kreativarbeit.
Gerade das Letzte ist im Moment fast komisch. AI ist extrem nützlich, wenn eine Aufgabe technisch und klar definiert ist. Sobald sie kreativ, nuanciert oder stark von Ton und Stimme geprägt wird, kann das Ergebnis erstaunlich unbeholfen wirken. Genau dieser Unterschied zeigt, wie wichtig menschliches Urteilsvermögen weiterhin ist.
Daraus schließe ich nicht, dass AI keine kreative Arbeit leisten kann. Mein engerer Schluss aus meiner eigenen Nutzung ist: AI lässt sich am leichtesten vertrauen, wenn die Aufgabe klar begrenzt und das Ergebnis überprüfbar ist. Für Positionierung und Tonfall gibt es kein Gegenstück zu einem Typechecker. Ich muss weiterhin selbst entscheiden, ob ein Ergebnis konkret, glaubwürdig und für die Zielgruppe passend ist.
Was „Shippen“ für mich inzwischen bedeutet
Dadurch hat sich verändert, wie ich über das Veröffentlichen eines SaaS denke. Ein Produkt kann live und technisch gesund sein, während das Distributionsproblem fast unberührt bleibt. Nach dem Launch beginnt eine zweite Schleife: erklären, für wen das Produkt ist, den richtigen Menschen helfen es zu entdecken, ihr Verhalten beobachten und sowohl Botschaft als auch Produkt anpassen. Als Solo-Entwickler konkurriert diese Arbeit um dieselbe begrenzte Aufmerksamkeit wie die Entwicklung.
Was ich vor dem nächsten Launch im Kopf behalten würde
- Kann ich klar erklären, für wen das Produkt ist und warum diese Menschen sich dafür interessieren sollten?
- Wo werden die ersten Nutzer es tatsächlich entdecken?
- Welche Signale beobachte ich – Klicks, CTR, Conversion, Retention – und was kann mir jedes davon allein nicht sagen?
- Behandle ich AI-Output als Entwurf, den ich beurteile, statt als Ersatz für mein eigenes Urteil?
Das ist keine universelle Regel
Ich behaupte nicht, dass Kundengewinnung bei jedem SaaS immer schwieriger ist als Engineering. Manche Produkte haben extreme technische Anforderungen, andere verfügen bereits über Distribution. Mein Punkt ist enger: Für einen Entwickler, der sich beim Bauen von Software sicher fühlt, kann die Arbeit nach dem Launch ein anderes Skillset und einen deutlich weniger deterministischen Feedback-Loop verlangen. In meinem Fall war genau das die größte Überraschung.
Meine praktische Schlussfolgerung ist einfach: Der Launch ist nicht die Ziellinie. Kundengewinnung, Positionierung, Messaging und Retention sind echte Fähigkeiten beim Produktbau. Sie lernen sich langsamer und lassen sich schwerer debuggen als Code, weil das Feedback deutlich verrauschter ist. Ignorieren verschwinden sie trotzdem nicht.