24 Monate, vom Schreiben der ersten Codezeile bis zum Insolvenzantrag: Die gemeinsamen Fallstricke, die ein Architekt in 47 "totgeglaubten" Projekten entdeckt hat

Schnell zu laufen heißt nicht zwangsläufig, stabil zu laufen.

Viele Start - Ups scheitern nicht auf dem Weg des Marktkampfs und auch nicht, weil „das Geld ausgeht“, sondern daran, dass ihr Produkt nicht skalierbar ist. Sie werden von ihrem eigenen Codebestand und ihrer chaotischen Architektur gefesselt und geraten schließlich in eine Situation des langsamen Untergangs. In den letzten drei Jahren hat ein Architekturberater die Code - Basen von 47 Start - Ups untersucht, die bei Problemen mit der Skalierbarkeit ihres Produkts um Hilfe baten. Er hat erstaunlicherweise festgestellt, dass fast alle entlang derselben Zeitlinie ins Stocken geraten sind.

Technische Schulden von Start - Ups: Die Zeitlinie des Untergangs

Meir Avimelec Davidov, Gründer und CEO von Gliltech Software, kommt speziell dann ins Spiel, wenn Start - Ups in eine technische Krise geraten. Davidov hat klar gemacht, dass diese Start - Ups ihn in der Regel nicht deswegen aufsuchen, weil sie „das Geld ausgebrannt haben“, sondern wegen der Skalierbarkeitsprobleme ihrer Code - Basen und ihrer Technologiestacks: „Das Produkt lässt sich überhaupt nicht skalieren, und man weiß nicht, warum.“

Er hat festgestellt, dass in solchen Fällen das Muster des Scheiterns immer wiederkehrt, ohne Ausnahme:

Monat 1–6: Alles läuft reibungslos. Es gibt einen hohen Tempo, es werden viele Versionen veröffentlicht, die Kunden sind zufrieden und das Leben ist schön.

Monat 7–12: Die Entwicklung verlangsamt sich. Es treten seltsame Bugs auf, und „später reparieren“ wird zum Motto des Teams.

Monat 13–18: Fast jede Einbindung einer neuen Funktion beeinträchtigt drei alte Funktionen. Jede Bereitstellung wird zu einer belastenden Aufgabe.

Monat 19–24: Es werden drei weitere Ingenieure eingestellt, die sich nur um die Wartung des bestehenden Durcheinanders kümmern. Niemand arbeitet an neuen Dingen.

Nach 24 Monaten bleiben nur noch zwei Optionen: Entweder wird alles von Grund auf neu geschrieben, oder man sieht zu, wie das System langsam abstirbt.

Er kann diese Generalisierung treffen, weil die „Grundlagenprobleme“ in den 47 Code - Basen sehr ähnlich sind.

Am auffälligsten ist die Datenbankebene. „Etwa 89 % haben überhaupt keine Datenbankindizes. Überhaupt keine.” Die Applikation ist langsam, nicht wegen seltsamer Bugs, sondern weil bei jeder Anfrage 100.000 Datensätze durchsucht werden. Auch auf der Ressourcenseite ist es nicht besser. Etwa 76 % der Unternehmen haben „achtmal so viele Server“ in der Cloud bestellt, aber die durchschnittliche Auslastung liegt nur bei 13 %. „Sie zahlen für 100 Server, nutzen aber nur 13.“ Jeden Monat verbrennen sie also 3.000 bis 15.000 US - Dollar unnötig.

Auch auf der Sicherheitsebene ist es sehr schwach. Fast 70 % der Systeme haben Authentifizierungsfehler, die einen Sicherheitsexperten „Herzinfarkt“ bekommen lassen würden. Was die Qualitätssicherung betrifft, ist das oft nicht die schlechte Testabdeckung, sondern der totale Ausfall: 91 % der Teams haben keine automatisierten Tests. Deshalb ist jedes Deployment wie ein Roulettespiel, und niemand kann „mit einem Klick sicherstellen, dass nichts anderes kaputt geht“.

