Um einen Tech-Stack auszuwählen, richten Sie ihn danach aus, was das Produkt leisten muss und wie viele Menschen es in den nächsten 12 Monaten nutzen werden. Prüfen Sie dann, ob Ihr Team ihn bauen und warten kann. Der teuerste Fehler ist ein Tech-Stack, der für eine Größenordnung gebaut ist, die das Projekt vielleicht erst in Jahren erreicht.
Ein Tech-Stack ist die Gesamtheit der Technologien, auf denen Ihre Software läuft: die Programmiersprache, die Frameworks, die Datenbank und die übergreifende Architektur. Jede dieser Entscheidungen bestimmt über Jahre, wie schnell Ihr Team liefern kann. In einem Produkt, das wir geprüft haben, verbrachten vier Entwickler rund 40 % ihrer Sprintzeit damit, eine überdimensionierte Architektur für weniger als 5.000 Nutzer am Laufen zu halten.
In diesem Artikel erklären wir, wie Sie einen so kostspieligen Fehler vermeiden und wie Sie einen Tech-Stack für ein Projekt mit einem oder mehreren Teams auswählen. Außerdem zeigen wir, wie KI-Coding-Tools moderne Entwicklungsansätze beeinflussen. Am Ende wissen Sie genau, wo Sie mit der Planung Ihres eigenen Projekts beginnen. Oder Sie nehmen die Abkürzung und sehen sich direkt die Software-Produktentwicklung von Redwerk an.
Worauf es bei der Auswahl eines Tech-Stacks ankommt
Drei Entscheidungen verdienen vor Entwicklungsbeginn die meiste Aufmerksamkeit, weil sie sich später am schwersten ändern lassen:
- Programmiersprache und Haupt-Framework: Ein Framework gibt Entwicklern eine fertige Struktur für gängige Funktionen. Wer das Framework oder die Sprache wechselt, muss deshalb meist große Teile des Produkts neu schreiben.
- Monolith oder Microservices-Architektur: Ein Monolith hält das gesamte Produkt in einer einzigen Anwendung, während Microservices es in separate Programme aufteilen, die über ein Netzwerk miteinander kommunizieren. Der Wechsel von einem Modell zum anderen verändert, wie jede Funktion gebaut, getestet und ausgeliefert wird.
- Datenbank und Datenmodell: Die Datenbank enthält jedes Kundenkonto, jede Bestellung und jede Einstellung. Jahre an Live-Daten in eine andere Art von Speicher zu verschieben, ist ein eigenes Projekt, mit einem realen Risiko, Datensätze zu verlieren oder zu beschädigen.
Ein praktischer Weg, das Risiko jeder technischen Option einzuschätzen, ist die Frage, wie lange es dauern würde, einen Fehler rückgängig zu machen. Die drei oben genannten Entscheidungen lassen sich meist erst nach sechs Monaten oder mehr umkehren. Sie brauchen also eine sorgfältige Prüfung, bevor jemand Code schreibt.
Was passiert, wenn Sie den falschen Tech-Stack wählen?
Sehen wir uns ein Beispiel aus unseren eigenen Code-Reviews an, das wir zuerst in unserem Artikel über den besten SaaS-Tech-Stack beschrieben haben. Mehrere dieser Produkte hatten weniger als 5.000 aktive Nutzer und waren trotzdem als vollständiges Set von Microservices gebaut. Bei einem davon bedeutete schon eine kleine Funktion, drei separate Services zu ändern, abzustimmen, wie die Teile Daten austauschen, und spezielle Tracking-Tools zu betreiben, nur um Fehler zu finden. Das Team aus vier Entwicklern verbrachte rund 40 % seiner Sprintzeit damit, dieses Setup am Laufen zu halten, statt das Produkt zu verbessern.
Das Team hatte Microservices gewählt, damit das System künftiges Wachstum bewältigen kann, ein vernünftiges Ziel. Das Produkt brauchte diese Struktur aber noch nicht, also erzeugte die Architektur Mehraufwand ohne Nutzen für die Anwender. Wir haben den Fall als vorzeitige Optimierung eingestuft, also als das Lösen von Problemen, die es noch gar nicht gibt. Zum Glück war die Lösung klar: die Services wieder zu weniger Teilen zusammenführen.
Wenn Sie vermuten, dass Ihr aktueller Stack das Team bereits ausbremst, messen Sie das Problem, bevor Sie etwas austauschen. Ein Software-Audit zeigt, woher die Probleme kommen und wie ernst sie sind. Ob Sie danach den bestehenden Code bereinigen oder neu anfangen, hängt von wenigen Signalen ab, die unser Vergleich Refactoring vs. Rewrite erklärt. Produkte in diesem Zustand zu reparieren, gehört fest zu unserer Arbeit.
Tech-Stack auswählen für ein Projekt mit einem Team
Für ein einzelnes Team deckt der richtige Tech-Stack den Bedarf des Produkts im ersten Jahr ab und setzt auf Technologien, die die Entwickler bereits gut kennen. Um erhofftes Wachstum herum zu planen, ist dagegen riskant, denn ein Produkt mit 2.000 Nutzern braucht etwas ganz anderes als eine Plattform für zwei Millionen.
Diese Fragen helfen, die Entscheidung realistisch zu halten:
- Was muss das Produkt in den nächsten 12 Monaten leisten, und für wie viele Nutzer?
- Welche Sprachen und Frameworks setzt das Team bereits sicher ein?
- Wie leicht lassen sich in Ihrem Markt Entwickler für diese Technologie finden?
- Gibt es eine aktive Community mit gut gepflegten Bibliotheken?
- Was wäre teuer umzubauen, wenn sich das Produkt verdoppelt?
Die Personalgewinnung verdient besonderes Gewicht, denn ein Stack, den Ihre Entwickler lieben, wird zum Risiko, wenn ihn auf dem Arbeitsmarkt nur wenige beherrschen. Unser Vergleich von React und Angular bringt es auf den Punkt: “Die Stack-Entscheidung ist eine Einstellungsentscheidung mit einem Nebeneffekt im Code.”
Vorausplanen und Überdimensionieren sind zwei verschiedene Dinge, wie eines unserer eigenen Projekte zeigt. 1Amped, ein interaktiver Schaltungssimulator für Ingenieurstudierende, hatte eine ungewöhnlich schwere Aufgabe: komplexe Schaltungsberechnungen auszuführen, während die Studierenden Bauteile über den Bildschirm ziehen. Diese Berechnungen zusammen mit allem anderen abzuwickeln, hätte den Bildschirm bei jeder Simulation ruckeln lassen. Deshalb haben wir den Berechnungen eine eigene Schicht gegeben und die übrige Geschäftslogik in einem einzigen Back-End belassen. Eine solche Aufteilung lohnt sich früh, weil sie ein Problem löst, das das Produkt ab dem ersten Release hat.
Überprüfen Sie die Entscheidung, wenn sich etwas Konkretes ändert, nicht nach einem festen Zeitplan, zum Beispiel wenn ein zweites Team hinzukommt, die Nutzung sprunghaft steigt oder ein großer Kunde neue Sicherheitsanforderungen mitbringt.
Tech-Stack auswählen für Projekte mit mehreren Teams
Wenn mehrere Teams am selben Produkt arbeiten, verschiebt sich die Frage: Es geht nicht mehr darum, was ein Team am schnellsten bauen kann, sondern wie sich die Gruppen gegenseitig nicht blockieren. 1968 stellte der Programmierer Melvin Conway fest, dass Software die Kommunikationsstruktur ihrer Entwickler widerspiegelt. Ein Projekt mit mehreren Teams braucht daher eine Architektur, die zur Aufteilung der Teams passt.
Drei Faktoren wiegen in einem Setup mit mehreren Teams schwerer:
- Koordination: Wenn jedes Release die Freigabe mehrerer Teams braucht, verlangsamt sich die Auslieferung. Ein typisches Warnsignal ist ein Produktions-Deployment, für das sich vier oder mehr Personen abstimmen müssen, ohne dass jemand genau weiß, wie die Services zusammenspielen.
- Gemeinsamer Code: Teams nutzen oft dieselben Bibliotheken, internen Tools und Designkomponenten. Jedes gemeinsam genutzte Teil braucht einen benannten Verantwortlichen und klare Regeln für Änderungen, sonst bricht ein Update des einen Teams eine Funktion, die ein anderes gebaut hat.
- Verantwortungsgrenzen: Jedes Team sollte einen klar abgegrenzten Teil des Produkts besitzen, etwa die Abrechnung oder die Benutzerkonten, und Änderungen daran ausliefern können, ohne auf die anderen zu warten.
Sind mehrere Teams beteiligt, ist es sinnvoll, das Produkt in separate Services aufzuteilen, weil jeder Service einen einzigen Verantwortlichen haben kann. Klare Grenzen zwischen den Teilen sind genauso wichtig. Das haben wir beim Upgrade der EUGI-Plattform erlebt, die das Europäische Parlament nutzt. Unsere Entwickler in der Ukraine stimmten sich mit Kollegen in Italien und Belgien ab, um einen Teil des Systems innerhalb eines Monats auf einen neuen Stack zu migrieren. Diese Komponente tauschte Daten mit externen Services nach festen Vereinbarungen aus, also musste die neue Version all diese Schnittstellen unverändert erhalten. In der Ukraine geschriebener Code wurde noch am selben Tag in Brüssel getestet, und das Projekt hielt seine Frist ein.
Projekte mit mehreren Teams profitieren auch davon, den Stack klein zu halten. Jede zusätzliche Sprache bedeutet einen weiteren Recruiting-Prozess, ein weiteres Set an Tools, das gepflegt werden muss, und weniger Leute, die einspringen können, wenn ein Kollege ausfällt.
Tech-Stack im KI-Zeitalter: Sollten KI-Coding-Tools Ihre Wahl beeinflussen?
In der Stack Overflow Developer Survey 2025 gaben 84 % der Entwickler an, KI-Tools zu nutzen oder dies zu planen. Allerdings vertrauen nur 33 % der Genauigkeit dessen, was diese Tools liefern, während 46 % ihnen ausdrücklich misstrauen. Die Qualität hängt außerdem von der Programmiersprache ab, was die Leistung von KI-Tools zu einem echten Faktor bei der Auswahl Ihres Tech-Stacks macht.
SWE-bench Multilingual, ein öffentlicher Test, der misst, wie gut KI-Agenten echte Fehler in Open-Source-Projekten beheben, zeigt den Unterschied. Derselbe Agent löste 58 % der Rust-Aufgaben und 53 % der Java-Aufgaben, aber nur 35 % der JavaScript- und TypeScript-Aufgaben. Der Test nutzte ein einzelnes Modell aus dem Jahr 2025, die Zahlen werden sich also mit dem technischen Fortschritt verschieben. JavaScript und TypeScript gehören zu den am weitesten verbreiteten Sprachen, Popularität allein bestimmt die KI-Leistung also nicht.
Typisierte Sprachen helfen ebenfalls, weil Entwickler darin festlegen müssen, welche Art von Daten jedes Codestück erwartet. Dadurch fallen Fehler auf, bevor die Software läuft, auch solche, die ein KI-Assistent einbaut.
KI-Tools ändern sich alle paar Monate, ein Stack dagegen bleibt jahrelang beim Produkt. So wird etwa eine beliebte Plattform für KI-Agenten bereits von einer neueren Option abgelöst, wie unsere Analyse von OpenFang vs. OpenClaw erklärt. Eine Sprache zu wählen, weil die heutigen Assistenten gut mit ihr umgehen, würde eine langfristige Entscheidung von kurzlebigen Produkten abhängig machen. Behandeln Sie die KI-Leistung stattdessen als letzte Prüfung: Wenn zwei Sprachen gleich gut zu Ihrem Team, Ihrem Produkt und Ihrem Arbeitsmarkt passen, nehmen Sie die, mit der KI-Tools besser umgehen.
Welche Tech-Stack-Entscheidungen können warten?
Viele Entscheidungen brauchen vor der ersten Codezeile noch keine Antwort. Wer sie später mit echten Nutzungsdaten trifft, erzielt bessere Ergebnisse. Folgendes kann getrost warten:
- Entwickler-Tools für Tests, Monitoring und Deployment
- Kleinere Bibliotheken und Plugins, die jeweils eine Aufgabe erledigen
- Das KI-Modell oder der KI-Anbieter hinter einer Funktion
- Performance-Tuning für Traffic, den Sie noch nicht haben
Das KI-Modell austauschbar zu halten, ist einfacher, als es klingt. Mit einem Framework wie LangChain wird der Wechsel zwischen GPT, Claude und Gemini zu einer Konfigurationsänderung statt zu einem Neuschreiben. Wächst das Produkt, geht es als Nächstes darum, mehr Nutzer zu bedienen. Damit befassen sich die Prinzipien skalierbarer Softwarearchitektur.
Die folgende Tabelle listet gängige Tech-Stack-Entscheidungen auf, zeigt, wann jede davon eine Antwort braucht, und was ein Fehler kostet.
Programmiersprache und Haupt-Framework
Vor Entwicklungsbeginn
Große Teile des Produkts neu schreiben
Monolith oder Microservices-Architektur
Vor Entwicklungsbeginn
Ändern, wie jede Funktion gebaut und ausgeliefert wird
Datenbank und Datenmodell
Vor Entwicklungsbeginn
Eine riskante Migration von Live-Daten
Cloud-Anbieter
Vor dem Launch
Ein Migrationsprojekt und neue Tools, die erlernt werden müssen
Entwickler-Tools
Wenn der Bedarf entsteht
Ein paar Tage Einrichtung
Kleinere Bibliotheken und Plugins
Wenn der Bedarf entsteht
Austausch einer Komponente
KI-Modell oder KI-Anbieter
Sobald echte Nutzungsdaten vorliegen
Eine Konfigurationsänderung, wenn der Code es zulässt
Performance-Tuning
Wenn echter Traffic einen Engpass zeigt
Wenig, wenn der restliche Stack zum Produkt passt
Wie Redwerk Sie bei der Auswahl des Tech-Stacks unterstützt
Ein Tech-Stack, der zu Ihrem Projekt passt, lässt Ihr Team seine Zeit in die Verbesserung des Produkts stecken. Dafür treffen Sie die schwer umkehrbaren Entscheidungen mit Sorgfalt und lassen alles andere offen, bis Sie echte Informationen haben.
Die Beratung zu diesen Entscheidungen ist ein großer Teil unseres Consultings in der Software-Produktentwicklung, das auf Code beruht, den wir in über 250 Projekten gebaut und geprüft haben. Manche Kunden kommen vor Entwicklungsbeginn zu uns, andere melden sich, wenn ein Stack sie bereits auszubremsen beginnt. In beiden Fällen arbeiten sie mit Ingenieuren, die die betreffenden Technologien bereits kennen.
Für eine fachkundige Einschätzung Ihres Tech-Stacks sprechen Sie mit unseren Ingenieuren.
FAQ
Wie wählt man einen Tech-Stack für ein Projekt aus?
Um einen Tech-Stack für ein Projekt auszuwählen, führen Sie drei Prüfungen durch. Legen Sie ihn zunächst für die Nutzer und Funktionen aus, die Sie innerhalb eines Jahres erwarten. Bevorzugen Sie dann Technologien, die Ihre Entwickler bereits kennen und für die Ihr lokaler Arbeitsmarkt Fachkräfte bietet. Verwenden Sie schließlich den Großteil Ihrer Prüfzeit auf die Programmiersprache, die Architektur und die Datenbank, denn diese Teile sind am teuersten zu ersetzen.
Was ist ein Tech-Stack?
Ein Tech-Stack umfasst jede Technologie, auf die ein Softwareprodukt angewiesen ist, von dem, was Nutzer sehen, bis dorthin, wo die Daten liegen. Eine typische Web-App kombiniert ein Frontend-Framework wie React, eine serverseitige Sprache wie .NET oder Python, eine Datenbank wie PostgreSQL und eine Cloud-Plattform, die alles hostet. Der Name kommt daher, dass diese Schichten übereinander gestapelt sind.
Kann man den Tech-Stack später ändern?
Ja, und viele Produkte tun das irgendwann. Kleine Teile wie ein Test-Tool oder eine Code-Bibliothek lassen sich in wenigen Tagen ersetzen. Kernteile dauern deutlich länger: Der Wechsel zu einer anderen Programmiersprache, die Aufteilung einer Anwendung in separate Services oder die Migration jahrelanger Daten in eine neue Datenbank kann Monate an Nacharbeit bedeuten. Die Kernentscheidungen verdienen daher vor Entwicklungsbeginn besondere Sorgfalt.
Wann sind Microservices besser als ein Monolith?
Setzen Sie Microservices ein, wenn mehrere Teams ihre Arbeit unabhängig voneinander ausliefern müssen oder wenn ein Teil des Produkts eine deutlich höhere Last trägt als der Rest. Bis dahin lassen sich die meisten Produkte als eine gut organisierte Anwendung, oft Monolith genannt, leichter bauen, testen und ändern. Wer zu früh auf Microservices setzt, sorgt dafür, dass ein kleines Team einen großen Teil seiner Zeit mit der Koordination von Services verbringt statt mit der Entwicklung von Funktionen.
Wie beeinflusst KI die Wahl der Programmiersprache?
KI beeinflusst die Wahl, aber nur wenig. Laut öffentlichen Benchmarks kommen Coding-Assistenten mit manchen Programmiersprachen deutlich besser zurecht als mit anderen, daher ist die KI-Leistung ein berechtigter Faktor. Teamkompetenz, Personalgewinnung und Produktanforderungen zählen jedoch mehr, denn eine Sprache bleibt meist viele Jahre im Einsatz, während KI-Tools innerhalb von Monaten aktualisiert oder ersetzt werden. Wenn zwei Sprachen ansonsten gleichwertig sind, lassen Sie diesen Unterschied entscheiden.
Sehen Sie, wie wir AWE Learning beim Aufbau von E-Learning-SaaS geholfen haben, das von 50 % der US-Bibliotheken genutzt wird
