Tech-Stack-Entscheidungen für Startups: Wie du teure Fehler vermeidest

Kaum eine Entscheidung wird in frühen Startups so emotional diskutiert wie die Wahl des Tech-Stacks. Gemeint sind damit die Programmiersprachen, Frameworks und Infrastruktur-Dienste, mit denen ein Produkt gebaut wird. Entwickler:innen haben oft ausgeprägte Vorlieben, Investoren fragen manchmal danach, und im Hintergrund schwingt die Sorge mit, sich mit der falschen Wahl langfristig zu blockieren. Folgenreich sind diese Entscheidungen tatsächlich, nur meist aus anderen Gründen, als die Diskussion vermuten lässt. Dieser Artikel zeigt, wie du sie so triffst, dass sie deinem Unternehmen wirklich dienen.

Warum die Frage "welcher Stack ist der beste?" die falsche ist

Es gibt keine objektiv beste Programmiersprache und keine objektiv beste Datenbank. Es gibt nur Werkzeuge, die für bestimmte Probleme und Teams besser oder schlechter passen. Wer die Frage "Was ist der beste Stack?" stellt, bekommt fast zwangsläufig eine Antwort, die von persönlichen Vorlieben statt von den tatsächlichen Anforderungen des Unternehmens geprägt ist. Die bessere Frage lautet: "Welcher Stack lässt uns am schnellsten und mit dem geringsten Risiko dorthin kommen, wo wir in den nächsten ein bis zwei Jahren sein müssen?"

Das Konzept der Innovation Tokens

Ein hilfreiches Denkmodell dafür stammt vom Softwarearchitekten Dan McKinley und ist unter dem Begriff "Choose Boring Technology" bekannt geworden. Die Grundidee: Jedes Unternehmen hat nur eine begrenzte Menge an "Innovationstoken" zur Verfügung, also eine begrenzte Kapazität, neue, unbekannte Technologien zu lernen, zu betreiben und bei Problemen zu debuggen. Jede unerprobte Technologie, die du einsetzt, verbraucht einen dieser Token. Daraus folgt nicht, dass neue Technologien grundsätzlich vermieden werden sollten. Es folgt vielmehr, dass man sie bewusst und sparsam einsetzt, und zwar dort, wo sie tatsächlich einen Wettbewerbsvorteil bringen, und nicht bei jeder Gelegenheit.

"Langweilig" bedeutet in diesem Zusammenhang nicht schlecht, sondern gut verstanden. Die Fähigkeiten einer etablierten Technologie sind bekannt, und noch wichtiger: ihre Fehlermodi sind bekannt. Wenn ein etabliertes Datenbanksystem um drei Uhr morgens Probleme macht, gibt es zehntausende dokumentierte Lösungswege dafür. Bei einer brandneuen, aufregenden Technologie stehst du in diesem Moment oft allein da.

Typische teure Fehler bei Tech-Stack-Entscheidungen

Technologie nach Lebenslauf statt nach Bedarf wählen

Ein häufiges Muster: Ein Entwickler oder eine Entwicklerin schlägt eine Technologie vor, weil sie gerade spannend ist oder gut im eigenen Lebenslauf aussieht. Nicht, weil sie das Problem des Unternehmens am besten löst. Das ist menschlich nachvollziehbar, aber als alleinige Entscheidungsgrundlage riskant. Frag bei jedem Vorschlag konkret: Welches Problem löst diese Wahl, das eine etablierte Alternative nicht lösen würde?

Für eine Größe skalieren, die noch lange nicht erreicht ist

Viele frühe Teams bauen Architekturen, die für Millionen Nutzer:innen ausgelegt sind, obwohl sie noch keine hundert haben. Das kostet unnötig Zeit und Komplexität, die an anderer Stelle fehlt. Die Architektur sollte sich am tatsächlich absehbaren Wachstum orientieren, nicht an einer hypothetischen Zukunft.

Zu viele verschiedene Technologien gleichzeitig einführen

