Rendering is a decision
you make per route.
Hire someone who makes it on purpose.
Static, ISR, streamed, dynamic, client island — Next.js gives you all of them and punishes you for choosing carelessly. Our engineers write the ledger before they write the components, and they stay on our payroll while they do it.
Six routes from a real commerce build
This is the artefact. Ask any Next.js candidate to produce one for a site they have worked on — the ones who can are the ones you want, and the exercise takes ten minutes.
Five things we look for in the first hour
We take over a lot of half-finished Next.js projects. These five turn up so reliably that they are the first grep on any handover — and any of them will quietly cost you money.
Or have us take the whole build"use client" at the top of the layout
One line that opts the entire tree out of server rendering. We find it in roughly half the codebases we inherit.
A fetch waterfall in a server component
Three sequential awaits where two were independent. Costs a second of TTFB and shows up in nobody's dashboard.
Images as raw <img> tags
No sizing, no format negotiation, no priority hint — and a Largest Contentful Paint nobody can explain.
Everything set to force-dynamic
The universal fix for a caching bug someone never diagnosed. It turns a CDN-served site into an origin-served one.
Secrets in NEXT_PUBLIC_
Shipped to the browser by definition. Worth a grep before your next release, whoever built it.
Current, not nostalgic
Next.js moves quickly. Our engineers work across several client codebases a year, which is the only reliable way to stay current with it.
Give us the URL and the complaint
We will run it, read the network waterfall, and tell you whether you need one engineer for a month or a different approach entirely. That review is free.