Hosting and delivery

Hosting here means the boring question of where the built files live and how a browser gets them. A static export on a CDN, a build platform such as Vercel or Netlify, or nginx on a virtual machine are three different answers with three different failure modes. The choice usually follows from one thing: whether the site needs to run code per request, or whether it only needs to hand over assets that were produced at build time.

How we use it

Linked Corporate is the pure case. It is a Next.js application exported to static HTML, with no API routes, no database and no server, served from a CDN. Enquiries go out through a chat link that carries the current page URL, which is why there is no form handler to host, an argument we make at length in why a chat link beats a contact form. Nothing in that site can be down in the usual sense, and the hosting bill is close to nothing.

360nutri splits it: the React front end is on Netlify and the entire backend, database, authentication, storage and edge functions, lives in Supabase. AHZ Associates shows what accretes over time, with the main site behind a CDN, the global site on Vercel, the application portal on nginx 1.24 on Ubuntu and imagery served from an S3 bucket. Three hosting arrangements for one brand is not a design, it is history, and the cost lands on whoever has to move a URL. Sixteen country sections under one roof is a related problem we have written up in one site, sixteen countries.

What it costs you

Decoupling has a specific hazard, and 360nutri demonstrates it: the deployed bundle points at a backend host that no longer resolves in DNS. The site loads perfectly, every check that pings the homepage stays green, and nothing in the product works. If the front end and the backend are hosted separately, the health check has to exercise the backend, not the shell.

Platform tiers have cliffs. Free bandwidth and build minutes are generous until a launch, then per-seat pricing and overage arrive together. Platform-specific features are the sharper edge: incremental regeneration, image optimisation and middleware are all easy to adopt and none of them port cleanly, so a decision made for convenience in month one is a rewrite in year two. A static export avoids all of that by giving up server rendering entirely, which is the right trade for a brochure site and the wrong one for anything with accounts.

nginx on a VM is the honest old option and it bills for what it is: patching, certificate renewal, log rotation, disk filling up at the wrong moment and someone on call for the reboot. It is fine when a long-running process is genuinely needed. It is a poor way to serve ten static pages.

Whatever the host, keep the URLs. A rebuild that changes paths throws away the search rankings the old site earned, and the redirect map is cheap to write on day one and expensive to reconstruct later, which is the whole of keep the URLs when you rebuild.

When we would choose something else

When the site needs to run code per request, authentication, personalised pages, webhooks, an API, we put it on Workers rather than bolt serverless functions onto a static host, because then one deployment covers everything and there is no second vendor in the request path. For an application that needs long-lived processes and stateful services next to it, that is a Kubernetes conversation, and a much larger bill.