1.3

Builder, Headless, or Bespoke: The Honest Comparison

Rented Ground: What You Actually Own When You Own a Website

Every major website platform is being rebuilt around code and AI agents. Four questions decide whether that’s your problem or someone else’s.

Articles in this series

A comparison with no winner

Most comparisons of this kind are written by someone who sells one of the options. You can usually spot it because one column wins every row.

I build on all three, so I’ll try to do this properly, which means being specific about what each one is bad at. If you finish this and still can’t tell which one I’d prefer to sell you, I’ve done it right.

The three options:

  • Managed visual builder — Webflow, Framer, Squarespace, Wix. You design in a browser, they host it, they patch it.
  • Headless CMS plus custom front end — Sanity, Storyblok or Payload behind an Astro or Next.js site. Editors get a content interface; developers own the code.
  • Fully bespoke — custom application, custom back end. Usually because the site is really a product.

I’ve left traditional WordPress out as its own row because in practice it behaves like a builder with worse security and better plugins, and saying so saves a column.

The comparison

| | Managed builder | Headless + custom front end | Fully bespoke | | :--- | :--- | :--- | :--- | | **Non-technical editing** | Best in class. Someone can genuinely change copy on a Tuesday | Good for content, but anything structural is a developer job | Whatever was built. Often nothing | | **Five-year cost, 1 editor** | Lowest | Higher, build cost dominates | Highest | | **Five-year cost, 5 editors** | Rises steeply. Seats are per-person | Flatter, most CMS pricing is kinder at this size | Depends entirely | | **Five-year cost, 15 editors** | Often the worst option. This is where enterprise quotes appear | Usually best | Varies | | **Portability** | Weakest. Proprietary format, partial export | Strong. Content in a database you can query, code in a repo | Strong in principle, weak if nobody understands it | | **Who patches and backs up** | Them. Genuinely included | You or your agency, forever | You or your agency, forever | | **Architectural ceiling** | Real and eventually hit: content limits, code caps, no build pipeline control | Very high | None, and that is not always good | | **AI agent compatibility** | Improving fast. Webflow shipped MCP 2.0 with branching and permissions in July 2026 | Native. Agents work directly on code | Native | | **Who you need at 11pm** | Nobody. Someone else is on call | Your developer | Your developer | | **Worst failure mode** | A feature you depend on is retired | Dependency rot nobody notices until something breaks | One person leaves and takes the knowledge |

Choose a managed builder if

  • One or two non-technical people need to edit content regularly and independently.
  • You don’t want to think about security, backups, SSL or uptime — and you’d rather pay a subscription than own the problem.
  • Your site is marketing, not machinery.
  • You’d struggle to reach a developer quickly when something breaks.

Avoid it if you’re heading towards logins, transactions or complex data; you’ll have a large editing team; or you’ve already hit a ceiling and are working around it with embeds and hacks.

Choose headless plus a custom front end if

  • You publish a lot and want editors served properly without capping what developers can do.
  • You want your content in a database you can query and your code in a repository you own.
  • You care about performance and search control at a level builders cap out at.
  • You have, or are willing to pay for, a continuing technical relationship.

Avoid it if nobody in your organisation will own the technical side. This is the important one. A headless stack with no maintainer degrades quietly — dependencies drift, the build breaks on a package update eighteen months later, and the person who set it up has moved on. That risk is real, it’s yours, and a managed platform genuinely does absorb it for you.

Choose bespoke if

  • The site is really a product. Users log in and do things.
  • Your requirements don’t map onto anything off the shelf.
  • You have budget for it to be maintained, not just built.

Avoid it if you’re choosing it for prestige, or because a builder felt limiting on one specific page. That’s an expensive way to solve a small problem.

A worked example where the builder is simply correct

A three-partner consultancy. Twelve pages, a contact form, case studies added a few times a year. One partner edits copy herself. Referrals and search bring in enquiries and the site’s job is to make them feel confident before they call.

Every argument in this cluster about ownership, portability and code-as-source-of-truth applies to them, and none of it should change what they do. A managed builder gives them a site their own partner can update, patched and backed up by somebody else, for less than the cost of an hour of their own time each month.

I’d put them on a builder, get their registrar and DNS in their own name, set up a content export, and tell them to stop reading about platforms.

That’s the answer for a lot of people. It’s just not an interesting enough answer to generate much content, which is why you don’t read it often.

The question that actually decides it

Everything above collapses into one thing.

Who changes this website in a normal week, and are they technical?

If the answer is a non-technical person making frequent changes, a managed builder or a genuinely good editorial CMS wins, and no amount of ownership argument outranks it. If the answer is a developer, or nobody, or an AI agent under supervision, the ownership arguments get their proper weight.

Answer that first. Then check it against the five-year cost and what leaving would cost, and the decision usually makes itself.

Platform features and pricing verified 13 August 2026.

Back to Rented Ground
→ Next: When the Platform Removes Something You Depend On

TL;DR

There are three broad ways to build a business website and none of them wins outright. The decision turns on who edits the site each week, whether it’s a website or a product, and who you want carrying hosting and security. Everything else is detail.

Mark Thurman