Engineering

When a project genuinely wants Next.js

Next.js is our default for web frontends, but a default is not a reflex. Some projects are better served by plain React on Vite and React Router, and pretending otherwise would cost a client complexity they do not need. Here is how we actually decide.

What Next.js is buying you

Next.js earns its place when a project needs server-side rendering or static generation for pages that must be fast to first paint and legible to search and answer engines — marketing surfaces, content, anything where a crawler reading the served HTML matters. It brings a file-based router, server components, and a build pipeline that handles a great deal you would otherwise assemble by hand.

It also brings a coherent story for the seam between server and client — data fetching that runs where it should, output that arrives rendered rather than blank-then-hydrated. For an app whose value is partly in being found and partly in feeling instant, that is real leverage, not ceremony.

When plain React is the better call

A web app that sits entirely behind a login — a dashboard, an internal tool, an admin console — often gets nothing from server rendering, because there is nothing public to render and no crawler to satisfy. There, a Vite and React Router setup is leaner: a faster dev loop, a simpler mental model, fewer moving parts between a change and the browser.

Reaching for the heavier framework anyway is a common and quiet mistake. It adds a server runtime to reason about, a rendering boundary to respect, and a class of bugs that exist only because the boundary exists. If none of that buys the project anything, it is complexity a client pays to maintain for no return — and we would rather not sell it.

How we decide

The question we actually ask is what the pages have to do. Public, content-heavy, discovery-sensitive surfaces lean Next.js. Private, interaction-heavy, behind-auth surfaces lean plain React. Many real products are both, and then the honest answer is sometimes two front ends — a rendered marketing site and a separate app — rather than one framework strained to cover both jobs.

Koryvant's interface is built on Next.js because its public preview needs to be fast and legible; a purely internal tool we would likely build on Vite. The framework follows the requirement. If you are weighing this for your own build, our wider approach is on custom web application development.

Questions

People also ask

    Is Next.js always better than plain React?

    No. Next.js is the better call when server rendering, static generation, or search legibility matter; for an app entirely behind a login, plain React on Vite and React Router is usually leaner and simpler to maintain.

    Can one project use both?

    Yes, and often it should — a rendered, discovery-sensitive marketing site on Next.js alongside a separate behind-auth app on plain React is frequently cleaner than straining one framework to do both jobs.