Fast on the first paint,
indexable on the first crawl
A single-page app that renders everything in the browser looks fine to a visitor on a fast connection and looks like an empty page to a search engine crawler and a visitor on a slow one. Next.js lets us render each page the way it actually needs: static for marketing pages, server-rendered for anything personalized, so the first thing a visitor or a crawler sees is the real content, not a loading spinner.
What it is
Next.js is a React framework that lets each page choose how it gets rendered: generated once at build time for content that is the same for every visitor, rendered on the server per request for anything personalized or frequently changing, or rendered in the browser for purely interactive parts of the page. The result is a site that loads fast and is fully readable by search engines, while still behaving like a modern app once it is interactive.
When you need it (and when you do not)
It earns its cost when SEO matters and the content is more than a handful of static pages, when parts of the site are genuinely dynamic (a dashboard, personalized recommendations, live pricing), or when you need the performance headroom that comes from controlling exactly how each page renders. A Thailand-based D2C store we rebuilt needed this combination: a catalog that had to be fast and indexable, plus checkout logic that had to be dynamic and correct.
It is the wrong tool for a five-page brochure site with no dynamic content, a static site generator is simpler and cheaper to run for that case. And if your team has no one who can maintain a Node application after we hand it over, a platform like WordPress or Shopify, which has a much larger pool of people who can maintain it, is the more honest recommendation even though it is less flexible.
How we build it
We decide the rendering strategy per page type before writing code: marketing and product pages that are the same for every visitor get static generation, so they are served instantly from a CDN with no server work per request; anything with per-user data, a cart, an account page, search results filtered live, gets server rendering so the first paint still has real content instead of a loading state. Purely interactive widgets that need no SEO value render client-side, which keeps the server-rendered pages lean.
Performance is a budget we hold the build to, not an afterthought: images sized and formatted per breakpoint, fonts loaded without blocking the first paint, and a largest contentful paint target measured on real pages on a throttled connection, not just a fast office Wi-Fi. SEO metadata, structured data and the sitemap are generated from the same route definitions as the pages themselves, so they cannot drift out of sync the way hand-maintained meta tags do.
Anything handling money or user data, checkout, forms, account actions, gets automated tests from the first week, not added at the end when there is less time to fix what they find.
What to watch
Server rendering means a running Node process, which is a different operational model than a static file host: you need monitoring, and a traffic spike needs the server to scale, not just a CDN cache to hold up. Vercel handles this for you at a cost that scales with usage; a self-hosted deployment is cheaper at steady traffic but is infrastructure you or we need to maintain. Over-using client-side rendering inside a Next.js app defeats the purpose, we watch for pages that quietly turn into the single-page app problem Next.js was meant to avoid.
Price and timeline
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| Marketing or content site | from $3,000 | Static and server-rendered pages, SEO, deployment | 3 to 4 weeks |
| App with backend and auth | from $8,000 | Custom API or database, authentication, dashboards | 6 to 10 weeks |
Running cost on Vercel is typically $20 to $200 a month depending on traffic; self-hosted on your own VPS is the cost of the server itself.
Related
This pairs with GraphQL API or API-first backend with OpenAPI when the app needs a dedicated backend behind it, and with design system and component library for teams building more than one Next.js app. See the development service page for our full build process. For real examples, see the D2C store Thailand rebuild and the AI persona business’s SEO site.
Have a slow React app or a WordPress site that has outgrown itself? Get in touch and we will look at whether Next.js is actually the fix.
FAQ
How much does a Next.js build cost?
From $3,000 for a site with a handful of page types and server rendering where it matters, 3 to 6 weeks. A larger app with a custom backend, authentication and a database runs $6,000 to $15,000 depending on scope.
Why Next.js instead of a plain React app?
A plain client-rendered React app ships an empty HTML shell and makes the browser do all the rendering work, which is slow on the first load and invisible to search engines that do not execute JavaScript well. Next.js renders the first view on the server or at build time, so the content is there immediately, then React takes over for interactivity.
Do you use the Pages Router or the App Router?
The App Router for new projects, since it is where Next.js is investing and it handles server components and streaming better. We migrate existing Pages Router projects when the client wants new features the App Router does better, and are honest when a migration is not worth the disruption yet.
Who owns the code and where does it deploy?
You. The repository is yours from the first commit, and it deploys to Vercel or any Node-capable host, your own VPS included, we do not lock the project to one platform.
Can this replace our WordPress or Shopify site?
Sometimes. If you need custom logic, a particular performance target, or a frontend that talks to several different data sources, Next.js gives more control. If a standard store or content site covers what you need, migrating off a platform that already works is usually not worth the cost; we tell you which situation you are in.