You don't need NextJS: here's why

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 singl