What is the difference between Server Components and Client Components?

Server Components render on the server and send no JavaScript to the browser, so they can read from a database or call an internal API directly and cannot use state, effects, or browser APIs. Client Components ship JavaScript and hydrate in the browser, so they can hold state and respond to events. In the App Router everything is a Server Component until you add the use client directive, and the important consequence is that the directive applies to everything imported below that component too.

Why does adding use client to a page make it slow?

Because the directive is inherited by the whole component tree beneath it. Putting use client at the top of a page to enable one piece of state converts every component that page imports into a Client Component, which ships all of that JavaScript to the browser and forfeits the server rendering you adopted Next.js for. The fix is to move the boundary down: keep the page a Server Component and mark only the small interactive control as a Client Component.

Why is our Next.js content not updating?

Almost always a caching layer that nobody has identified. Next.js has several distinct caches, and stale content behaves differently depending on which one is holding it: the Data Cache holds fetch results across requests, the Full Route Cache holds rendered output for static routes, and the client-side Router Cache holds route payloads in the user's own browser. Diagnosing it means establishing which layer is serving the stale copy before changing any revalidation setting, because the same symptom has four different causes.

Should we migrate from Pages Router to App Router?

Only with a reason beyond being current. The App Router is worth adopting when you want Server Components to reduce client JavaScript, streaming for slow data, or the newer data and metadata model. It is not worth adopting on a Pages Router application that works, because the migration is genuine architectural work rather than a rename. Both routers can run in the same application, so the sensible approach is incremental: move new routes and high-value routes first.

How much do Next.js development services cost?

A marketing or content site typically costs $15,000 to $50,000, an application build $40,000 to $200,000, and a Pages Router to App Router migration $15,000 to $70,000. A caching and rendering audit is $2,000 to $5,000, performance work $8,000 to $35,000, headless CMS or commerce integration $12,000 to $60,000, and self-hosting setup $6,000 to $25,000. Support retainers run $5,000 to $25,000 per month.

Can Next.js be self-hosted instead of using Vercel?

Yes. Next.js runs anywhere Node runs, and in a container on your own infrastructure with the standalone output. What you take on is the work Vercel otherwise does for you: image optimisation, incremental regeneration behaviour, caching across multiple instances, and edge behaviour. Self-hosting is the right answer for data residency requirements, existing platform commitments, or predictable cost at scale, and the wrong answer if the reason is only to avoid a bill you have not compared against engineering time.

What are Server Actions and should we use them?

Server Actions are functions that run on the server and can be called directly from your components, which removes most of the boilerplate around form submission and mutation endpoints. They suit forms, mutations, and progressive enhancement, and they are genuinely less code than a Route Handler plus a fetch. They are not a replacement for a public API: anything a third party or another client consumes should still be a Route Handler, and every action needs its own authorisation check because being callable from a component does not make it private.

Is Next.js good for SEO?

It is one of the better frameworks for it, provided the client boundary is drawn correctly. Static and server rendering put content in the initial HTML, the Metadata API generates titles, descriptions, canonicals, and Open Graph tags per route, and sitemap and robots files can be generated from your data. What undoes all of that is a client boundary placed too high, because a page converted to a Client Component ships its content as JavaScript instead of HTML, and then the framework's advantages are switched off.

App Router · Server Components · caching

Next.js development services

We build and repair Next.js applications: App Router architecture, Server and Client Component boundaries, caching and revalidation strategy, Server Actions and Route Handlers, headless CMS and commerce integration, Pages Router migrations, and self-hosted deployment. Two things account for most of the Next.js work we are called into, and neither is a bug.

The client boundary is drawn in the wrong place. One component needed state, so use client went at the top of the page, and everything below it became a Client Component. And nobody knows which cache is holding the stale copy. Next.js has several, they behave differently, and the same symptom has four possible causes.

Get a free app review Server or Client?

Client boundary audit, caching and revalidation map, route-level rendering behaviour, and dependency health · five business days

Scope it roughly estimating

Engagement

Where you are now

Typical band

End to end

What decides the number

Fixed price on defined scope. Data model and integration count drive the number far more than route count does.

Before you enquire

What you are actually looking for

Four things nearly every enquiry turns out to be about, in the words people actually use.

The honest answer

What you mean

What we do about it

What you end up with

In practice

What the work looks like

Screens from live engagements, with client details removed.

The main view

Scope

What we build

Thirteen kinds of work, including the diagnostic engagements that establish whether you need a build at all.

Try it · interactive

Where Next.js projects go wrong

Seven causes. Next.js gives you more architectural power than plain React and correspondingly more ways to switch its advantages off by accident. Tick what you recognise.

The pattern: almost every item here is a team paying Next.js's complexity cost without collecting its benefit. That is worse than not using the framework, and it is entirely recoverable.

{{ problemCount }} of 7 recognised

What each one costs you

• {{ c }}

Nothing ticked yet. Pick whichever ones sound like your codebase and the cost of each appears here.

The decision that defines the architecture

Server Component or Client Component?

