Was kostet TypeScript-/Node.js-Entwicklung 2026? Preise, Stundensätze und die TCO-Rechnung gegen den Java-Stack

Die teuerste Position Ihres nächsten Softwareprojekts steht in keinem Angebot: die Betriebskosten der Jahre zwei bis fünf. Generische Preisübersichten wie die von xmethod nennen für Individualsoftware Spannen von 20.000 bis 250.000 € — aber keine differenziert nach Technologie-Stack, und keine rechnet Lizenzen, Supportzyklen oder Teamstruktur in die Gesamtkosten ein. Beides holen wir hier nach: zuerst unsere realen Preisspannen für TypeScript- und Node.js-Projekte, danach die TCO-Rechnung gegen den Java-Vergleichsstack — inklusive der unbequemen Antwort, wann Ihr Java-Bestand besser bleibt, wo er ist.

Preistransparenz ist für uns eine Frage des Respekts vor Ihrer Zeit: Wer ein Erstgespräch führt, soll vorher wissen, ob die Budgetgröße überhaupt passt. Für den Datenbank-Layer haben wir diese Rechnung bereits offengelegt — in Was Supabase in der Produktion wirklich kostet. Für Entwicklungsprojekte im TypeScript-Stack gelten bei uns diese Spannen:

Stand: Juli 2026. Alle Preise netto. Methodik: Die Spannen stammen aus realen, abgeschlossenen Projekten — keine Lockangebote, keine hypothetischen Musterkalkulationen.

Zwei Dinge stehen bewusst nicht in der Tabelle. Erstens: verdeckte Nebenkosten — die Spannen enthalten Projektleitung, Qualitätssicherung und Deployment, es gibt keinen zweiten Preiszettel nach Vertragsschluss. Zweitens: eine Pauschale für Integrations- und Modernisierungsprojekte, denn dort hängt der Aufwand von Ihrer Bestandslandschaft ab, und jede Zahl ohne Discovery wäre geraten statt kalkuliert.

Die häufigste Rückfrage auf eine Preistabelle lautet: Und was ist euer Stundensatz? Marktübersichten wie die von Bytefront verorten Agentur-Stundensätze für Softwareentwicklung im DACH-Raum zwischen 120 und 180 €. Die Zahl stimmt — und führt trotzdem in die Irre. Ein niedriger Satz wird teuer, wenn ein größeres Team länger braucht und mehr koordiniert werden muss. Deshalb arbeiten wir senior-first und nennen Projektpreise: Sie kaufen ein Ergebnis mit definiertem Umfang, kein Stundenkontingent mit offenem Ende. Der Festpreis verlagert das Schätzrisiko außerdem dorthin, wo es hingehört — zu denen, die die Schätzung abgeben.

Unsere Spannen gelten für den Stack, auf den wir uns festgelegt haben: TypeScript über die gesamte Anwendung, Next.js im Frontend, Node.js mit NestJS im Backend, dazu Sanity oder Supabase als Datenschicht. Ein Einwand, den wir aus CIO-Gesprächen kennen: Ist das im Backend nicht ein Exoten-Risiko? Die Zahlen sagen das Gegenteil — NestJS liegt laut npm-Statistik bei rund drei Millionen wöchentlichen Downloads und läuft produktiv unter anderem bei Adidas, Autodesk und Decathlon. Sie zahlen mit diesem Stack keinen Nischen-Aufpreis: nicht beim Bau, nicht im Betrieb und nicht bei der Nachbesetzung in drei Jahren.

Integrationsgrad: Eine Webapp, die drei Bestandssysteme anbindet, kostet mehr als eine, die auf der grünen Wiese startet. Saubere API-Verträge zum Java-Kernsystem sind planbarer Aufwand — gewachsene Punkt-zu-Punkt-Schnittstellen sind es nicht.

Compliance und Datenhaltung: Rollenmodelle, Audit-Logs, EU-Datenhaltung und Löschkonzepte gehören ins Fundament, nicht ins Nachrüstpaket. Wer sie früh spezifiziert, zahlt sie einmal statt zweimal.

