The Modern Web Development Stack, Reviewed

React is the default. Next.js is the default React framework. The defaults are right because the team you hire next has used them, the libraries you need integrate with them, and the answer to "what is this" is one sentence instead of a paragraph. That is not a dismissal of Vue, Svelte or Solid. It is a statement about which lever matters most: the framework, or the team.

Choose React + Next.js unless one of these is true: the team is already strong in Vue, the product is content-heavy and Remix's data model fits, or you are building a small interactive surface that does not need a router. Otherwise, default. Move on.

This is the single highest-leverage choice a modern web team can make. TypeScript in the frontend, TypeScript in the API route handlers, TypeScript in the database queries (Prisma, Drizzle), TypeScript in the test files. The shared types flow from the data model to the UI without a translation step. The editor catches the bug before the test suite does. The new hire reads the function signature and knows what the function does.

A JavaScript codebase and a TypeScript codebase of the same size do not contain the same number of bugs. The TypeScript one has fewer, and the ones it has are caught earlier.

The cost is the slow first week as the team learns to think in types. The benefit compounds for years.

PostgreSQL is the default. It is the right default for 80% of web products because it has the best tooling, the best extension ecosystem, the most predictable performance, and the most engineers who know it. Choose it unless you have a specific reason not to.

The specific reason not to is the query pattern. If you are doing heavy full-text search, Elasticsearch is the right answer and PostgreSQL is the wrong one. If you are doing real-time analytics on event streams, ClickHouse is the right answer and PostgreSQL is the wrong one. If you are doing geospatial at scale, PostGIS on PostgreSQL is the right answer and a generic document database is the wrong one.

The choice is the query, not the language. Most web products are a relational shape with full-text and JSON bolted on, and PostgreSQL is the right answer for that.

Vercel for the Next.js app, a managed Postgres for the database, S3 for the files, GitHub Actions for the CI, a single environment variable file that is not committed. The boring deploy is right because the boring deploy is the one that does not page you at 3am. The custom Kubernetes story is right for the team that has ten engineers and the product that has a million users. For everyone else, the managed platform is the right answer.

A monorepo with five apps and three packages, on day one. A micro-frontend architecture, on day one. A custom design system, before the second product. A feature flag service, before you have features to flag. The first version of the product is one app, one database, one deploy. The second version is the same thing, plus the feature the first version is missing. The microservices, the platform engineering and the design system come when the team and the revenue justify them, not before.

If you are choosing a stack for a real product and want a second opinion, our web development team can run the review. If the question is "how do we ship this faster", our product engineering engagement is the right one.