Why We Build With React, Next.js and Prisma

A founder asked me last month why we default to React, Next.js, and Prisma when so many teams are moving to other frameworks. He had read three blog posts arguing the JavaScript ecosystem is collapsing, and wanted to know if we were betting on a sinking ship.

The short answer is no. The longer answer is that stack choices are not about what is trendy, they are about what you can hire for, ship with, and still maintain in five years when the founder who picked the stack has moved on. By that test, React, Next.js, and Prisma are not just defensible. They are the conservative choice.

What we are actually optimizing for

When I pick a stack, I am not picking the fastest framework or the most elegant ORM. I am picking the stack that makes the next twenty hires possible. The stack that lets a freelancer step in for two weeks when someone goes on leave. The stack that has documentation written by a thousand people, not three.

I am also picking the stack that has survived three hype cycles. That last criterion eliminates almost everything that gets posted to Hacker News on a Tuesday. The question is not is this technology good. The question is will this technology still be around, well-supported, and well-hired-for in 2031.

By that test, the JavaScript ecosystem keeps winning. Not because it is the best by any narrow measure. Because it is the broadest.

React

React is not the fastest UI library. It is not the smallest. The rendering model has rough edges, the hooks API has footguns, and server components introduced a mental model split that took the community two years to digest.

None of that matters. What matters is that every senior frontend engineer in Europe has shipped a React app. Every junior engineer learned React in their bootcamp. Every component library, every form library, every animation library, every analytics SDK ships a React adapter on day one.

When I write React, I am writing code that the next person who touches this codebase will understand within an hour. That is the only durable productivity metric.

Next.js

Next.js is more controversial than React because it is more opinionated. The App Router shipped before it was ready. The server components story confused a lot of teams. Caching is genuinely hard.

But Next.js solves the boring problems that every product hits at month six. Routing. Image optimization. Static generation for marketing pages. API routes for one-off endpoints. Middleware for auth. Edge functions for personalization. Without Next, you assemble these from a dozen libraries and write the glue yourself. With Next, you read the docs.

A framework's value is not what it lets you do. It is what it lets you stop thinking about.

For products that have both a marketing surface and an authenticated app surface, which is most products we build, Next is the only mainstream answer that handles both without compromise.

Prisma

Prisma is the part of this stack where I have the most opinions and the most exceptions.

What Prisma gets right is the migration model. Schema as code. Migrations generated and reviewed in PRs. Types flowing from the database into the application layer with no manual intervention. Onboarding a new engineer to a Prisma codebase is faster than any ORM I have used (Prisma documentation).

Where Prisma struggles is at scale, complex joins, raw query performance, edge runtimes. For most products we build, we never hit those limits. For the ones that do, we use Prisma for ninety percent of queries and drop to raw SQL for the ten percent that need it. That escape hatch is the whole reason this works.

When we don't use this stack

We do not pick React, Next, or Prisma reflexively. There are three cases where we move off-stack.

1. Hardware-adjacent products, anything talking to USB, Bluetooth, or local files at high throughput. Electron or native is usually better.
2. Heavy realtime collaboration, multiplayer editors, dense state-sync. We reach for purpose-built stacks here, not because React cannot do it, but because the realtime layer is the product and deserves its own choices.
3. Backend-heavy systems with light UI, data pipelines, ML services, anything where the UI is a thin admin panel. Python plus FastAPI plus a small React shell is often a better fit.

Everywhere else, the default holds.

The meta-point

Choosing a stack is not a technical decision. It is a hiring decision, a documentation decision, and a maintenance decision dressed up as a technical one. The stack that lets you onboard the eighth engineer in a week is the stack that lets your company grow. The stack that requires a six-month ramp because three people on earth know it is the stack that grinds to a halt the day one of them quits.

React, Next, Prisma are not the most elegant answer. They are the answer that lets the product still exist in 2031 with a team that has rotated three times since launch. That is the bet I am willing to make. Every other stack has to clear a much higher bar than we think this would be fun.