Der teuerste Satz in früher Softwareentwicklung lautet „das reparieren wir später“.
Die fünf Entscheidungen vorab: Dimensionieren Sie Ihren Stack für Ihre Größe statt für die von Netflix, skalieren Sie nichts, was noch nicht kaputt ist, setzen Sie KI nicht auf ein schwaches Fundament, liefern Sie keinen KI-generierten Code ohne architektonisches Urteilsvermögen aus, und machen Sie ein Audit, bevor Sie etwas hinzufügen. Jede davon kostet am ersten Tag wenig und wird im 18. Monat brutal teuer, wenn Sie sie nachrüsten müssen.
Manchmal kommt „später“ glimpflich: Das Team refaktoriert in einem ruhigen Sprint, die Migration geht live, die Codebasis entwickelt sich weiter. Häufiger kommt „später“ in der Woche, in der sich Ihr Traffic verfünffacht, Ihr bester Entwickler kündigt, ein Käufer ein Code-Audit verlangt oder ein angeflanschtes KI-Feature unter echter Last zusammenbricht. Dann kostet „später reparieren“ vier Monate und eine Finanzierungsrunde.
Jedes Startup, mit dem wir gearbeitet haben und das seine Wachstumsphase überlebt hat, hat dieselben fünf Architekturentscheidungen früh getroffen. Die anderen kamen meist 18 Monate später zu uns und baten uns, neu zu bauen, was sie hatten, nur diesmal unter dem Druck einer Runway, die eigentlich ins Wachstum hätte fließen sollen.
Hier sind die fünf Entscheidungen, in der Reihenfolge, in der sie typischerweise zubeißen.
1. Wählen Sie Ihren Tech-Stack für Ihre Größe, nicht für die von Netflix
Gründer kopieren, was Big Tech einsetzt, und machen dabei ihr eigenes Produkt kaputt. Netflix läuft auf Java, Go, Cassandra und einer Flotte maßgeschneiderter verteilter Systeme, weil Netflix 250 Mio. Nutzer und 8.000 Entwickler hat. Sie haben drei Nutzer und stellen gerade Entwickler Nr. 4 ein. Der Stack, der auf 100 Mio. Nutzer skaliert, bringt Sie auf null, bevor Sie 1.000 erreichen.
Die drei echten Fragen in der Frühphase:
- Wie schnell können Sie auf diesem Stack bauen und ändern? Geschwindigkeit ist die einzige Kennzahl, die zählt, bis Sie Product-Market-Fit gefunden haben.
- Wie leicht finden Sie Entwickler für diesen Stack? Die Vorlieben Ihres ersten Entwicklers werden zur dauerhaften Architektur Ihres Unternehmens, wenn Sie es zulassen.
- Wächst der Stack mit Ihnen für die nächsten zwei Jahre, nicht die nächsten zehn? Sie werden ohnehin neu architekturieren, wenn Sie relevante Größenschwellen überschreiten. Bezahlen Sie nicht im Voraus für ein Problem, das Sie vielleicht nie haben werden.
Für die meisten B2B-SaaS- und KI-Produkte in dieser Phase ist die richtige Antwort unmodern: TypeScript auf Node, React im Frontend, Postgres als Datenbank, dazu eine kleine Zahl gut verstandener Dienste für Queues und Suche. Das ist nicht aufregend. Es ist der Stack, der Sie nicht bremst, und nur dieser Stack zählt.
2. Skalieren Sie nichts, was noch nicht kaputt ist
„Wir müssen skalieren“ ist der zweitteuerste Satz in Startups, und er fällt fast immer, bevor Skalierung das eigentliche Problem ist.
Teams führen Microservices ein, bevor sie Product-Market-Fit haben. Sie migrieren auf Kubernetes, wenn eine gut abgestimmte VM reichen würde. Sie stellen drei weitere Entwickler ein, wenn der Engpass eine einzige Datenbankabfrage ist, die 12 Sekunden dauert.
Bei Skalierung geht es nicht darum, sich auf Millionen Nutzer vorzubereiten, die Sie nicht haben. Es geht darum, unter den Nutzern, die Sie bereits haben, nicht zusammenzubrechen. Die besten Architekturentscheidungen, die wir für Kunden getroffen haben, haben fast immer Schichten entfernt statt hinzugefügt. Weniger Dienste. Einfachere Deployments. Weniger clever, dafür zuverlässiger.
Wenn Ihr System mit jedem neuen Teammitglied langsamer wird, liegt der Engpass nicht in Ihrer Infrastruktur. Er liegt in den Entscheidungen, die sie geformt haben.
3. Setzen Sie KI nicht auf ein kaputtes Fundament
Das ist der häufigste Architekturfehler der Jahre 2025 und 2026.
KI-Features werden in Codebasen gezwängt, die dafür nie gebaut wurden: Vektordatenbanken mit Klebeband an Monolithen befestigt, LLM-Aufrufe in synchrone Request-Zyklen eingebettet, Prompt-Logik über 15 Microservices verstreut, ohne Observability, ohne Caching, ohne Fallback.
Das Ergebnis ist ein Produkt, das in der Demo glänzt und unter echtem Traffic zusammenbricht. Die Token-Kosten explodieren. Die P99-Latenz kennt keine Grenze mehr. Ihr Team verbringt mehr Zeit mit Brandbekämpfung als mit Ausliefern.
Die unbequeme Wahrheit: KI behebt keine Architekturschulden. Sie vervielfacht sie.
Die Startups, die gerade mit KI gewinnen, sind nicht die mit den ausgefallensten Modellen. Es sind die mit sauberen Datenpipelines, Async-First-Architekturen, Observability bei jedem Modellaufruf und Systemen, die ausdrücklich darauf ausgelegt sind, sich mit den zugrunde liegenden Modellen weiterzuentwickeln. Stimmt dieses Fundament, wird KI zum Multiplikator. Überspringen Sie es, wird KI zur teuersten Verbindlichkeit in Ihrer Bilanz.
Ausführlicher haben wir das in KI ist ein Multiplikator, keine Lösung behandelt.
4. KI-generierter Code ohne architektonisches Urteilsvermögen ist eine Bombe mit 3-Monats-Zünder
Ein benachbarter Fehler mit etwas anderer Form: Teams liefern mit KI-generiertem Code in wenigen Wochen ein MVP aus. Drei Monate später ertrinken sie in technischen Schulden, die Datenbank hält die Last nicht aus, jedes neue Feature macht zwei alte kaputt, und der Gründer fragt sich, warum die Geschwindigkeit eingebrochen ist.
Das Problem war nie das Tempo. Es war das Fehlen einer architektonischen Absicht.
KI-generierter Code ist hervorragend darin, die fünfzigste Umsetzung eines bekannten Musters zu liefern. Er ist schlecht darin, das richtige Muster für Ihr konkretes Datenmodell, Ihr konkretes Lastprofil und Ihre konkreten Compliance-Vorgaben auszuwählen. Er baut Ihnen bereitwillig ein System, das für die Demo funktioniert und unter echten Nutzern zerbröselt, weil er keine Vorstellung von Ihren echten Nutzern hat.
Die Lösung ist nicht, KI aus dem Entwicklungsprozess zu verbannen. Die Lösung ist, jeder Entscheidung auf Systemebene erfahrenes architektonisches Urteilsvermögen voranzustellen und die KI die Umsetzung unter diesem Urteil erledigen zu lassen, nicht an seiner Stelle.
5. Erst prüfen, dann hinzufügen
Die Arbeitsstunde mit der größten Hebelwirkung in den meisten frühen Codebasen ist nicht das Schreiben von neuem Code. Es ist, den bestehenden Code so sorgfältig zu lesen, dass man versteht, welche Entscheidungen tragend sind und welche Zufälle, die sich aufschaukeln werden.
Jedes Mandat bei WeAreFabbrik beginnt mit einem Codebasis-Audit, bevor wir eine einzige neue Zeile schreiben. Dieses Audit fördert immer wieder dieselben Muster zutage:
- Eine einzelne Datenbankabfrage, die für 60 % der P95-Latenz verantwortlich ist
- Authentifizierungslogik, an drei Stellen geforkt, mit subtil unterschiedlichem Verhalten
- Ein „temporärer“ Worker-Prozess, der seit zwei Jahren in Produktion läuft
- Konfigurationswerte, die in sieben Dateien hartcodiert sind, weil die ursprüngliche
config.js„später aufgeräumt werden sollte“
Keines dieser Probleme ist exotisch. Alle sind betrieblicher Natur. Alle lassen sich früh günstig beheben und spät nur ruinös.
Was kostet es, diese Entscheidungen zu überspringen?
Das Muster, das wir immer wieder sehen:
- Die günstige Abkürzung im Monat 0 spart 30.000 €
- Aufgelaufene Kosten zwischen Monat 6 und Monat 18: rund 200.000 € an Engineering-Zeit für Brandbekämpfung statt Ausliefern
- Neubau im Monat 18: 150.000 € und ein Roadmap-Neustart von sechs Monaten
Die Abkürzung hat nichts gespart. Sie hat 30.000 € geliehen und 350.000 € plus eine Finanzierungsrunde zurückgezahlt.
Die echten Kosten von Software sind nicht, was Sie für ihren Bau bezahlen. Es ist, was Sie bezahlen, wenn sie kaputtgeht, und worauf Sie verzichten, während Sie sie neu bauen.
Treffen Sie die Architekturentscheidungen früh richtig
Wenn Sie ein finanzierter Gründer sind, ein CTO, der eine Codebasis übernimmt, oder ein Board-Mitglied, das verstehen will, ob der vorgelegte Engineering-Plan glaubwürdig ist, buchen Sie ein 30-minütiges Strategiegespräch. Wir geben Ihnen eine belastbare Einschätzung, welche dieser fünf Entscheidungen funktionieren und welche Sie bald Geld kosten werden, bevor es so weit ist.
Sie können sich auch das dreiphasige Zusammenarbeitsmodell ansehen, mit dem wir Projekte vom Blueprint über den Build bis zur laufenden Skalierung führen.
Über den Autor: Konstantinos Tsolakidis ist Gründer von WeAreFabbrik und arbeitet als Fractional CTO für finanzierte Startups und PE-finanzierte Scale-ups in ganz Europa. WeAreFabbrik ist ein Senior-Engineering-Team mit Sitz in Athen und Tallinn, das seit 2018 über 50 KI-, SaaS- und Automatisierungsprodukte ausgeliefert hat.