Next.js development
If you already use React, Next.js is not a different library. It is a decision about where each page is rendered, what gets cached, and who operates the server that now exists. Those are the questions worth ten minutes.
01Capabilities
Where choosing per route changes the product
React is the library and this page is the layer above it: rendering, routing, caching and hosting. The work below is where that layer changes the outcome rather than just the folder structure.
- Hybrid
Products with a public surface and an app behind it
A marketing surface that has to be found and indexed, plus an application behind a login, in one codebase with a different rendering strategy for each. Splitting them into two projects is the alternative, and it usually means two design systems within a year. Both halves are one web build.
- Rebuilds
SaaS platform rebuilds
Replacing an application that renders entirely in the browser and has become slow to load and awkward to change, including data-heavy products in energy and sustainability. Rendering on the server is often what removes the loading spinner, not more work in the browser.
- Scale
Content-driven product pages at scale
Hundreds or thousands of generated pages from a CMS or a database, built at deploy time or refreshed on a schedule, where first paint and being indexable both decide whether the page is worth having. Built under an ISO 27001:2022 certified information-security management system.
- Handlers
The API layer next to the interface
Route handlers doing session work, form handling and calls out to internal services, so the browser is not talking directly to five systems. Anything long-running belongs in a real service behind it, on Node.js or elsewhere.
02Case studies
The rebuild these choices came out of
One published rebuild: a climate-tech SaaS platform, taken off a browser-rendered front end.
See all case studies
03Fit
When the extra server is not worth running
The React page puts it correctly: the question is really about rendering strategy and hosting, and this page is where that question gets answered. Next.js is our default when a product has public pages worth indexing, and a poor default when it does not, because you take on a server and a cache that somebody then has to operate. Four of the six rows below send the work somewhere other than a Next.js project with us, and two of those send it nowhere near us at all.
| Your situation | What we recommend |
|---|---|
| Public product pages where first paint and search visibility both matter | Use Next.jsThis is the case it earns. Mixing built-ahead, per-request and browser-rendered routes in one project is the actual advantage. |
| An application entirely behind a login, with no public pages at all | We argue againstPlain React served as static files. A server buys you nothing here and adds something somebody has to run at 3am. |
| Mostly content, with very little for the reader to interact with | Do lessA static site build, or pages served by whatever already holds your content. This is more machinery than the problem deserves. |
| A team already productive in Vue | Different pageDo not switch frameworks over this. Vue has the same server-rendering answer in its own ecosystem, and your people already know it. |
| Heavy background jobs, queues or long-running processing | Different pageNot in a web framework. That belongs in a service with its own lifecycle, see Node.js, with the pages calling it. |
| A hard requirement to run it inside your own network | Decide that firstPossible, and worth settling before you build. Image handling and scheduled refreshes cost real extra work off the platforms designed for them. |
Scope
What we own is the rendering and caching model and what it costs you later. Which routes are built ahead of time. Which are built per request. What a reader sees when the cache and the database disagree. All of it written down, because these choices are invisible in the code and expensive to reverse. unicrew has been building web products since 2012, with 100+ senior in-house engineers across six countries, under an ISO 27001:2022 certified information-security management system.
The rendering decision is a per-page one and teams keep making it once for the whole product. A marketing page and a logged-in dashboard have opposite needs, and a framework that lets you choose per route is only useful if somebody actually chooses. When we inherit a slow Next application, the cause is almost always that everything was rendered the same way.
Andrii BurdaSenior Engineering Manager, unicrew04Delivery
Four calls we make before route one
Four decisions we make early, because retrofitting any of them means touching every route.
- Decide the rendering strategy per routeBuilt ahead of time, rendered per request, or refreshed on a schedule, chosen route by route and written down with the reason. Inheriting this from a starter template is how products end up rendering a dashboard on a server for no reason.
- Fix the data-fetching and caching boundaryWhere data is fetched, what is cached, and how a cache is cleared when something changes. This is the single largest source of both speed and stale-data bugs in a Next.js codebase.
- Prove the hosting target earlyA managed platform or your own infrastructure, decided and deployed in the first weeks with images, redirects and middleware exercised. Hosting surprises here arrive late, and they arrive as architecture changes.
- Measure real routes, not lab scoresPerformance data from the routes users actually hit, on the devices they actually have. A perfect score on a synthetic test and a slow product are entirely compatible. Test automation goes in alongside, through the same QA practice as our own projects.
05Stack
What sits behind the pages
The decisions that arrive with this one, each with a page of its own.
06Questions
What people want settled before the first sprint
Answered the way we would answer them live. If yours is not here, it is a good first message.
Yes, and on a product you already own it is often the sensible shape. What we will not do is take the framework as given and stay quiet about the rendering model, because that is where these projects go wrong. An architect outside the delivery team reviews the rendering and caching design, and the work goes through the same QA practice as ours. Team extension is managed teams; the outcome is web development.
Routing, server rendering, a build and caching pipeline, and a place to put server-side code next to the interface. It does not change how you write components. The practical difference is that a page can be rendered before it reaches the browser, which is what makes it indexable and what removes the empty first paint. It also adds a server and a cache to the things you operate, so it is a real trade rather than a free upgrade.
The rule we use: if the content is the same for everyone and changes rarely, build it ahead of time. If it is the same for everyone but changes often, build it ahead and refresh on a schedule. If it depends on who is asking, render per request. If it depends on interaction and nobody outside needs to read it, render in the browser. Most products need three of those four.
Yes, as a Node process or in a container, and plenty of products do. Image handling, scheduled refreshes and edge middleware are the features that cost extra work when you run them yourself, and that cost lands on whoever operates it. We would rather agree the hosting target in the first week than discover it during a launch. Our DevOps practice owns that side when we run it.
A scoping call with an engineer rather than a salesperson. For an existing app we want repository access and, if you have it, real performance data from users, because a chain of blocking requests shows up in minutes and cannot be described in a meeting. You get back a written read on the strategy per route, the caching model, and what we would change first. Most engagements start within two to four weeks.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we only offer it once the first read is done, because a fixed number on a system nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Picking a strategy, or fixing one?
Tell us what is public, what is behind a login, and where it has to run. You will get a straight recommendation on the rendering strategy, including the case where plain React is the better answer.