This is the public, sanitized version of an internal proposal I wrote to move our production app off Next.js.
Next.js is the default answer to "I want to build a React app." It's a great framework.
But default and necessary aren't the same word.
The gap between them quietly cost us speed, debuggability, and a surprising amount of cross-team friction.
We were building an authenticated, data-heavy product: dashboards, filters, charts. Almost every screen lived behind a login and updated in response to clicks.
For that shape of app, server-side rendering wasn't buying us much, and it was charging us a lot.
First, the only question that matters
The right architecture depends on what you're building.
- Content-first: Marketing sites, blogs, storefronts, docs. Mostly public, SEO matters, lots of static content. SSR/SSG is a genuinely great fit. Use Next.js. Seriously.
- Application-first: Internal tools, dashboards, admin panels, SaaS consoles. Behind auth, highly interactive, bottlenecked by your API and DB — not by React rendering.
Put an application-first product on a content-first framework and you pay for machinery you never use. That was us.
What SSR actually cost us
Production debugging got harder
Server-rendered errors don't map cleanly to the components you wrote, so root-causing took longer every single time.
Client-side, the error happens in the browser with a stack trace that points at your component. Boring and fast to fix.
Server components fought our tests
You can't cleanly unit test a server component that renders other server components.
Tools like React Testing Library expect renderable elements, not the serialized output a server component produces.
We ended up making design choices purely to stay testable. Tail wagging the dog.
Authentication became a distributed-systems problem
This was a big one.
If you gate protected pages on the server, the server must read and validate the token on every request, then propagate auth state through hydration.
That single requirement gave us:
- A bigger attack surface
- Cache/isolation risk
- Cookie/CSRF complexity
- Hydration mismatches
A client-first app collapses all of this: there's exactly one place where auth happens: the API.
You can still use HttpOnly cookies; you just stop duplicating session logic across a render server and the client.
A live server is a bigger target
SSR needs an always-on server for every request: a standing surface for DDoS and more infra to run.
A static frontend ships as JS files from a CDN: one less always-on service to run and harden.
Your API is still a live server, of course. You just stop also exposing a render server.
Interactivity is a client job
Our app was filters, search, and dashboards: inherently client-side interactions.
Under SSR, managing loading states for them got harder, not easier.
We were adding complexity to make features behave the way they'd behave naturally in a SPA.
File-based routing is a constraint
Every routing change demanded a matching change in the file structure.
With a decoupled router (React Router), the route map is just code you control.
The hidden tax: cross-team complexity
Because Next.js enforces a server–client split, frontend engineers had to manage server concerns (session middleware, caching, token propagation).
The result: duplicated logic across server and client, blurred ownership of auth flows, a steeper learning curve, and slower delivery on every change.
What we moved to
A Vite-based SPA, migrated in phases to keep risk and SEO impact low:
- Prep: Move server-side logic into the client where it belonged (this alone fixed the debugging pain).
- Incremental migration: Page by page, leaving the one SEO-critical public section on Next.js for now.
- Evaluate: Audit that remaining section's SEO, then decide: Vite SSR, or keep it on Next.js where SSR earns its keep.
That last step is the honest part: we didn't declare Next.js dead. We kept it where it was the right tool and removed it everywhere it wasn't.
Along the way we swapped file-based routing for React Router, unified duplicated utilities into one client implementation, and moved to CDN hosting.
"But SEO… but initial load…"
The two real drawbacks, and why they were manageable:
- SEO: A SPA can pre-render critical pages or use dynamic meta tags. But for dashboards behind a login, SEO is a non-issue. Be honest about whether your pages even need to rank.
- Initial load: Yes, you ship more JS up front. But in data-heavy apps the slowness lives in the backend (DB queries, API latency), which users feel regardless of framework.
The decision checklist
Reach for Next.js when:
- Pages are public and SEO / social previews matter
- Cold-load first paint is a core metric
- Content is largely static or cacheable per-URL
A Vite SPA is probably enough when:
- The app is mostly behind authentication
- The value is rich, interactive, data-driven UI
- Your bottleneck is the API/DB, not rendering
- You want one place for routing, auth, and state
The takeaway
Next.js isn't the problem. Using a content-first framework for an application-first product is the problem.
SSR is powerful, and when you need it nothing comes close.
"We need React" doesn't imply "we need a server rendering it."
Ask yourself this question: what am I actually building? That decides the tool, not the default.
Made the opposite call and been glad you did? I'd genuinely like to hear where SSR earned its place for you — drop it in the comments.