Next.js, React, TypeScript: the modern web stack explained for decision-makers

Anyone who, as a managing director or owner, gathers quotations for a new website quickly comes up against a vocabulary that obscures more than it explains: React, Next.js, TypeScript, “modern stack”. Some providers carry these terms around like seals of quality, others warn against unnecessary complexity. Both are sometimes right. This text explains what lies behind the buzzwords — and for whom the effort actually pays off.

By way of classification up front: this piece appears as an advertisement. It comes from the environment of BitBau (in German), a web agency from Osnabrück that works with exactly this toolkit — Next.js, React, TypeScript. That is one perspective, not a neutral authority. All the more important, then, to name clearly the cases in which this route would be the wrong one.

Let us begin with React. React is an open-source technology for building user interfaces, originally created at Meta and today in use in countless applications large and small. The basic idea: a website is not built as a collection of individual, mutually independent pages, but out of reusable building blocks — components. A contact box, a pricing table, an image gallery is developed once and then deployed everywhere it is needed.

For clients that is more than a technical detail. Components mean consistency: the button looks the same on every page because it exists only once in the code. They mean speed when things change: if the building block is adjusted, it changes everywhere at once. And they mean lower follow-up costs, because new pages are assembled from existing parts instead of starting from zero every time.

Next.js builds on React and turns it into a complete foundation for websites. Its most important contribution: pages are assembled ready on the server, or already at the moment of publication, and reach the visitor as a fast, complete document — instead of being laboriously put together in the browser first. Added to that are built-in solutions for things that would otherwise be error-prone handiwork: image optimisation, multilingualism, clean address structures for search engines.

Why is that relevant? Because loading time is not a comfort issue. Visitors bounce when pages react sluggishly, and search engines have rated loading speed as a ranking factor for years. On the move in particular — in a mobile dead spot in the countryside, on overloaded hotel Wi-Fi — it is decided whether a page is used or closed. A foundation that makes speed the normal case rather than a subsequent optimisation pays directly into visibility and revenue.

That leaves TypeScript. Behind the unwieldy name sits an extended variant of JavaScript, the programming language of the web. The extension: the code describes precisely what form data has to take — and errors that would otherwise come to light only in the customer's browser are detected while the code is being written. You can picture it as a very strict spelling and grammar check for program logic.

The benefit shows itself less on the day of acceptance than in the years afterwards. Websites get rebuilt, extended, and at some point looked after by new people. Typed code makes such interventions safer: whoever changes one place sees immediately what elsewhere depends on it. For clients that means concretely: fewer unnoticed knock-on errors, faster onboarding of new developers and a lower risk when changing service provider, because the code documents a good part of its rules itself.

One point often overlooked in this list: all three technologies are open source and usable without licence fees. There is no vendor lock-in, but instead a large worldwide developer community that finds bugs, writes documentation and shares knowledge freely. For clients that means above all one thing: the labour market knows these tools. Anyone who one day has to or wants to change service provider will find qualified developers for React and TypeScript far more easily than for an exotic special system that only a handful of firms have mastered. The tie to a framework remains — but it is a tie to a broad standard, not to a single vendor.

So much for the strengths. Now the honest counter-calculation, because this toolkit has its price. A modern stack requires professional developers; quickly changing something in the source code yourself, as some people know it from the old home-page days, does not work. So that clients can nevertheless maintain their content themselves, an editorial system has to be connected and planned in from the outset. Publication processes and hosting, too, are more demanding than with a simple website-builder page.

Added to that is the dynamism of the ecosystem. React and Next.js develop rapidly; versions age, dependencies want updating regularly. That is no drama, but it is an operational matter: an unmaintained Next.js website ages technically faster than an unmaintained static site. Anyone without a maintenance plan also buys a permanent obligation along with the modern stack — nobody should keep quiet about that.

What such a maintenance plan concretely contains can be spelled out: regular updates of the libraries in use, prompt security fixes, occasionally a larger version jump of the framework, plus a watchful eye on the editorial system and the interfaces. What matters is less the exact rhythm than the commitment: who takes on this work, what does it cost per year, and what happens if it is left undone? These three questions belong in the quotation, not in the small print — and their answers in the contract, before the first line of code comes into being.