Wenn man die Kosten berechnet, und man geht von einem Jahresgehalt von 120.000 US - Dollar pro Ingenieur aus, zeigt eine Studie von Stripe, dass Entwickler 42 % ihrer Zeit mit schlechtem Code verbringen. Für ein Team von vier Personen bedeutet das also eine Verschwendung von über 600.000 US - Dollar in drei Jahren. Dazu kommen noch 200.000 bis 400.000 US - Dollar für die Neugestaltung und ein Einnahmeverlust von 6 bis 12 Monaten während der Neugestaltung. Der Gesamtschaden pro Unternehmen liegt also zwischen 2 und 3 Millionen US - Dollar.

Viele Gründer merken das erst im 18. bis 24. Monat. Zu diesem Zeitpunkt haben sie gerade aufgrund einer schönen Wachstumskurve die A - Runde finanziert, ohne zu merken, dass „das Wachstum auseinanderfallen wird“.

„Zwei Wochen Architekturplanung, 18 Monate Stabilität“

Was kann diese Probleme wirklich vermeiden?

Davidovs Methode ist sehr einfach: Investieren Sie am besten vor dem ersten Codezeile in die Architekturplanung - verbringen Sie zwei Wochen mit der Architekturentwicklung. Er sagt direkt: „Ich weiß, dass das langweilig ist, und Sie möchten auch schnell eine Version veröffentlichen. Aber diese zwei Wochen können Ihnen 18 Monate von Höllenqualen ersparen.“

In diesen zwei Wochen sollte man von Anfang an an die Skalierbarkeit denken. Man sollte sich zuerst fragen: „Was wird bei 10.000 Benutzern kaputt gehen?“ und nicht „Funktioniert es mit 100 Benutzern?“. Kritische Pfade wie Datenbankabfragen, Dateiuploads und Hintergrundaufgaben sollten von Tag 1 an die Kapazität für 100 - fachen Verkehr haben. Gleichzeitig sollten die automatisierten Tests von Tag 1 an laufen. Wenn man nicht „mit einem Klick“ sicherstellen kann, dass nichts anderes kaputt geht, ist jedes Deployment ein Glücksspiel. Es ist besser, „langweilige“ Technologiestacks zu wählen. React/Node/Postgres sind langweilig, aber es ist einfach, Leute zu rekrutieren, es gibt Antworten auf Stack Overflow und sie werden nicht plötzlich um 2 Uhr nachts „sterben“.

Eine externe Architekturrevision sollte schon in der ersten Woche stattfinden. Wie er sagt: „Suchen Sie in der ersten Woche jemanden, der schon solche Dinge gemacht hat, um Ihre Architektur zu prüfen. Warten Sie nicht bis zum 12. Monat, dann ist es zu spät.“

Der Grund für die frühe Planung ist ein unangenehmes, aber wahres Zitat: „Die meisten technischen Mitgründer und ersten Ingenieure können gut programmieren, aber haben noch nie eine skalierbare Architektur entworfen. Das ist so, als wären Sie ein ausgezeichneter Koch, aber hätten noch nie eine Restaurantküche während der Abendspitze geleitet.“

Das Prinzip „Bewege dich schnell und breche Dinge“ (Move fast, break things) mag in einem Unternehmen wie Facebook, das unendlich viel Geld ausgeben kann, funktionieren. Aber in Ihrem Start - Up ist es wie Selbstmord. Deshalb sollte jedes technische Team in einem Start - Up sich selbst fragen: Wo bricht das System bei zehnmal der aktuellen Benutzerzahl zusammen? Gibt es automatische Tests? Kann die Datenbank 100 - fache Abfragen bewältigen? Wenn die Benutzerzahl um das Zehnfache steigt, steigen die Infrastrukturkosten auch auf 50.000 US - Dollar pro Monat?

Wenn die Antwort auf eine dieser Fragen „Ich weiß nicht“ ist, bauen Sie Ihr Haus auf Sand.

„Die gleichen Probleme, von einem Unternehmen zum nächsten“

Obwohl die von Davidov aufgezeigten Probleme „einfach“ erscheinen (und er deswegen auch einige Einwände bekommt), stimmen viele Fachleute in den Kommentaren zu ihrer Allgemeingültigkeit.

Ein Leser sagt direkt, dass er ähnliche Arbeit wie Davidov macht und dass diese Probleme „nur die Spitze des Eisbergs“ sind, besonders seit dem Aufstieg von KI, weil jeder, der ein ähnliches Tool wie Claude Code (ein KI - Coding - Tool) nutzen kann, schnell Produkte auf den Markt bringt.