Scope-Reife: Der größte Preistreiber ist Unklarheit. Ein präzises Zielbild mit priorisiertem Funktionsumfang hält ein MVP in der unteren Hälfte der Spanne; ein Projekt, das seine Anforderungen erst während der Entwicklung sucht, wandert nach oben — das gilt in jedem Stack.

Bei vergleichbarem Scope liegen die reinen Entwicklungskosten eines Java- und eines TypeScript-Projekts gar nicht dramatisch auseinander. Die Differenz entsteht danach — im Betrieb. Die vier TCO-Blöcke haben wir im TCO-Vergleich TypeScript vs. Java ausführlich hergeleitet; hier die Kurzfassung als Kostenpositionen für Ihre Fünfjahresplanung. Wir rechnen bewusst in Positionen statt in Schein-Präzision auf den Euro — denn welche Positionen überhaupt anfallen, unterscheidet die beiden Stacks stärker als jede Einzelzahl.

Oracle lizenziert Java seit 2023 nach Belegschaftsgröße, nicht nach tatsächlicher Nutzung. Laut Gartner verteuert das Per-Employee-Modell die Java-Lizenzierung um das Zwei- bis Fünffache gegenüber den alten Metriken. Als Beispielrechnung für den Mittelstand: 500 Mitarbeiter mal 15 USD pro Monat ergeben rund 90.000 USD pro Jahr — unabhängig davon, ob eine oder fünfzig Anwendungen Oracle-Java nutzen.

Das Audit-Risiko dazu ist keine Vertriebsfolklore: Laut Azul und ITAM Forum (Juli 2025) wurden 73 % der Unternehmen in den letzten drei Jahren wegen Java auditiert, und jedes vierte gibt über 500.000 USD pro Jahr für die Bereinigung von Lizenz-Non-Compliance aus. Fairerweise: OpenJDK-Distributionen eliminieren die Lizenzgebühr — laut Azul State of Java 2026 migrieren bereits 81 % der Unternehmen ganz oder teilweise weg von Oracle. Die Audit-Rückstellung bleibt trotzdem im Risikoregister, solange irgendwo im Unternehmen ein Oracle-JDK laufen könnte. Ein TypeScript-Stack kennt diese Position schlicht nicht.

Spring Boot kennt kein LTS-Modell: Jede Minor-Version erhält laut endoflife.date zwölf Monate Open-Source-Support. Die Konsequenz ist seit gut einer Woche Realität: Mit dem OSS-Ende von Boot 3.5 Ende Juni ist die gesamte 3.x-Linie ohne freie Sicherheitspatches; für das noch weit verbreitete Boot 2.7 endet der kommerzielle Tanzu-Support am 31. Dezember 2026. Jede dieser Fristen ist ein Budgetposten — Migrationssprints oder Extended-Support-Verträge, Jahr für Jahr.

Auf der Node-Seite ist derselbe Posten planbar und kostenlos: Node 24 ist die aktuelle Active-LTS-Linie mit Wartung bis zum 30. April 2028, und jede LTS-Linie erhält laut endoflife.date rund 30 Monate Support. Das ist kein Feature-Argument, sondern schlicht eine kleinere Zeile in der Betriebskostenplanung: Ein Node-Upgrade ist ein planbares Wartungsfenster pro LTS-Zyklus, kein jährlich wiederkehrendes Migrationsprojekt mit eigener Kostenstelle.

Der größte TCO-Hebel steckt im Organigramm. Ein Java-Backend braucht ein JavaScript- oder TypeScript-Frontend obendrauf — zwei Sprachwelten, zwei Rekrutierungspfade, doppelte Übergaben. Senior-Java-Entwickler kosten laut Robert Half 75.000 bis 95.000 € im Jahr, und der Talentpool verschiebt sich: Laut Stack Overflow Developer Survey 2025 nutzen 48,8 % der professionellen Entwickler TypeScript, aber nur 29,6 % Java. Ein Full-Stack-TypeScript-Team rekrutiert aus dem größeren Pool und besetzt beide Enden der Anwendung mit denselben Leuten.

