4 Learnings aus 4 Jahren als SaaS-Gründer und CTO

Nach meinem Ausstieg bei finvoice - zwei Übernahmen und vier Jahre später - hatte ich Zeit zum Reflektieren. Was würde ich anders machen? Was hat funktioniert, was nicht?

Vier Learnings haben sich dabei herauskristallisiert - Dinge, die mich viel Zeit, Geld und Nerven gekostet haben. Und die ich garantiert nie wieder so machen werde.

Learning 1: Vor dem Launch 1 Tag, danach 2 Wochen

Das ist die brutalste Lektion, die ich gelernt habe.

Vor dem Launch kannst du die Datenbank-Struktur an einem Nachmittag ändern. Du fährst den Server runter, migrierst die Daten, passt den Code an, testest kurz - fertig. Niemand merkt es, niemand beschwert sich.

Nach dem Launch? Die gleiche Änderung wird zum Projekt.

Du brauchst:

Eine Migration-Strategie, die keine Downtime verursacht
Backward Compatibility für alte API-Versionen
Kommunikation an Kunden über Breaking Changes
Rollback-Pläne, falls etwas schiefgeht
Monitoring, ob die Migration erfolgreich war

Was vorher ein Tag war, dauert jetzt zwei Wochen. Minimum.

Warum das so ist

Im Live-Betrieb hast du echte User mit echten Daten. Du kannst nicht "mal schnell" etwas ändern, weil:

Kunden gerade aktiv im System arbeiten
Daten nicht verloren gehen dürfen
Integrationen von Drittanbietern abhängen
Support-Tickets sofort reinkommen, wenn etwas nicht stimmt

Laut McKinsey zahlen Unternehmen 10-20% zusätzlich auf jedes Projekt, nur um bestehende technische Schulden zu adressieren. Das sind die versteckten Kosten von "machen wir später".

Fazit: Mach es vor dem Launch

Wenn du weißt, dass etwas geändert werden muss - mach es VOR dem Launch. Egal wie stressig die Timeline ist. Der Tag, den du jetzt investierst, spart dir die zwei Wochen später.

Das gilt besonders für:

Datenbank-Strukturen
API-Designs
Authentifizierung und Rollen
Zahlungslogik

Learning 2: Production Readiness von Tag 1

"CI/CD bauen wir ein, wenn wir größer sind." "Automatisierte Tests kommen später." "Quality Gates sind für Enterprise, nicht für Startups."

Das habe ich alles gesagt. Und es war alles falsch.

Was passiert, wenn du es aufschiebst

Du schiebst es auf. Immer wieder. Weil es immer etwas "Wichtigeres" gibt.

Dann hast du 50 zahlende Kunden und deployest immer noch per Hand. Du hast 200 Kunden und keine automatisierten Tests. Du hast 500 Kunden und jeder Hotfix ist ein Abenteuer.

Und dann passiert das Unvermeidliche: Ein Deploy geht schief. Um 17 Uhr am Freitag. Und du verbringst das Wochenende damit, manuell zu debuggen, was ein automatisierter Test in 30 Sekunden gefunden hätte.

Studien zeigen: Organisationen mit Test-Automation reduzieren Production-Bugs um 80%. Das ist kein Nice-to-have. Das ist der Unterschied zwischen ruhigem Schlaf und Dauerstress.

Was von Anfang an da sein muss

Automatisierte Pipeline:

Code pushen → Tests laufen → Build → Deploy
Keine manuellen Schritte, keine "ich deploye mal kurz"
Rollback mit einem Klick

Quality Gates:

Kein Merge ohne bestandene Tests
Kein Deploy ohne Code Review
Keine Exceptions, auch nicht "nur dieses eine Mal"

Basis-Tests:

Mindestens die kritischen Pfade: Login, Zahlung, Kernfunktion
Nicht perfekt, aber existent
Wachsen mit dem Produkt

Fazit: Nachziehen kostet 10x mehr

Der Aufwand, das nachträglich einzuführen, ist 10x höher als es von Anfang an zu machen. Du musst nicht nur die Infrastruktur bauen, sondern auch gegen die Gewohnheiten des Teams kämpfen. "Wir haben das doch immer so gemacht."

Von Anfang an ist es einfach wie es ist. Später ist es Change Management.

Learning 3: Keine Sonderlocken für einzelne Kunden

"Der Kunde zahlt €5.000 mehr, wenn wir dieses eine Feature einbauen." "Das ist ein strategisch wichtiger Kunde, der braucht das." "Ist ja nur eine kleine Anpassung."

Jede dieser Sonderlocken macht dein System schwerer wartbar. Jede einzelne.

Wie Sonderlocken dich auffressen

Am Anfang ist es harmlos. Ein zusätzliches Feld hier, eine spezielle Export-Funktion da. Kein Problem.