„Auf den ersten Blick sehen die Produkte gut aus, aber wenn man hineinsieht, gibt es ungetesteten Code, niemand ist für etwas verantwortlich, „Dokumentation ist nicht nötig“ und es gibt fast keine Architekturplanung.“ Er meint, dass die wertvollsten Dinge in der Softwareentwicklung oft ignoriert werden. „Forschung und Praxis sagen, man sollte sich nicht vor Tests drücken“, aber viele Start - Ups denken nicht so.

Ein anderer Entwickler gibt auch Zeugnis: „Ich habe das auch schon gesehen“.

Er hat gesehen, dass ein Unternehmen drei Jahre für ein Produkt aufgewendet hat, das in sechs Monaten fertig sein sollte, weil die ursprüngliche Planung so schlecht war, dass das fertige Produkt von Grund auf neu gemacht werden musste. Er hat auch ein Softwareprojekt gesehen, das wahrscheinlich ein Verkaufshit geworden wäre, aber das Team hat es kurz vor dem Start gestoppt - nicht wegen Marktproblemen, sondern weil die Architektur die Kosten pro Benutzer zu hoch machte. „Für die gleichen Funktionen braucht man wegen der schlechten Architektur 50 - mal so viele Server.“ Seine Zusammenfassung ist sehr realistisch:

• Es ist nicht unbedingt teurer, die Softwareentwicklung von Anfang an richtig zu machen;
• Vielleicht können drei starke Ingenieure schneller und stabiler arbeiten als 20 billige Fremdarbeiter;
• Andererseits werden „billige, aber ineffiziente“ Fremdarbeiter in einigen Jahren einen Berg an technischen Schulden aufbauen, der am Ende wertlos ist.

Einige Leute sagen, dass das einfach die Realität ist. Es kommt auf Disziplin und Grundlagenkenntnisse an.

Bruder, das ist der beste Artikel, den ich in den letzten Wochen hier gelesen habe, im Ernst - jede Zeile ist eine Narbe eines echten Gründers, nicht nur Theorie. Aber ehrlich gesagt, werden die meisten frühen Gründer nicht zuhören: Sie werden weiterhin die Funktionen mit Klebeband zusammenhalten und sagen „später refaktorieren“, und dann werden sie weinen, wenn eine zweisekündige Abfrage ihre 30.000 US - Dollar AWS - Rechnung sprengt.

Das Wahnsinnigste ist: Das ist nicht einmal eine komplizierte technische Empfehlung, sondern einfach Grundlagen und Disziplin - schreibe Tests, benenne die Tabellen richtig, füge Indizes zu den Abfragen hinzu, verfolge keine neuen, glänzenden Frameworks. Ich habe Leute gesehen, die schon bei 500 Benutzern sagen, „Wir haben Skalierbarkeitsprobleme“, aber die Wahrheit ist: Sie benutzen überhaupt keine Hintergrundaufgabenwarteschlange oder Cache - Ebene.

In den Kommentaren stellt jemand eine zentrale Frage: „Sehr gut geschrieben. Welche Rolle spielt die Stimmungscodierung in all dem? Wie viel von dem Code, das Sie jetzt prüfen, ist von KI geschrieben?“ Das ist genau der Kern der aktuellen Situation. KI hat die Schwelle für „erstmal laufen lassen“ auf ein nie dagewesenes Minimum gesenkt und den „langsamen Untergang“ auch viel früher herbeigeführt. Der von Modellen generierte Code sieht oft „funktionsfähig“ aus, aber es führt zu einer schnelleren Akkumulation von technischen Schulden und es ist schwieriger, die Qualität zu beurteilen.

Die KI hat sowohl kreative als auch zerstörerische Kräfte: Sie kann Ideen schnell in Code umwandeln, aber auch ein temporäres Gerüst für ein Fundament halten. Die Kosten werden oft erst im 18. Monat deutlich.

Referenzlink: https://old.reddit.com/r/Entrepreneur/comments/1o4jup6/i_audited_47_failed_startups_codebases_and_the/

Dieser Artikel stammt aus dem WeChat - Account „InfoQ“, Autor: Tina, veröffentlicht von 36Kr mit Genehmigung.