Jedes zusätzliche Werkzeug, sei es eine weitere Programmiersprache, eine weitere Datenbank oder ein weiteres Cloud-Tool, erhöht die Komplexität für Betrieb, Wartung und Einarbeitung neuer Teammitglieder überproportional. Ein kleines Team profitiert fast immer davon, sich auf wenige, gut beherrschte Werkzeuge zu konzentrieren.

Build-vs-Buy-Fragen ideologisch statt sachlich beantworten

Bei der Frage, ob eine Funktion selbst gebaut oder eingekauft werden soll, hilft eine einfache Faustregel: Bau selbst, was dein Produkt tatsächlich differenziert, und kauf ein, was für dich Commodity ist, also austauschbare Standardfunktionalität. Ein Zahlungsabwicklungssystem, ein Login-System oder ein E-Mail-Versanddienst sind für die allermeisten Startups keine Differenzierung, sondern Infrastruktur, die es fertig und ausgereift am Markt gibt. Wer diese Bereiche selbst baut, bindet Entwicklungskapazität, die an anderer Stelle fehlt. Und er übersieht oft, dass der laufende Betrieb einer selbstgebauten Lösung dauerhaft Aufwand erzeugt, der bei einer eingekauften Lösung entfällt.

Ein Beispiel zur Veranschaulichung

Stell dir ein Startup vor, dessen technischer Mitleiter aus Begeisterung für eine neue, noch wenig verbreitete Datenbanktechnologie das komplette Produkt darauf aufbaut. Ein Jahr später zeigt sich: Es gibt kaum Fachkräfte am Markt, die mit dieser Technologie Erfahrung haben, die Dokumentation ist lückenhaft, und ein Produktionsproblem lässt sich tagelang nicht lösen, weil es schlicht keine Community gibt, die vergleichbare Probleme schon gelöst hat. Die ursprüngliche Entscheidung war nicht bösartig. Aber sie hat ein Innovationstoken für ein Problem ausgegeben, das mit einer etablierten Lösung ebenso gut zu lösen gewesen wäre, ganz ohne das zusätzliche Risiko.

Wann Neues trotzdem die richtige Wahl ist

Das Prinzip "erst einmal langweilig" bedeutet nicht, dass neue Technologien grundsätzlich tabu sind. Wenn ein neues Werkzeug tatsächlich das zentrale Problem löst, das dein Produkt von anderen unterscheidet, etwa eine spezialisierte Datenverarbeitung, die im Kern deines Geschäftsmodells steht, dann kann sich der Einsatz eines Innovationstokens dort durchaus lohnen. Die Faustregel lautet: Setz neue, unerprobte Technologie dort ein, wo sie dir einen echten Vorteil gegenüber dem Wettbewerb verschafft, und setz etablierte, langweilige Technologie überall dort ein, wo es lediglich um solide, austauschbare Infrastruktur geht. Diese bewusste Aufteilung ist der eigentliche Kern des Konzepts, nicht ein pauschales Verbot von Innovation.

Wie du als nicht-technische:r Gründer diese Entscheidungen begleitest

Du musst den Stack nicht selbst festlegen können, aber du solltest die Begründung dahinter einfordern und verstehen können. Stell bei jeder größeren technischen Entscheidung drei Fragen: Warum diese Technologie und nicht eine etabliertere Alternative? Was passiert, wenn die Person, die diese Entscheidung trifft, das Unternehmen morgen verlässt, findet sich am Markt Ersatz mit dieser Erfahrung? Und: Löst diese Entscheidung ein Problem, das wir heute wirklich haben, oder eines, das wir vielleicht in drei Jahren haben könnten?

Wenn du unsicher bist, ob eine geplante oder bereits getroffene Tech-Stack-Entscheidung in deinem Unternehmen wirklich trägt, hilft oft eine unabhängige Zweitmeinung von jemandem, der weder am Ergebnis der eigenen Empfehlung noch am Erfolg eines bestimmten Tools hängt. Im Rahmen des Founder & CTO Sparring bringe ich genau diese Perspektive ein, praxisnah und ohne Buzzwords. Lass uns das in einem unverbindlichen Kennenlerngespräch besprechen.