Website technologies — what to build on, and what changing your mind costs

A conversation about website technology usually opens with a question that has no answer: which one is best. There is no best, in the same way there is no best vehicle — there is a fit between what you need to carry and for how long.

This section is therefore not a guide to be read front to back. It is a switchboard: nine texts, one for each situation that brings a company into a conversation about technology.

What this section actually settles

Proposals get compared on price and on a list of features. What settles the outcome is two things that appear in neither, and whose consequences surface in year three.

Who inside the company will be able to change what. That single question rules out most of the options before anyone opens a technology comparison. If the content changes once a quarter and one person does it, almost any option will do. If it changes weekly, three people from different departments do it, and a mistake in a price list costs real money, then a narrow group of systems is left — and it is that group, not the number of pages, that sets the budget.

What leaving costs. Every choice of technology is also a choice of what you will pay if it turns out to be wrong. That cost appears in no proposal and it differs between options by an order of magnitude: from some you can take your content out in a single file, from others you can take out nothing but plain text, and from others still, leaving means leaving the supplier too, because nobody else will maintain it. It is the one line item you cannot buy later — it is settled when you sign.

Everything else — which language, which framework, which host — follows from those two answers. Which is why the question to ask of any proposal is not "is this modern", but: what does this change about who can work here, and what would it cost us to back out of it.

The order these decisions get made in

They do not all carry the same weight, and they are not all final. It is worth knowing which one you are making, because that is what tells you how much time it deserves.

Reversible tends to be cheap. Hosting can be changed — it is work measured in hours rather than a project, and it usually touches neither the content nor the design. The same goes for the tools around the site: analytics, forms, search. If a decision can be undone in a week, it does not deserve a month of deliberation.

Irreversible tends to be expensive. The system your content lives in, and the way the site is built, are decisions that last for years. Changing them is not a matter of moving files; it is writing the site again and moving every address across without losing your position in search results.

The practical consequence for the order of your conversations with a supplier: settle who gets to change what, and what leaving would look like, before you discuss hosting, frameworks and product names. Proposals usually run that conversation in reverse, because product names are easier to put in a document than an answer to the first question.

Which text answers your question

Nine texts, arranged by how far into the decision you are.

Before you choose — understanding what this conversation is about

You have a proposal and the words next to the price mean nothing to you. Serverless, edge, JAMstack, API-first, PWA, sometimes WebAssembly — none of them is good or bad in itself; each describes a way of doing something. A dictionary of those words for the person signing the contract rather than writing the code, with a question to put to the supplier under each entry: modern website — what the words in a proposal mean.

You want to know what a website is actually made of. Without that, every later conversation runs blind: you cannot tell content from design from behaviour, so you cannot tell what you will be able to change yourself and what counts as a rebuild. The three layers of a website, explained for the buyer rather than the student: HTML and CSS — what you are looking at when you open your own site.

Two proposals name two different languages. The difference does not fall where the names suggest: on one side is a ready-made system you adapt, on the other an application written for you. It is a choice between two cost models rather than between two technologies — with one SEO trap that genuinely costs visibility: PHP vs JavaScript.

What to build on

You do not know what to build on at all. This is the text that settles the whole section, and the one to start with if you read only one. Five paths, each with the line no quote contains: what it costs to get out when it turns out to be the wrong one. With a scored checklist and three cases worked through to the end: what to build your company website on.

The real question is who will be able to change what. Headless separates content from presentation, and that separation costs exactly as much as the team capable of running it. When that cost pays for itself, and when it amounts to buying an editorial department you do not have: headless CMS.

You want to see it from the inside over a year, not in the vendor's brochure. This site runs on Payload, which makes this the one text in the section whose numbers come from our own deployment — including what broke in it and what fixing that cost: Payload CMS.

Your supplier is proposing React or Next.js, and it is unclear whether those are the same thing. They are not. The difference comes down to where the page is assembled — in the browser or on the server — and that is what decides whether a search crawler sees your content: Next.js vs React.

Where to put it

You are choosing a host and cannot tell what you are paying for. Four kinds of hosting, the threshold at which moving up is worth it, and the two sales models that reveal the real bill: a promotional first year with a price step at renewal, against one price for the whole term: website hosting.

You are weighing your own server against a managed service. The maths can come out in your favour — and it has three line items you discover afterwards. Written from our own deployment, outages included: self-hosting Next.js and Payload.

What this section does not cover

Four questions sound technical and are settled elsewhere — and are covered better where they belong.

What all of this costs. Technology is one line in the bill, not the bill, and the bill has two halves: the build, and what starts accruing the day after launch. The full breakdown is in the cost section.

What you will edit content with day to day. Choosing a system as a product — subscription builders, visual editors on top of WordPress, families of CMS — is the tools section. This section holds the architectural decision; that one holds the choice of an instrument to work with.

What happens after launch. Updates, backups, monitoring and technical support depend on the choice of technology far less than proposals imply, and they have a section of their own.

Whether this should be a website at all. If you are considering software to work in — a dashboard, a system for a team, an application for customers — that is a different decision with a different bill, covered in the web applications section.

Check your own case before you start reading

Two of the decisions above can be settled provisionally in a few minutes, without reading any of the nine texts — and it is worth starting there, so that you read only what applies to you.

If the question is whether a classic system will do or you need content separated from presentation, the answer turns mostly on how often the content changes and how many people change it: the WordPress or headless CMS quiz. If the question is whether you need anything written for you at all, rather than a ready-made subscription service: the off-the-shelf SaaS or custom software quiz.

Both give you a result with the reasoning attached rather than a product name — and both may well tell you that something cheaper than what you were reaching for will do.