KISS or Die: Warum erfahrene Ingenieure bei Startups scheitern

Mein erstes Startup war ein Misserfolg, und mehrere benachbarte Startups scheiterten ebenfalls. Wir hatten: 100.000 $ in GCP-Guthaben, einen Gründungsingenieur, der Systeme in Unternehmen aufgebaut hatte, und Go-to-Market. Und wir scheiterten, nicht weil wir es falsch gebaut haben, sondern weil wir es gut gebaut haben. Das war das Problem.

Während wir Zeit damit verbrachten, mit einem scheinbar "nicht optimalen" Tech-Stack zu kämpfen, verloren wir das Wichtigste: Zeit, Momentum und strategisch eine Chance.

Diese Geschichte handelt nicht von Menschen ohne gesunden Menschenverstand. Ich hatte gesunden Menschenverstand, und wir wussten, dass wir die Dinge einfach halten sollten. Aber wenn dein mentales Modell nicht zur Situation passt, wird all dein gesunder Menschenverstand weggefegt. Du triffst "korrekte" Entscheidungen, die dich umbringen.

Dies ist auch keine Geschichte über schlechtes Engineering. Es geht darum, wie gutes Engineering Startups tötet. Wie genau die Erfahrung, die dich zum Senior macht, zu deiner größten Belastung wird. Wie "es richtig machen" oder sogar "es einfach machen" oft falsch ist.

Dieser Artikel präsentiert mentale Modelle, die dir helfen, die richtigen Entscheidungen zu treffen und die falschen zu vermeiden, die ich getroffen habe.

:::tip Für wen das ist: Senior-Ingenieure, die frühe Startups gründen oder ihnen beitreten. Wenn du 5+ Jahre in Unternehmen oder Big Tech verbracht hast, ist dies deine Warnung.

:::

\

Mentales Modell #1 - "Kostenlose" Infrastruktur ist die teuerste

100.000 $ in GCP-Guthaben scheinen ein Geschenk zu sein, aber es ist eine Falle. Es drängt dich zu Überengineering, weil "es bereits bezahlt ist." Du bekommst Recheninstanzen, Load Balancer, Container-Registries und Unternehmenstools, die ein Unternehmens-Setup erfordern. Was brauchst du? Einen "Push-to-Deploy"-Button.

Sicher, du kannst "Deploy von GitHub zu VM"-Workflows auf GCP/AWS/Azure erstellen. Einige Produkte kommen nahe heran. Aber es erfordert zusätzliche Schritte: Konfiguration von Cloud Build, Einrichtung von IAM-Rollen, Schreiben von Deployment-Skripten, Verwaltung von Geheimnissen und Konfiguration von Gesundheitschecks. Du verbrennst Zeit mit dem Aufbau von Deployment-Infrastruktur, bevor du tatsächliche Produkte bereitstellst.

In der Zwischenzeit geben dir Plattformen wie Railway oder Fly.io das, was Startups tatsächlich brauchen: eine persistente VM mit Start-and-Go-Deployment von GitHub. So einfach wie möglich: Du pushst deinen Code, und er wird bereitgestellt. Einfach eine einsatzbereite VM mit Umgebungsvariablen, SSL, Load Balancern, Logs usw. Es ist nicht "kostenlos", aber es ist bereit.

Kostenlose Guthaben drängen dich zu Überengineering, weil "es bereits bezahlt ist." Du überzeugst dich selbst, dass du Geld sparst, während du deine wertvollste Ressource ausgibst: Zeit.

\

Mentales Modell #2 - "Minimal" <> "Einfach"

Das traditionelle KISS-Prinzip sagt uns, dass wir unsere Software einfach halten sollen. Aber in Startups ist das das falsche Ziel. Du solltest nicht deine SOFTWARE einfach halten; du solltest deine LÖSUNGEN einfach halten.

Echte Einfachheit sollte am Gesamtaufwand gemessen werden, nicht an der Code-Komplexität:

Gesamtaufwand = Erstaufbau + Wartung + Debugging + Funktionserweiterung + Sicherheitsupdates + Skalierungsänderungen

