What a website costs after you launch it.

The quote is the small number

Website procurement is almost always run on build cost. Three quotes, compare the totals, pick one. It is a reasonable-looking process that optimises the wrong variable, because a website is not a purchase — it is a subscription to a set of obligations you accept on the day you launch.

Over five years, a site of any commercial seriousness will cost more in the running than it did in the building, and the ratio gets worse the more the build tried to save. That is not an argument for spending more up front. It is an argument for asking, at quote stage, a different question: what will this cost to still have?

The four things that actually recur

Platform and security upkeep

Whatever you build on gets updates, and some of them are security updates you do not get to defer. On a mainstream CMS this is mostly routine and mostly cheap — until a major version lands and the plugins you depend on have not followed.

The cost here scales with how much you added, not with the platform. A stock installation is nearly free to maintain. The same platform carrying fourteen extensions, three of them abandoned by their authors, is a different proposition entirely, and nobody costed the difference at build time.

Dependency churn

A modern JavaScript stack carries hundreds of transitive dependencies and a framework that ships breaking changes on a real cadence. Staying current is work. Not staying current is also work, deferred and compounding, and eventually it arrives as "we need to rebuild" — which is how a five-year-old site becomes a new project.

This is the single most under-budgeted line in web ownership, because at build time it is genuinely invisible. Ask any prospective builder how they handle framework upgrades and who pays for them. The answer tells you a great deal.

Content operations

This is usually the largest cost and almost never appears in a quote, because it is paid in your own team's time rather than an invoice.

The variable that matters is publishing friction. If changing a paragraph requires a developer, a deployment, or a ticket, your organisation will publish less. Not occasionally less — permanently less, because the friction is paid every single time and people route around it by not doing the thing.

We think this is the most consistently underweighted factor in platform choice, and it is why the right answer is so often less technically interesting than the one the builder prefers. A stack that is marginally slower but lets a marketer ship a landing page unassisted will out-produce an elegant one that does not. Our WordPress or Next.js guide works through where each genuinely wins.

The custom surface

Every bespoke component is a permanent liability. It has no upstream maintainer, no community fixing its bugs, and no documentation beyond whatever the person who wrote it left behind — and that person will not always be reachable.

Custom work is often correct; the mistake is not accounting for it. A reasonable rule: for anything bespoke, ask what it would take for someone who has never seen the codebase to change it safely. If the honest answer is "a long time", you have found a future cost.

The build decisions that set the running cost

Five choices made in the first fortnight determine most of what follows.

1. How much is bespoke versus configured. Every custom component is yours forever. Configure where you can; build where the value is genuinely differentiated.
2. Whether editors can work unassisted. The single largest lever on lifetime cost, and the easiest to test — ask to publish a page yourself during the demo.
3. Whether the URL structure is designed or accidental. URLs are the hardest thing to change later, because changing them means redirects, lost equity and a migration project. Get them right while they cost nothing.
4. Whether internal linking is systematic or manual. On anything past a few hundred pages, manual linking decays, and the pages that lose out are the newest ones. This is an architecture decision with a direct traffic consequence — see large-site SEO and indexing.
5. Who holds the keys. Domain, DNS, hosting, repository, analytics. If any of them sit only with an agency, your switching cost is not a number — it is a negotiation. This is not a hypothetical: it is the most common way we see organisations become unable to leave a supplier they have outgrown.

What to ask before you sign

Seven questions that surface running cost at quote stage, when you still have leverage.

• Who owns the domain, DNS, hosting account, repository and analytics — in writing?
• Can a non-technical colleague publish a new page and change a headline without you? Show me.
• What happens when the platform ships a major version — who does the upgrade, and who pays?
• Which parts are bespoke, and what does it take for a new developer to change them safely?
• What is the plan for internal linking as the site grows past a few hundred pages?
• If we replace you in two years, what exactly do we take with us, and in what format?
• What does this cost us annually if we do nothing at all?

The last one is the most revealing. A supplier who can answer it clearly has thought about your total cost. One who treats it as an odd question has priced a build and not a relationship.

Why we answer this the way we do

We run six properties of our own across WordPress, WooCommerce and Next.js, which means we are on the receiving end of every cost above — the upgrades, the dependency churn, the abandoned plugin, the publishing friction we inflicted on ourselves and later had to remove.

That is a different vantage point from an agency that hands over at launch, and it is why we argue for boring, low-friction choices more often than the category norm. When you keep the site, elegance you have to maintain stops being free. Our website development work is built around that view.