In the App Router everything is a Server Component until you say otherwise. The critical detail almost everyone learns late: use client is inherited by everything imported below it. Put it in the wrong place and you ship the whole page as JavaScript.

Interactive · describe a component

Where does the boundary go?

Two questions about one component, and you get the verdict plus where the directive actually belongs.

{{ d.label }}

Rule of thumb

Push the boundary as far down the tree as it will go. A Client Component can be a button inside a Server Component page, and that is almost always the right shape.

{{ bCode }}

If you get it wrong

The part nobody explains

The caching layers

“The content will not update” is the single most common Next.js complaint, and it has four possible causes sitting in four different places. Diagnosing which one is holding your stale copy comes before changing any setting.

Layer What it holds Cleared by Symptom when wrong

How we approach it

Tag-based invalidation wired to your CMS or data source, so publishing clears exactly the affected routes rather than everything or nothing. Then it is documented, because a caching strategy nobody can explain gets dismantled by the next developer who hits a stale page.

The anti-pattern we find most

Caching disabled everywhere, because at some point something was stale and opting out made the symptom go away. The site now re-fetches everything on every request, and the framework is doing strictly more work than a plain server-rendered app would.

Routers

App Router or Pages Router?

A question with a real answer rather than a default one. Both can run in the same application, which makes this less binary than it is usually presented.

△

We will not recommend a migration you do not need. A Pages Router application that performs well and ships features is not a problem to be solved. Migrate for Server Components, streaming, or the newer data model, and not because the documentation moved.

Deployment

Vercel or self-hosted

A commercial question dressed as a technical one, and worth answering honestly in both directions.

Concern Vercel Self-hosted

⊕

Self-host for a reason, not as a reflex. Data residency, an existing platform commitment, or predictable cost at real scale are good reasons. Avoiding a bill you have not compared against engineering hours is not, and we will show you that comparison rather than assume the answer.

Deliverables

What you receive

The actual documents, not a sample deck built for the pitch.

Engineering spec

Next.js rendering and architecture plan

52 routes · App Router · 2 data sources

01Rendering strategy per route 02Caching and revalidation rules 03Data fetching boundaries 04SEO and metadata handling 05Deployment and edge config

B Every decision has a written reason

Report

App health at handover

Server render coverage97%

Core Web Vitals94

Cache hit rate88%

Edge readinessPartial

Edge deployment is the lowest bar and the one that needs a cost conversation first.

Priorities

Per-route report

Route Was Now

/3.9s0.8s /blog/*4.6s0.7s /pricing3.2s0.6s /docs/*5.1s0.9s /app/*6.4s1.6s

Largest Contentful Paint per route, measured in the field.

Handover

Pricing

Next.js development pricing

Fixed price on defined scope. Paid discovery where the scope is genuinely uncertain.

01 · What do you need

02 · How big {{ estSizeLabel }}

Small Very large

03 · Anything else

Estimate {{ estUnit }}

{{ estLow }} to {{ estHigh }}

Get this scoped properly

An estimate, not a quote. Fixed price follows a scoping call, and where requirements are genuinely uncertain we run a paid discovery phase first.

⊕

The caching and rendering audit is the cheapest useful thing on this list. It regularly establishes that the problem is one boundary in the wrong file and three cache settings, on a codebase where a rebuild was already being discussed.

Fit

Who we work with

∅

Probably not us if the requirement is a content site with no application behind it. Next.js will do it, and a content-managed platform will do it for less money with faster publishing. If you want the general React case rather than the framework specifics, that is React development.

Free · five business days

Get a free Next.js app review

Including a client boundary map: every use client in your codebase and how much of the tree each one converts.

Build walkthrough Screen share · {{ gLoomTime }}

Requires repository read access for the boundary and caching analysis. If the architecture is sound and the answer is two revalidation changes, we will tell you that.

Repository or deployed URL *

Work email *

What is prompting this? *

Router, hosting, and data source?

These three determine most of what the review will find. Rough is fine.

No sales sequence. A developer reads the code and writes the review, and you will be able to tell.

✓

Request received.

Evidence

Before and after

The same view, before the work and after it.

Before

A fast framework configured so that search engines saw almost none of it.

After

Same codebase, rendering decided per route instead of by accident.

Our stack

Billion Game runs your work through the same instruments the best in-house teams use.

Licences are on us, and every export we pull from them is yours to keep.

✎

Be wary of any agency whose reporting is a tool dashboard with their logo on it. Tools measure; they do not decide what matters, and every one of these will happily generate a hundred findings that change nothing. What you are paying for is the judgement about which three of those hundred are worth your developers’ time.

FAQ

Next.js development FAQs

Anything not answered here, ask us directly.

The short version

Push the client boundary down. Know which cache is holding the stale copy before you change a setting. Invalidate by tag, not by disabling caching. Migrate routers for a reason. And self-host for a reason too.

Do you know which cache is holding the stale copy?

Free app review covering the client boundary map, caching and revalidation, route rendering behaviour, and dependency health. Five business days.

Get a free app review Get a scoped quote

{{ col.title }}

{{ feature.title }}