Two-Speed IT in Practice: New Digital Products on a TypeScript Stack Alongside the Java Core System

If your next digital product can only go live once the Java core system has been modernized, it's not going live. That's not polemics — it's arithmetic: according to New Relic 2024, nearly 30 percent of all Java production applications were still running on Java 8 — a language version from 2014. That number doesn't come from a survey; it comes from telemetry across 62 million JVM instances. A backlog of that size won't be cleared in a single fiscal year, and your product roadmap can't wait that long.

The two standard answers to this dilemma are both wrong. Answer one: the big-bang rewrite — rebuild the core system from scratch and hope the market holds still for two years. Answer two: keep building new features into the legacy system, where every feature is throttled by release cycles, dependencies, and knowledge silos. There is a third way, and it's our default recommendation for new digital products next to a stable but immovable Java core: two-speed IT — the core system keeps running, new things are built alongside it on a TypeScript stack and docked on via API.

Money isn't the problem. According to the Lünendonk study 2025/26, 83 percent of DACH companies are planning higher modernization budgets for 2026, and according to Gartner, 72 percent of CIOs have declared paying down technical debt a priority for 2026 — while 60 to 80 percent of IT budgets already flow into operating and maintaining existing systems. The problem is sequencing: as long as every product idea sits in the queue behind the migration, innovation competes with maintenance for the same team, the same budget, and the same release windows. And loses.

Then there's the cadence of the Java ecosystem itself. Spring Boot has no LTS model: every minor version gets just twelve months of open-source support, and at the end of June 2026 — a few days from now — Spring Boot 3.5, the last 3.x line, drops out of OSS support, according to endoflife.date. Modernizing in place therefore doesn't mean modernizing once — it means modernizing permanently. That's not an argument against Java. It's an argument for not coupling new products to that cadence.

From a decision-maker's perspective there are three options, and each has a legitimate use case. This is how we assess them in architecture reviews:

The big-bang rewrite is almost always off the table in practice: it ties up capacity for years, delivers no visible value for a long time, and carries the highest risk of failure. The real decision is between modernizing in place and two-speed — and it hinges on a single question: Is the core system itself the product, or is it the platform that new products should build on? In the second case, two-speed wins, because it's the only option where product development and modernization don't compete for the same resources.

The underlying pattern is well established as the strangler pattern: new functionality is built as a standalone service next to the legacy system and communicates with it through defined interfaces. The core system stays untouched — no surgery on grown code, no feature freeze, no parallel operation of two complete systems. Over time, individual capabilities can migrate out of the core into new services, but that's an option, not an obligation. Two-speed is first and foremost a sequencing strategy: it decouples the speed of your product development from the speed of your modernization.

That our fast lane runs on TypeScript is not a matter of taste. Since August 2025, TypeScript has been the most-used language on GitHub according to GitHub Octoverse 2025, with 66 percent more contributors year over year — GitHub calls it the biggest language shift in more than a decade. According to the Stack Overflow Developer Survey 2025, 48.8 percent of professional developers use TypeScript; Java sits at 29.6 percent. For the greenfield lane, that means a larger talent pool, one language stack from frontend to backend, and no Oracle licensing debate in the new product. We've laid out the full cost calculation — including the cases where Java wins — in our TypeScript vs. Java TCO comparison.

The classic reference case argues at exactly this level, too: back in 2013, PayPal built its first Node application in parallel with its ongoing Java development — with two developers instead of five, 33 percent less code, and double the throughput. The case is old, but the punchline still holds: the gain wasn't raw performance — it was smaller teams and shorter time to market. Those are exactly the metrics new digital products are measured by — not requests per second.

Before a second stack becomes strategy, a warning belongs on the table. Zalando has run microservices in Java, Scala, and Node.js side by side for years — coexistence is enterprise normality, not the exception. But the Zalando engineering retrospective covering a decade of technology history also documents the flip side: six languages for similar CRUD services prevented good platform support and cost measurable productivity — the endgame was consolidation. The lesson for the mid-market: two-speed means exactly two stacks with documented responsibilities — Java for the core, TypeScript for new products. Not "every team picks its favorite framework." A deliberate two-stack strategy is the opposite of polyglot sprawl, not the beginning of it.

The new application never touches the core system's database directly. The interface is a contract: OpenAPI specification first, with typed clients generated from it on the TypeScript side. That way, every change to the core surfaces as a contract change — in code review, not as a middle-of-the-night production incident. We've described what such an integration layer in front of a legacy system looks like in practice in our guide Next.js as an integration layer for legacy systems.

The most common organizational mistake: the TypeScript team gets demoted to the Java team's "frontend supplier" — then every feature needs two backlogs, two prioritization rounds, and an escalation meeting, and within a quarter the second speed is back to being the first. What holds up is the opposite cut: one product team owns the new service end to end, from the interface to the API integration. The core-system team provides its interfaces as an internal product — versioned, documented, with a named point of contact. Two speeds need two ownerships, not a dependency chain.

For every business entity, which system is the source of truth must be settled before the project starts. Customer master data in the core, interaction and product data in the new service — that works as long as it's documented and synchronization flows in one defined direction. What reliably kills two-speed setups is shadow data: copies of core data that take on a life of their own in the new stack and that nobody can reconcile a year later. Data ownership is a governance decision, not a technical one — it belongs in the project charter, not the sprint backlog.

Honesty is part of consulting, so here are three contraindications. First: if the new product is CPU-intensive — pricing engines, simulations, massive parallel processing — physics favors the JVM: independent benchmarks show a 30 to 68 percent advantage over Node.js there, and Java 25 LTS has raised the bar further with mature virtual threads. Services like that belong on the JVM, even in a two-speed landscape. Node and TypeScript play to their strengths in I/O-heavy web and API services — which is where most customer-facing digital products actually live.

Second: if you can't operate two stacks, don't try to do it quietly. A small IT team with no experience in the Node ecosystem initially gains complexity from a second stack, not speed — in that case, an external product team is a more realistic entry point than building up parallel structures of your own. Third: if your core already runs on Java 21 and the team is well-drilled and ships in short cycles, there is simply no problem for two-speed to solve. The approach is a tool against gridlock, not an end in itself.

Getting started with two-speed isn't a strategy paper — it's a pilot project. Pick the one digital product that has waited longest on your roadmap and can be cleanly separated from the core in business terms. Define the API contract to the core system, staff a product team — and after 90 days, measure what's live. As a TypeScript agency, we build greenfield products like these with senior teams: typically as an MVP between €8,000 and €20,000, or as a full-fledged web app between €20,000 and €60,000. If you want to pressure-test whether your candidate holds up: in a free intro call, we'll walk through interfaces, data ownership, and team structure in 30 minutes.

As of June 2026. All study and support figures attributed as stated in the text; price ranges are net and depend on scope and degree of integration.