And finally: for many purposes all this is simply too much. A business-card website with five pages that changes twice a year needs no React. A website builder or a classic editorial system with a ready-made design fulfils the same purpose at a fraction of the cost. An agency that reflexively sells even such enquirers the big toolkit is not advising — it is selling.

So when is the modern stack worth it? A usable indicator is the question of whether the website is more of a document or more of a tool. Documents — information, pictures, contact details — need no app technology. Tools do: user accounts, dashboards, booking journeys, configurators, individual evaluations, connections to inventory management or calendars. The more a website does instead of merely showing, the more the foundation pays off.

Two examples from the agency's portfolio illustrate this category. QR2GO is a platform on which users can create QR codes and evaluate their use with analytics features; development took twenty-four weeks. ScanYou, in turn, is a tool for visual regression tests: it automatically compares screen states of websites in order to find unintended display errors after changes — sixteen weeks of development time. Both are software products with a logic of their own. In a website builder they could not have been realised.

More interesting is the third example, because it lies closer to the everyday reality of many companies: the website of the Praxis am Salzmarkt, a presence for a medical practice. At first glance a document, not a tool. What tipped the balance towards the modern stack here was the requirement to run the entire presence in three languages — with clean addresses per language and translations maintainable centrally. The support for multilingualism built into Next.js made that achievable in twelve weeks. The lesson from it: it is not the sector that decides the technology, but the concrete requirement.

Part of this weighing-up is the time factor — on both sides of the table. The projects mentioned took twelve, sixteen and twenty-four weeks, and such periods are not agency comfort but real obligations for the client too: feedback rounds want attending to, content delivering, decisions taking. A company that cannot or will not provide this collaboration over months is often more honestly served by a simpler solution — a website builder or a template-based system then delivers a result more quickly that fulfils its purpose properly. The modern stack rewards commitment; it does not replace it.

Operations are part of the foundation as well. Next.js websites typically run on specialised hosting platforms; BitBau uses Vercel infrastructure at the Frankfurt location. For clients two effects are noticeable: short loading paths for visitors in the German-speaking world, and a publication process in which every change first appears in a preview environment before it goes live. Errors are thus found before customers see them — not afterwards.

Here too the honest counter-calculation applies: such a platform is a further dependency. Next.js runs in principle on other infrastructure as well, but the convenience — preview environments for every change, automated publication, scaling without any effort of your own — is part of the package and has its running price. Anyone who would rather see operations entirely in their own hands, or with a regional provider, can do that, but then takes on tasks the platform otherwise handles. It is the same weighing-up as everywhere in the project: convenience against control, running costs against your own working time.

How does a non-technician check whether a provider has mastered the stack or only the buzzwords? Three questions help. First: “why this stack for my project — and what would the simpler alternative be?” Anyone who cannot name an alternative may not know one. Second: “how do I maintain content myself later?” The answer has to be a concrete editorial system, not evasions. Third: “what does operation cost per year, including updates?” Reputable providers have a solid answer to that.

A fourth question does no harm either: “who owns the code in the end, and where is it?” The answer should be a source-code repository to which the company itself has access — together with documentation that allows a future service provider to get started. That sounds like a detail for the event of a dispute, but it is above all an insurance for the normal case: teams change, agencies change, and a well-built website should live longer than any single business relationship.

In the overall calculation it is worth looking beyond the project price. A modern stack is usually more expensive to acquire than the simple solution, but it catches up over the lifetime: through lower change costs thanks to components, through safety in rebuilds thanks to typing, through better findability thanks to speed. Whether that calculation works out depends on how long the website is to live and how often it is to change. For a stopgap it rarely pays — for a working instrument with years ahead of it, frequently.

In the end the technology question is a business question in disguise: what is the website supposed to achieve, for how long, for whom — and who looks after it afterwards? Anyone who can answer these questions can be given a reasoned recommendation for the fitting toolkit in a technical consultation. And sometimes the reasoned recommendation is precisely this: for your case the simple solution is enough. That, too, is something one should be able to expect from a specialist firm.