Der bekannteste Beleg für diesen Effekt stammt von PayPal — wohlgemerkt aus dem Jahr 2013: Die Node-Anwendung entstand dort mit zwei statt fünf Entwicklern, mit 33 % weniger Code und doppeltem Durchsatz. Die Zahlen sind alt; der Mechanismus dahinter — kleineres Team, eine Sprache, weniger Übergaben zwischen Menschen — ist es nicht.

Wie groß der Betriebseffekt ist, zeigt eine bewusst einfache Beispielrechnung: Das Oracle-Lizenzabo eines 500-Mitarbeiter-Unternehmens von rund 90.000 USD pro Jahr summiert sich über fünf Jahre auf etwa 450.000 USD — ein Vielfaches dessen, was die Entwicklung einer kompletten produktionsreifen Webapplikation bei uns kostet, ohne dass dafür eine einzige Zeile neuer Funktionalität entsteht. Selbst wer per OpenJDK-Migration aus der Lizenz kommt, behält die zweite Kostenlinie: den Spring-Upgrade-Zyklus mit seinen Zwölf-Monats-Fenstern. Der Punkt ist nicht, dass Java-Betrieb unbezahlbar wäre. Der Punkt ist, dass diese Positionen in Angebotsvergleichen nie auftauchen — und genau dort entscheidet sich, was ein Stack wirklich kostet.

Jetzt die Gegenrechnung, die in Agentur-Blogs gern fehlt: Migration kostet ebenfalls Geld, und ein stabiles System hat seine Investition bereits verdient. In drei Situationen ist der Weiterbetrieb die bessere Rechnung. Dass wir das als TypeScript-Agentur schreiben, ist kein Widerspruch — es ist der Grund, warum Sie uns auch den Rest dieser Rechnung abnehmen können.

Der Bestand ist stabil und ändert sich kaum: Ein Kernsystem ohne aktiven Feature-Druck rechtfertigt keinen Neubau. Hier reicht meist die OpenJDK-Migration, um die Lizenzfrage zu entschärfen — der Rest darf weiterlaufen.

Der Workload ist CPU-intensiv: Unabhängige Benchmarks zeigen die JVM bei rechenintensiven Lasten 30 bis 68 % vor Node.js. Batch-Verarbeitung, Simulationen, massiv-parallele Berechnungen — das bleibt JVM-Terrain, und wer Ihnen dort einen Node-Umbau verkauft, rechnet gegen Sie.

Neues lässt sich neben dem Bestand bauen: Die teuerste Fehlentscheidung ist der Big-Bang-Rewrite eines funktionierenden Systems. Der wirtschaftlichere Weg ist meist, neue Produkte im TypeScript-Stack per API an das Java-Kernsystem anzudocken — dieses Muster haben wir in Two-Speed IT in der Praxis im Detail beschrieben.

Ich sage in Erstgesprächen öfter „bauen Sie das nicht neu“ als das Gegenteil. Ein Rewrite, der nur die Technologie tauscht und keinen messbaren Produktnutzen bringt, ist die teuerste Form von Stillstand — in beide Richtungen.

Die Tabellen oben geben Ihnen die Größenordnung; den belastbaren Preis gibt es erst, wenn Zielbild, Systemlandschaft und Zeitrahmen auf dem Tisch liegen. Genau dafür ist das Erstgespräch da: Sie bringen die Projektskizze mit, wir ordnen sie in die Spannen ein — und sagen Ihnen auch dann ehrlich Bescheid, wenn die günstigste Antwort „Java-Bestand weiterbetreiben“ lautet. Wie wir arbeiten und warum wir uns auf einen Stack festgelegt haben, steht auf unserer Seite TypeScript-Agentur — oder Sie buchen direkt ein unverbindliches 30-Minuten-Gespräch und gehen mit einer ersten realistischen Preisspanne für Ihr Projekt wieder raus.