Why We Reach for Next.js (and When We Don't)

Every studio has a default. The tool it reaches for when a new project lands and nobody has argued about the stack yet. Ours is Next.js, and it has been for a while.

That is not a fashion statement. It is a decision we have made a few hundred times over, and it holds up more often than not. But a default is only useful if you know when to break it, so this piece is both halves: why we lean on Next.js, and the projects where we quietly put it back on the shelf and reach for something else.

We are a small team. That shapes everything. We cannot afford to relearn a new set of tools for every client, and we cannot afford to ship something we will be scared to touch in a year. A sensible default buys us both speed and calm.

What Next.js actually gives us

The honest headline is rendering flexibility. Most frameworks pick one way to build a page and make you live with it. Next.js lets us decide per page. A marketing page can be built ahead of time and served as a plain static file, fast and cheap. A dashboard behind a login can render on the server on every request. A product page can be built once, then quietly refreshed in the background when the data changes. Same codebase, three different strategies, chosen where each one fits.

That matters because real sites are mixtures. A brand site usually has a fast static front, a blog that updates now and then, and maybe one logged-in area. Picking a single rendering mode for all of it is a compromise. Picking per page is not.

Then there is the boring win that turns out to matter most: one language across the whole stack. The page, the little bit of interactivity on it, and the small server function behind it are all JavaScript or TypeScript. Nobody context-switches between a front-end language and a separate back-end one for a simple contact form. For a small team, that is not a luxury, it is the difference between shipping this week and shipping next month.

Speed is the third reason, and it is not vanity. Pages built ahead of time load close to instantly, and the framework does a lot of the fiddly work of sending only the code a page needs. We wrote separately about what actually makes software feel fast, and a lot of it is exactly this kind of default that you get without having to be a hero about it.

Two more, quickly, because they decide real projects:

• Hiring and handoff. React is the most common front-end skill on earth, so a client is never locked to us. Any competent developer can pick up where we left off.
• Ecosystem. Auth, payments, content, image handling. The paths are well worn, which means fewer nasty surprises at 11pm before a launch.

None of these are magic. They are just a stack of sensible things that add up, and rarely fight each other.

The renderer shift under all of this

There is a quieter reason we are comfortable betting on it. The whole industry has been drifting back toward doing work on the server, after a decade of pushing everything into the browser. Next.js sits right on that shift, which is why it can offer per-page choices in the first place.

We think that drift is healthy, and we made the case in the quiet return of server-side rendering. Betting on a tool that matches where the craft is heading, rather than where it was in 2018, is part of why the default feels safe rather than trendy.

When we don't reach for it

Here is the part most Next.js articles skip, and the part that actually earns trust.

A plain brochure site is the clearest case. Five pages, a bit of copy, some photos, contact details, no login and nothing that changes daily. Next.js will build that fine, but a lighter static generator like Astro, or honestly plain HTML, will do it with less machinery to maintain. Fewer moving parts is a feature when the site barely moves. We do not add a framework to a project that is asking for a poster.

Content-heavy sites where a non-technical person publishes constantly are the second case. If someone on the client's side needs to log in, write, and hit publish several times a week without a developer in the loop, WordPress is often the kinder answer. We are not precious about it. We wrote a whole comparison on Next.js versus WordPress for a small brand, and the answer there is genuinely "it depends", not "use ours".

A tiny landing page is the third. One page, one form, one deadline. Reaching for a full framework there is like renting a moving truck to carry a chair. A single hand-built page loads faster, costs almost nothing, and ships in an afternoon.

And then there is native mobile. If the core of the project is an app that has to feel truly native, use the camera and sensors properly, and live in an app store, a web framework is the wrong starting point no matter how good it is. That is a job for React Native or the platform's own tools. We would rather say so on day one than force a website to pretend to be an app.

The thread through all four: the tool has to match the shape of the work, not the habits of the team building it. A default that you never question stops being a judgment and becomes a reflex, and reflexes ship the wrong thing.

The honest summary

We reach for Next.js because it lets us decide how each page is built, keeps us in one language, ships fast by default, and does not trap the client with us. For most client web work, that combination is hard to beat, and we are glad it is our default.

But a default is a starting point, not a verdict. When the project is a simple brochure, a publish-heavy content site, a one-page landing, or a genuinely native app, we say so and pick the tool that fits. Good engineering is mostly knowing which problem you actually have.

If you want to see the full range of what we build on, and where each one fits, have a look at our stacks. The right answer for your project might be Next.js. It might not be. We would rather get that right than sell you our habit.