Why we build company websites with Next.js

We build most company websites with Next.js because it gives us three things at once: pages that are rendered ahead of time and load fast on any connection, a public site with no admin panel for attackers to find, and a codebase that can grow from brochure pages into a portal or product without starting again. For a business whose website has to win trust and enquiries, those three matter more than being able to install plugins.

That is the short version. The rest of this post explains each point with the specifics, and then sets out where Next.js is the wrong choice, because it sometimes is.

What is Next.js, in one paragraph?

Next.js is a framework built on React, maintained by Vercel and open source. As of October 2026 the current major version is 16. It lets a developer write pages as components, decide per page whether it is rendered at build time, on the server when requested, or in the browser, and ship the result with image optimisation, metadata handling, routing and caching built in. The Next.js documentation is thorough and is the reference we work from.

It is the framework behind most of the sites we build in our website design and development work. For a company site, the important part is that most pages are rendered once, at build time or on first request, and then served as finished HTML from a cache close to the visitor. Nothing is assembled from a database while a visitor waits.

Why does the way pages are rendered matter so much?

Because it decides how fast the page appears, and page speed is now part of how Google evaluates pages and how visitors judge a company.

Google measures three Core Web Vitals: Largest Contentful Paint (how long until the main content is visible), Interaction to Next Paint (how quickly the page responds to a tap or click) and Cumulative Layout Shift (how much the layout jumps around while loading). The thresholds, published on web.dev, are 2.5 seconds or less for LCP, 200 milliseconds or less for INP and 0.1 or less for CLS, measured for real visitors at the 75th percentile. Our Core Web Vitals checker tells you whether your current numbers pass.

A pre-rendered Next.js page tends to pass all three without special effort. The HTML arrives complete, images are sized and lazy-loaded by the framework, fonts are loaded without layout shift, and only the JavaScript a page needs is sent. A WordPress site can reach the same scores, but it takes a caching layer, image tuning and plugin discipline to get there and stay there. Core Web Vitals explained covers the metrics in more depth, and Next.js image optimisation covers the single biggest contributor.

How does Next.js compare with the alternatives for a company site?

The table shows why Next.js is not the answer to every brief. WordPress wins on editing and on the pool of people who can work on it. Webflow wins for a design-led team that wants to change layouts visually. The detailed comparisons are in Next.js vs WordPress and WordPress vs custom website.

What does Next.js give a business beyond speed?

Search-ready pages by default. Every page is complete HTML when Google fetches it, with the title, description, canonical URL, Open Graph tags and structured data set from a metadata API rather than a plugin. Next.js for SEO covers what it does better and the few things to watch; setting up metadata and Open Graph is the how-to.

A small attack surface. The public site has no login page, no plugin directory and no database connection a visitor can reach. The content editor, if there is one, is a separate service with its own access control. The usual WordPress security routine of updates, firewalls and malware scans mostly disappears.

One codebase that can grow. The site that starts as ten pages and a contact form can gain a client login, a quote calculator or a booking flow without moving platforms. Server components, explained for non-developers in server components explained, let data-driven pages be built in the same project as the marketing pages.

Predictable running costs. A mostly static site on Vercel, Netlify or Cloudflare costs nothing or close to it at low traffic and a flat monthly amount above that; as of October 2026, Vercel's Pro plan is listed at $20 per team member per month. There are no plugin licences and no weekly updates to apply. Deploying Next.js to Vercel is our launch checklist.

Editing, when it is needed. Most of our Next.js sites connect to a headless CMS. Editors get a clean interface for pages, posts, projects and jobs; the site updates within seconds through on-demand revalidation. How to add a CMS to a Next.js site compares the options we use.

This is the stack we recommend when the brief fits. It is not the one we recommend every time.

When is Next.js the wrong choice?

Your team publishes daily and wants full control of layout. A newsroom, a content-marketing operation or a team that builds landing pages weekly is better served by WordPress or Webflow. A headless CMS handles content well; it does not let a marketer redesign a page on a Friday afternoon.

The budget is small and the site is standard. A ten-page services site with a blog, built from a good WordPress theme, costs less than a custom Next.js build and does the job. Spending the difference on better copy and photography will change more enquiries than the platform will.

Nobody on your side knows React. If you plan to maintain the site in-house and your team knows PHP or no code at all, a Next.js site makes you dependent on an outside developer for anything beyond content. That is fine if you have a care arrangement; it is a trap if you do not.

You need a mature plugin. Event ticketing, course platforms, membership sites and complex multilingual publishing exist as WordPress plugins that would cost a great deal to rebuild. If a plugin matches your need closely, use the platform the plugin runs on.

What should you check before choosing it?

Ask whoever is quoting these four things.

1. Will the pages be pre-rendered, or rendered on each request? Most company pages should be pre-rendered; a site rendered entirely on request throws away the main speed advantage.
2. Which CMS will editors use, and can they preview a change before publishing? Get a demo of the editing screen, not just the public site.
3. Where will it be hosted, who owns the account, and what does it cost at your expected traffic? You should own the hosting and the code repository from the first day.
4. What is the Core Web Vitals target, and will it be measured with real-visitor data after launch, not just a lab score?

If the answers are clear, Next.js will give you a site that is fast, hard to break and able to grow. If they are vague, the platform will not save the project. The choice between the two routing systems the framework offers is a technical one that the developer should make for you; App Router vs Pages Router explains it if you want to understand the recommendation you are given.