Dann hast du 10 Sonderlocken. Und plötzlich:

Jedes Update muss gegen 10 verschiedene Konfigurationen getestet werden
Bugs treten nur bei bestimmten Kunden auf
Neue Entwickler verstehen das System nicht mehr
Refactoring wird unmöglich, weil du nicht weißt, was wo gebraucht wird

Stripe's Developer Coefficient Report zeigt: Entwickler verbringen 42% ihrer Arbeitszeit mit Technical Debt und schlechtem Code. Sonderlocken sind ein Haupttreiber davon.

Die versteckten Kosten

Der Kunde, der €5.000 extra gezahlt hat? Der kostet dich langfristig €50.000 an Wartung, Bug-Fixes und verlorener Entwicklerproduktivität.

Die Rechnung geht nicht auf. Nie.

Fazit: Standard-Produkt oder gar nicht

Sonderlocken nur unter einer Bedingung: Sie werden Teil des Standard-Produkts.

Wenn ein Feature gut genug für einen Kunden ist, ist es gut genug für alle. Dann baust du es richtig ein - mit Tests, Dokumentation und als offizielle Funktion.

Wenn es nicht gut genug für alle ist, baust du es nicht ein. Auch nicht für €5.000 extra.

Learning 4: Dokumentation von Tag 1

Das ist das Learning, das mich am meisten Zeit gekostet hat.

Bei der Übergabe musste ich alles dokumentieren. Jeden Prozess. Jede Integration. Jedes "das weiß nur Marco".

Es hat 4 Monate gedauert.

Vier Monate, in denen ich Wissen aus meinem Kopf auf Papier gebracht habe. Wissen, das ich über Jahre angesammelt hatte. Wissen, das nirgendwo stand.

Warum Dokumentation aufgeschoben wird

"Ich schreib das später auf." "Das ist doch offensichtlich." "Dafür haben wir keine Zeit."

Und dann ist das Wissen in deinem Kopf. Nur in deinem Kopf. Und wenn du nicht da bist - Urlaub, krank, Exit - steht das Team im Regen.

Was dokumentiert werden muss

Prozesse:

Wie wird deployed?
Wie wird ein neuer Kunde ongeboardet?
Was passiert bei einem Incident?

Architektur:

Warum wurde X so entschieden?
Wie hängen die Services zusammen?
Welche externen Abhängigkeiten gibt es?

Wissen:

Welche Gotchas gibt es im Code?
Welche historischen Entscheidungen sind wichtig?
Was funktioniert nicht so, wie man es erwarten würde?

Der Unterschied: Sofort vs. Später

Wenn du Dokumentation sofort schreibst - direkt nach der Implementierung - dauert es 15 Minuten. Das Wissen ist frisch, die Details sind klar.

Wenn du es später schreibst - Wochen oder Monate später - dauert es Stunden. Du musst den Code wieder verstehen, dich erinnern warum du etwas so gemacht hast, Details rekonstruieren.

Und wenn du es nach Jahren schreibst, wie ich bei der Übergabe? Dann sind es Monate.

Fazit: Dokumentation ist Teil der Aufgabe

Dokumentation ist Teil der Aufgabe, nicht ein Nachgedanke.

Ein Feature ist nicht fertig, wenn der Code merged ist. Ein Feature ist fertig, wenn es dokumentiert ist. So wie ein Feature nicht fertig ist ohne Tests, ist es nicht fertig ohne Dokumentation.

Das bedeutet nicht seitenlange Prosa. Es bedeutet:

README für jeden Service
Kommentare für nicht-offensichtliche Entscheidungen
Runbooks für kritische Prozesse
ADRs (Architecture Decision Records) für wichtige Entscheidungen

Fazit: Was ich beim nächsten Mal anders mache

Diese vier Learnings kosten zusammen keinen großen Mehraufwand am Anfang. Aber sie sparen Monate am Ende.

Die Zusammenfassung:

Vor dem Launch ist alles einfacher. Ein Tag jetzt = zwei Wochen später. Nutze diese Zeit.
Production Readiness von Tag 1. CI/CD, Tests, Quality Gates. Nicht später, sofort.
Keine Sonderlocken. Features entweder für alle oder für niemanden.
Dokumentation sofort. 15 Minuten jetzt = 4 Monate später.

Das klingt nach mehr Arbeit am Anfang. Ist es auch. Aber es ist ein Bruchteil der Arbeit, die du später sparst.

Nächste Schritte

Du erkennst diese Muster? Du bist mitten im Aufbau und fragst dich, ob du auf dem richtigen Weg bist?

In einer kostenlosen Erstberatung schauen wir gemeinsam auf dein Setup. Wo stehst du bei Production Readiness? Wo lauern die Technical-Debt-Fallen?

Jetzt Erstberatung vereinbaren oder schreib mir auf LinkedIn.

Quellen: