Every new engagement, the same question: what do we build this on? For a studio our size, the only wrong answer is "it depends." So after a year of testing, we standardized on Next.js 15 for everything we ship — marketing sites, internal tools, customer portals, SaaS apps.
This looks like lock-in. It is actually the opposite.
The logic
When you pick a different framework for every project, you pay a recurring tax — mental context-switching, scattered tooling, diverging deploy pipelines, security patches you only know about in one codebase at a time. When you standardize, you invest once in the shared foundations — CI, deploy, observability, auth, RBAC, brand tokens, component library — and every new project lands on top of that foundation.
Next.js 15 specifically earned the slot because:
- App Router + React Server Components. Data fetching colocated with the page, no client bundle bloat for read-only views. This alone cut our average first-contentful-paint in half on marketing sites.
- Server Actions. The entire form-submission round-trip (validation, DB write, email send) is a typed function you call from a button. No hand-rolled API routes.
- Boring infrastructure. Deploys to AWS App Runner behind a CDK stack. No vendor lock-in at the runtime layer.
Not a framework comparison. A studio decision. If you need a React app built and maintained, this is the lane we run in.