Wenn du von Grund auf aufbaust, gehören dir all diese für immer. Wenn du einen Dienst nutzt, werden die meisten davon zu Null. Der "aufgeblähte" Drittanbieter-Dienst ist tatsächlich die einfache Lösung, weil er den Gesamtaufwand minimiert.

Mein OAuth-Beispiel

Unser Gründungsingenieur beschloss, OAuth von Grund auf neu zu erstellen, anstatt eine "unbekannte Bibliothek" zu verwenden. Eine Woche später reichte er einen PR ein: saubere OAuth-Implementierung mit JWT-Tokens, Refresh-Token-Rotation, Sitzungsverwaltung und rollenbasierter Zugriffskontrolle. Keine Abhängigkeiten, kein Vendor Lock-in, nur Code, den wir kontrollierten.

Ich lehnte den PR nicht ab. Und das war ein Fehler. Eine Woche Arbeit wegzuwerfen, würde die Moral zerstören. Aber es schafft Code-Komplexität und setzt es auf die falschen Schienen. Außerdem war es unser eigentlicher Fehler, den Ansatz nicht vorher zu besprechen. Wir ließen Ingenieursstolz eine strategische Entscheidung treffen.

Dann benötigte ein Kunde Microsoft OAuth und Google OAuth. Benutzerdefinierte Implementierung bedeutete Tage der Umgestaltung, Refresh-Token-Rotation, Randfälle, RBA und andere Dinge. Jede "einfache" Ergänzung erforderte ein tiefes Verständnis unserer benutzerdefinierten Authentifizierung. Jedes Sicherheitsupdate mussten wir implementieren. Jede neue Anforderung mussten wir codieren.

Prinzipien

Klassischer Fehler von Senior-Ingenieuren: Optimierung für Kontrolle statt für Ergebnisse. In Startups erfordert die Realität eine vollständige Umkehrung der Denkweise von Senior-Ingenieuren:

1. HÖRE AUF zu denken: "Das sind nur ein paar Tage Codierung" \n FANGE AN zu denken: "Das sind ein paar Tage, in denen ich NICHT mein eigentliches Produkt codiere"
2. HÖRE AUF zu denken: "Ich kann das einfach bauen" \n FANGE AN zu denken: "Ich kann das einfach lösen, indem ich nicht baue"
3. HÖRE AUF zu denken: "Drittanbieter-Dienste fügen Komplexität hinzu" \n FANGE AN zu denken: "Drittanbieter-Dienste absorbieren Komplexität"

\

\

Mentales Modell #3 - Komfort-Entscheidungen

Wir wählten Angular, weil unser Gründungsingenieur es tiefgreifend kannte. Kluge Entscheidung, oder? Nutze deine Stärken, liefere qualitativ hochwertigen Code. Das Framework war in Ordnung, ABER das Problem war sein Ökosystem.

Die Ökosystem-Falle

Angular ist hervorragend und unser Ingenieur konnte damit alles bauen.

Aber "alles" brauchte Zeit, nur um anzufangen. Die Einrichtung von Deployment, Authentifizierung und grundlegenden UI-Komponenten bedeutete endlose Konfiguration, bevor eine einzige Funktion geschrieben wurde. Während wir Angular Material-Themes debuggten, konnten (und werden) Wettbewerber Next.js + Vercel nutzen und bereits Benutzer onboarden.

Vergleiche das einfach mit dem Next.js + Vercel-Weg: Stelle am ersten Tag eine Skelett-App mit npx create-next-app bereit, füge Clerk-Authentifizierung und shadcn/ui-Komponenten hinzu, liefere am ersten Tag tatsächliche Funktionen. Gleiches Ziel, völlig unterschiedliche Reise.

Warum passiert das?

Der Unterschied liegt nicht in der Framework-Qualität, sondern in der Ökosystem-Optimierung. Next.js/React ist umgeben von Venture-finanzierten Startups, die Tools für andere Startups bauen:

