Why I Build Client Websites with Next.js

The question behind the question

Clients rarely care which framework their site uses, and they are right not to. What they care about is whether the site loads fast, whether it can rank, whether their team can update it, and whether it will still be maintainable in three years. Next.js is my default because of how it answers those four questions — not because it is fashionable.

Rendering that suits marketing content

A marketing site has two kinds of pages: ones that barely change, and ones that change often. Next.js lets each page choose. Static pages are pre-rendered to HTML at build time and served instantly from a CDN. Pages backed by a database can revalidate on a schedule, so they stay fresh without being rebuilt on every request.

This matters commercially because it removes the usual trade-off. You do not have to choose between a fast static site your team cannot edit and a slow dynamic site they can.

Performance defaults you would otherwise have to build

A lot of what determines Core Web Vitals is handled without extra work:

• Images are resized, converted to modern formats and lazy-loaded, with dimensions reserved so nothing shifts as they load
• Fonts are self-hosted automatically, removing a third-party round trip and the flash of unstyled text
• JavaScript is split per route, so a visitor landing on your contact page does not download the code for your blog

None of this is impossible elsewhere. It is just that here it is the default, and defaults are what survive a busy project.

Search visibility is not an afterthought

Server rendering means crawlers receive complete HTML rather than an empty container waiting for JavaScript. The metadata API generates titles, descriptions, canonical tags and Open Graph images per page, and sitemaps and robots rules are generated from the same data the site already has — so they cannot drift out of sync with reality.

That last point is worth dwelling on. Most stale sitemaps are stale because they were maintained separately from the content.

It scales past the marketing site

The same codebase handles API routes, authentication and an admin panel. When a client eventually needs a lead dashboard, a customer portal or a booking flow, that is an addition to the existing project rather than a second system to integrate and pay for.

The honest trade-offs

It is not the right answer for everything:

• A five-page brochure site with no ambitions — a simpler static setup is cheaper and perfectly adequate
• A team already fluent in WordPress — familiarity has real value, and fighting it rarely pays
• Very tight budgets — custom development costs more upfront than a theme, and sometimes a theme is the correct commercial decision

I will say so when one of those applies. Recommending a rebuild that does not earn its cost is a good way to lose a client you could have kept.

When it clearly is the right call

If your site is slow on mobile and it is costing you conversions, if you need genuinely custom functionality, if you are running SEO seriously enough that technical foundations matter, or if you expect to add tools and integrations over the next few years — the investment returns quickly and keeps returning.