Message before decoration
The first screen names who the offer is for and what changes for them. Visual polish on top of an unclear offer just makes the confusion load faster.
A business website on Next.js, new or rebuilt: the offer clear on the first screen, rendering chosen per page type, metadata shipped with each template, and a quote path on every service page rather than one contact form buried in the nav.
The first screen names who the offer is for and what changes for them. Visual polish on top of an unclear offer just makes the confusion load faster.
Mobile, tablet, and desktop share a type scale and spacing set rather than behaving like three separate designs that happen to share content.
A visitor who lands deep from search should be able to enquire from that page, not navigate back to a single contact form to do it.
A new site starts from who it is for and what each page has to do. A rebuild starts by crawling the current site for the pages that carry search traffic and enquiries, because a rebuild that quietly drops one of them is a downgrade.
What each page is for, who it is for, which claim it makes, and what it asks for at the end. Decided in writing before design, because rearranging pages after they are built is the expensive way to have this conversation.
Static, incremental, server-rendered, or client-fetched, decided by how the data behaves rather than applied uniformly. This decision sets the performance ceiling for the whole site.
Each template ships with its canonical, title, and structured data in the same commit, so there is never a version of a page live without them.
Real-device checks, keyboard and screen-reader passes, a performance budget verified against the deployed site rather than a local build, then written handover notes.
Most performance problems in a Next.js build come from applying one rendering mode everywhere. A marketing page that server-renders on every request is slow for no reason, and a stock level that was baked in at build time is wrong. The decision is per page type, and it is made before the build.
Service pages, about, contact, legal
Rendered once at build time and served from the CDN. Fastest possible response, nothing to compute per visit. The default for anything that changes less often than you deploy.
Blog posts, case studies, catalogue pages
Static, but regenerated in the background on a schedule or when content changes. Editors see updates without a rebuild, and visitors still get a CDN response rather than waiting on a render.
Stock levels, pricing, anything per-user
Rendered per request because the data is only correct at the moment it is asked for. Slower than static and worth it only where staleness would be wrong rather than merely old.
Dashboards behind a login, search results
Rendered in the browser after load. Right for interactive state that search engines never need to see, wrong for anything that should appear in results.
Working out a budget? There are guides to what a small business website costs in the UK and website design costs in Dubai and the UAE, with my starting prices and what moves a quote above them.
Website builds start around £750, whether it is a new site or a rebuild of a small one. Moving a site that already ranks is priced as a migration, from £3,000, because the crawl and the redirect map come on top of the build. Beyond that, the number moves on page count, how ready the content is, how many integrations have to keep working, and whether the offer itself needs rewriting before anything gets designed. A five-page service site with copy already written is a very different job from a forty-page catalogue where half the content needs restructuring first.
Most business sites take three to six weeks, once scope, content, and a review rhythm are settled. The long pole is almost never the code. It is waiting on content, logo files, product data, or a decision about what the offer actually is.
Both. A new site starts from the offer: who it is for, what each page has to say, and what it asks the visitor to do. A rebuild starts one step earlier, with a crawl of the current site to find the pages that already earn search traffic and enquiries, so none of them are dropped by accident.
If the current stack is sound and the problem is presentation, a redesign on the existing platform is cheaper and lower risk. A rebuild is worth it when the platform itself is the constraint: plugin weight you cannot remove, a theme nobody can safely change, no way to add a page type, or performance that will not improve without changing how pages are rendered. I will tell you which one you are looking at after seeing the site.
You know the business, so the facts have to come from you. I structure it: what belongs on which page, what order it goes in, which claims need a number behind them, and what the page should ask the visitor to do at the end. Handing over a blank CMS and calling it done is how sites end up with a beautiful shell and lorem ipsum in the service pages six months later.
Whichever suits how often you publish. Sites that change monthly are usually better with content in the repo: nothing to log into, nothing to patch, and content changes go through the same review as code. Sites where non-technical staff publish weekly need a real CMS, either headless WordPress if your team already knows wp-admin, or a hosted headless option. This is decided before the build, because it changes the architecture.
A Next.js site of this size runs on Vercel's Pro plan or a similar host for a small monthly fee. Vercel's free Hobby plan is for non-commercial sites, so a business site should not sit on it. There is no server to patch and no plugin subscriptions. The cost that does remain is a domain, possibly a CMS, and whatever transactional email you send. That is usually well below what a maintained WordPress install costs once hosting, security plugins, and updates are counted.
You get the repo, the deployment, and written notes on how the templates fit together and where to change what. If you want ongoing work I am available for it, but the handover assumes you might not. A site that only its original developer can maintain is a liability, not an asset.
A couple of sentences is enough to start. I reply within one business day.