• UI: shadcn/ui - kopieren, einfügen, ausliefern
• Auth: Clerk/Supabase - in Minuten konfigurieren
• Deploy: Vercel - git push entspricht Produktion
• Alles andere: Wenn Startups es brauchen, hat jemand einen Dienst gebaut

Angulars Ökosystem dient Unternehmen: leistungsstark, flexibel, unendlich anpassbar. Perfekt(?) für Teams von 50 und ein Gift für Teams von 3.

\

Mentales Modell #4 - Baue den Kern, miete den Kontext

Aber selbst mit den richtigen Werkzeugen gibt es eine letzte Falle: der Zwang, Dinge zu bauen, weil du es kannst, nicht weil du es solltest. Diese Falle tötet technisch starke Teams und mehr Startups, als wir uns vorstellen können: Dinge bauen, nach denen niemand gefragt hat, weil du es kannst, nicht weil du es solltest.

Wir haben insgesamt mindestens einen Monat mit Funktionen verbracht, die niemand brauchte. Benutzerdefiniertes OAuth, als Auth0 existierte. Eine Postgres-basierte Job-Warteschlange, als Redis + Celery existierten. Terraform von Tag eins an, als die Konsole gut funktionierte. Jede Entscheidung fühlte sich produktiv an, aber jede war Selbstsabotage, um sich realen Herausforderungen wie dem Gespräch mit Kunden oder anderer Kundenentwicklung zu stellen.

Das Muster ist einfach: Wenn Kunden dich nicht dafür wählen werden, baue es nicht.

Meine 50-Dollar-Regel

Wenn ein SaaS weniger als 50 $/Monat kostet, kannst du es dir nicht leisten, es zu bauen. Deine Zeit ist zu teuer.

Der Aufbau eines benutzerdefinierten OAuth dauert insgesamt 1-2 Wochen für Wartung und das Hinzufügen verschiedener OAuth-Anbieter. Bei Startup-Burn-Raten sind das 5.000-15.000 $ an Ingenieurzeit oder an verlorener Gelegenheitszeit. Auth0 ist kostenlos für bis zu 25.000 aktive Benutzer, dann 35 $/Monat. Du könntest Auth0 für 35 Jahre bezahlen mit dem, was es kostet, es einmal zu bauen.

Es geht also nicht um Geld, sondern um Prioritäten und Opportunitätskosten.

Ausnahme

Meiner Meinung nach solltest du nur bauen, wenn du ohne es nichts über Benutzer lernen kannst.  Ein einfaches Beispiel ist, wenn du testen musst, ob Benutzer für KI-generierte Berichte bezahlen werden. Baue die einfachste Version, die die Nachfrage beweist. Und alles andere versucht zu rutschen. Ja, überspringe Infrastruktur, überspringe "es richtig machen", überspringe Best Practices, die keine Funktionen liefern, überspringe Tests. Nochmals, sei so faul wie möglich beim Schreiben von Code.

Was ich tatsächlich verwende

• Auth: Clerk (React-native, bessere DX) oder Auth0 (B2B-fokussiert, unternehmensbereit)
• E-Mail: Resend (entwicklerorientiert) oder SendGrid (kampferprobt)
• Analytik: PostHog (kostenlos bis zur Skalierung)
• Überwachung: Sentry (unschlagbar für Fehler)
• Hosting: Cloudflare oder Vercel (wenn alles auf Next.js setzt)

Dies sind keine Empfehlungen, sondern meine eigenen, auf Geschwindigkeit optimierten Entscheidungen. Ich vermute, dein Stack wird sich unterscheiden, aber dieses Prinzip nicht.

\

\

Fazit

LLMs haben das Bauen zur Ware gemacht. Jeder Junior mit Claude kann dieses benutzerdefinierte Auth-System erstellen, auf das du so stolz bist. Dein Wert liegt nicht mehr in dem, was du bauen kannst, SONDERN darin, zu wissen, was du nicht bauen sollst.

Führung ist die Fähigkeit, Signale von Rauschen zu trennen. Wahre Seniorität bedeutet, die Disziplin zu haben, 90% dessen, was du weißt, zu ignorieren und die heutige Lösung zu liefern, nicht die Architektur von morgen.