Next.js, TypeScript and Postgres as the default for web products

For most new web products I start with Next.js, TypeScript and Postgres. You write the frontend and the backend in one language, the database covers nearly everything a product needs in its first years, and plenty of developers know the stack. It is not the right answer for every product. If your company already runs on .NET, if the hard work happens in Python, or if you mainly publish content, I would pick something else.

Why the three work well together

With TypeScript on both sides, a type lives in one place. When the shape of an order changes, the compiler shows you which screens and which API routes need to follow. You find the mistake at build time, not when a customer calls.

Next.js gives you routing, server rendering and server-side logic in a single project. A small team does not have to maintain a separate API server, a separate frontend build and the glue between them. That helps most in the first year or two, while the product still changes every week.

Postgres is a deliberately boring choice. You get transactions, foreign keys and mature SQL. Flexible fields go into jsonb, and full-text search and pgvector take you a long way before you need a second database. Aleksa wrote a separate piece on that: Postgres as the default database.

What it gives your team

The stack is widely known. In the 2025 Stack Overflow Developer Survey, PostgreSQL was the most used database, among all respondents and among professional developers. React and Next.js rank high on the list of web frameworks. That makes hiring and onboarding easier. Our technology page lists the stacks our developers work with.

In this stack one developer can take a ticket from start to finish: migration, query, API and screen. That suits a small or distributed team, because there are fewer handovers between a backend group and a frontend group.

AI coding tools also do well here. Typed code and familiar conventions give the tool something to hold on to, and the compiler catches some of the mistakes such a tool makes. Milos wrote about that in stacks that work well with AI coding tools.

How I would set it up

• Turn on strict in tsconfig.json in the first commit. Switching it on later costs days.
• Validate all input at the edge: forms, route handlers and webhooks. A schema library such as Zod gives you the matching types as well.
• Use a query layer that derives types from your schema, and keep migrations in git. CI runs them; nobody runs them by hand against production.
• Keep business logic out of React components. Put it in plain TypeScript modules that your route handlers and server functions call, so you can move it to a separate service later without a rewrite.
• Send long-running work, such as exports, email and calls to external systems, to a queue with its own worker.

Next.js runs as a Node.js server with next start or in a Docker container, so you are not tied to one hosting provider. If you run more than one instance, you need a shared cache and the same encryption key for server functions on every instance. The Next.js self-hosting guide explains this. Read it before you start a second instance.

What can go wrong

Next.js moves fast. Major versions change defaults around caching and rendering, so plan time for upgrades every year and do not let them pile up.

You also need to be able to patch quickly. On 3 December 2025 the React team disclosed CVE-2025-55182, a vulnerability in React Server Components rated CVSS 10.0 that let an attacker run code on the server without logging in. Next.js was among the affected frameworks, and the fix was to upgrade. Make sure you can ship a patched version within a day, backed by tests you trust.

Watch the boundary between server and browser. Environment variables are only available on the server by default. Anything prefixed with NEXT_PUBLIC_ ends up in the JavaScript bundle, so a secret never belongs there. In code review, also check what a server component passes to a client component.

When I would choose something else

• Your organisation already runs on .NET or Java, with developers and operations built around it. Stay there and add a React frontend, as described in .NET and React for enterprise software.
• The heavy work is data or machine learning. A Python service belongs next to the web app; see Python and FastAPI for AI backends.
• It is mostly a content site with a few forms. A static site with a CMS is simpler.
• You are first of all building a mobile app. Start with the choice of mobile stack instead.

What it asks of your developers

Look for developers who take TypeScript seriously on both sides and who can read and write SQL. A strong React developer is not automatically good with databases, and you find out at the first slow query. Test it in your screening with a real query and a migration.

Sources

• Next.js: How to self-host your Next.js application
• React: Critical Security Vulnerability in React Server Components
• Stack Overflow Developer Survey 2025: Technology