Column

Next.js runs anywhere Node runs — the hard part is knowing when "anywhere" stops being good enough. Teams pick up Next.js because it answers a specific set of problems well, and for a long stretch of a project's life it keeps answering them. The question worth asking isn't "is Next.js good," it's "is Next.js still the right fit for what we're building now."

This guide walks through what Next.js is actually built for, the use cases where it genuinely wins, and the signals that tell you it's becoming the wrong tool for the job.

What Next.js is actually solving

Next.js exists to remove the plumbing around React: routing, data fetching, rendering strategy, and the build pipeline that turns a React tree into something a browser can load fast. Before frameworks like this, teams wired up their own server-side rendering, their own code-splitting, their own route-based data loading — and most of that code looked the same from one project to the next. Next.js packages those decisions so a team can start writing product features on day one instead of reinventing a rendering pipeline.

That's the core value proposition: a React app that renders fast on first load, indexes well for search, and doesn't require a bespoke build setup. Kubo and plenty of other infrastructure products exist precisely because that value proposition holds for a huge share of web projects — the framework choice is rarely the bottleneck; what you run it on eventually is.

Where Next.js genuinely wins

Content and marketing sites. Static generation (generateStaticParams, output: 'export' where applicable) turns pages into prebuilt HTML, so a blog, docs site, or marketing page loads instantly and costs almost nothing to serve. This is the case Next.js was originally built around, and it still does it better than most general-purpose frameworks.

Mixed static/dynamic products. A SaaS dashboard with a public marketing shell and an authenticated app behind it is the canonical Next.js shape. The App Router's per-route rendering model — some routes static, some server-rendered, some client-only — lets a single codebase serve both halves without separate deployments.

Teams that want one language, one framework, for backend and frontend. API routes and Server Actions mean a small team can ship a working product without standing up a separate backend service for every feature. For an MVP or a small team's internal tool, that's a meaningful velocity win.

SEO-sensitive products. Server-side rendering and static generation solve a real problem: client-rendered single-page apps historically rendered blank pages to crawlers and slow first paints to users. Next.js's hybrid rendering model handles both without the team having to design that infrastructure themselves.

Where it starts to strain

Heavy background or long-running work. Next.js is a request/response framework at heart. Route Handlers and Server Actions run inside the same execution model as the rest of the app, with the same timeout assumptions. Video transcoding, large batch jobs, or anything that needs to run for minutes rather than seconds belongs in a separate worker process — bolting it onto a Next.js API route is a common cause of mysterious timeouts in production.

Non-HTTP protocols. Real-time features built on long-lived WebSocket or Server-Sent Events connections don't fit the serverless, per-request execution model that most Next.js hosting assumes. Teams hosting on infrastructure built around short-lived function invocations end up reaching for a separate real-time service anyway, which raises the question of why the framework needs to own that boundary at all.

Multi-service products. Once a product has more than one language, more than one database, or more than one team deploying independently, "one Next.js app" stops being an accurate description of the system — it becomes one of several services, and the framework decision is now a small part of a bigger infrastructure decision.

Cost and control at scale. Vercel's pricing model is usage-based: bandwidth, function invocations, and build minutes all meter separately. For a side project or an early-stage product, that model is close to free. For a product with sustained, high-volume traffic, the same usage-based billing that made the first year cheap can make the fifth year expensive — and the fix isn't to abandon Next.js, it's to run it somewhere with a different cost model.

The signal, not the symptom

The actual decision point usually isn't "the bill is too high" — that's the symptom. The signal is realizing that most of what you're paying for (or configuring around) is infrastructure the framework never controlled in the first place: how many replicas you run, where they're geographically placed, what happens during a traffic spike, how logs and metrics get collected. Next.js was never meant to answer those questions; a hosting platform or an orchestrator is.

This is where most teams stall: the app is ready, self-hosting works in theory, but standing up ingress, TLS certificates, autoscaling, and monitoring from scratch is its own multi-week project before a single feature ships. That gap between "we could self-host" and "we actually have a production-grade place to run this" is exactly what Kubo is built to close — standard Kubernetes underneath, with that plumbing already wired, so the workflow stays closer to a platform-as-a-service experience without tying the team to one vendor's usage-based meter.

If the product has grown into multiple services already, migrating from Docker Compose to Kubernetes is usually the more honest next step than trying to force everything back into a single Next.js deployment.

A practical checklist

Before concluding Next.js (or Vercel specifically) is the wrong fit, it's worth checking which of these is actually true for the product today:

• Request duration. Do any routes need to run longer than your hosting platform's function timeout? If yes, that work belongs in a separate process, not necessarily a separate framework.
• Connection type. Does the product need persistent connections (WebSockets, long-polling, SSE) as a core feature, not an edge case? If yes, plan for a dedicated real-time service regardless of where the frontend lives.
• Service count. Is "the app" already more than one deployable unit? If yes, the conversation isn't "Next.js vs. something else," it's "what orchestrates all of these services together" — and that's a Kubernetes-shaped question, not a framework-shaped one.
• Cost predictability. Can finance forecast next quarter's hosting bill within 20%? If the honest answer is no because billing is usage-metered, that's a hosting decision to revisit, independent of the frontend framework.
• Team structure. Does more than one team deploy to this codebase independently? If yes, the per-request execution model that makes Next.js convenient for a small team starts working against you.

None of these checklist items mean "stop using Next.js." They mean the question has shifted from "which frontend framework" to "where and how does this run in production" — and for teams that reach that second question, how many environments you actually need is usually the next thing worth getting right, alongside automating deployment with GitLab CI/CD so that shipping to those environments doesn't become its own manual chore.

The takeaway

Next.js is the right tool for a large and genuine set of problems: content sites, SEO-sensitive products, small teams that want one codebase for frontend and light backend work, and mixed static/dynamic apps. It's the wrong tool to blame when the real friction is long-running jobs, persistent connections, multi-service architecture, or a hosting bill that no longer scales the way the team expected.

If you're weighing whether to keep scaling on Vercel or move the same Next.js app somewhere with a flatter, more predictable cost model, Kubo runs standard Kubernetes underneath a workflow that's still close to what a PaaS gives you — so the framework decision and the infrastructure decision stay separate, the way they should be.