We repriced the same brief three ways last spring: a 14-page marketing site for a B2B SaaS company, with a blog, a pricing page, a resources library and two gated PDFs. Template build: 62 hours. Webflow build: 48 hours plus a recurring plan. Fully custom design and Next.js front end with a headless CMS: 310 hours. The client picked the template route, launched in five weeks, and has spent roughly nothing on the site since apart from hosting.

That is not an argument that templates always win. The same studio, same year, built a custom application shell for a logistics client because no template on earth was going to handle their permissions model. The honest answer to html template vs website builder vs custom build is that the three options fail in completely different places, and most people choose based on the first-year price tag rather than the thing that actually costs them money later.

Here is the breakdown we use internally when scoping, including the numbers we would rather clients saw up front.

First, define what you are actually comparing

These three categories get muddled constantly, so let’s be precise.

An HTML template is a licensed set of static files: markup, CSS, JS, demo pages. You host it anywhere, you own the code, and there is no runtime platform in the middle. Canvas sits in this category, as do the thousands of Bootstrap 5 kits on ThemeForest. A WordPress theme is a cousin: licensed code, but running on a CMS you also have to maintain.

A website builder is a hosted platform where the editor, the hosting and the rendering are one product. Webflow, Squarespace, Wix, Framer, Shopify. You rent capability. You do not own the output in any portable sense, whatever the export button claims.

A custom build means design from scratch plus code from scratch, whether that is Laravel, Next.js, Astro or a bespoke WordPress theme. The defining feature is that every pixel and every route exists because someone decided it should.

Most real projects are hybrids. A licensed template as the design system, a CMS behind it, a hosted form API instead of a backend. That hybrid is where the majority of our profitable projects live.

HTML template vs website builder: where the money actually goes

On a template project, the licence is a rounding error. A premium HTML template runs roughly $20 to $80 for a regular licence; a WordPress theme, $59 to $99. If your decision is being driven by that number, you are looking at the wrong column of the spreadsheet.

The work is elsewhere:

• Content migration and writing. Consistently the biggest line and consistently underestimated. Fourteen pages of real copy, images sourced and compressed, meta descriptions written: 20 to 40 hours.
• Stripping what you do not use. A 200-demo template ships a lot you will never touch. Budget 4 to 8 hours to trim CSS/JS and get your Lighthouse numbers back.
• Integrations. Forms, CRM, analytics, consent banner, search. 8 to 20 hours.
• Design deviation. Wherever the client’s brand disagrees with the template. This is the variable that blows budgets.

Before you buy any template, audit how much of its CSS you will actually ship. This takes two minutes:

# Point PurgeCSS at only the demo pages you intend to use
npx purgecss --css dist/css/style.css \
  --content "demos/corporate/**/*.html" \
  --output ./audit

Compare the original against the purged output
ls -lh dist/css/style.css ./audit/style.css

If the original is 480KB and your purged version is 90KB, that template is fine: the bulk is demos you are not using. If purging barely moves the number, every page you ship carries that weight. We have rejected templates on this test alone. The same logic applies to WordPress, where theme bloat is the leading cause of failing Core Web Vitals audits; we wrote up the selection criteria in how to choose a WordPress theme that will not wreck your Core Web Vitals.

Builders invert this. There is almost no setup cost and almost no code cost, but you pay a platform tax every month forever, and you pay a second tax in capability ceilings. The moment you need a custom URL structure, a locale-aware redirect rule or server-side logic on submit, you are either buying an third-party add-on or you are stuck.

The real website build cost, line by line

Figures below are based on the same brief: a 14-page B2B marketing site with a blog, one gated asset and a CRM integration. Blended rate of $110 per hour, which is roughly mid-market agency in the UK and US in 2026. Adjust for your region.

Two things jump out. The builder is not dramatically cheaper than the template in year one, because content is content regardless of platform. And the custom build is not 20 percent more expensive, it is four to five times more. Anyone quoting a custom site at template money is either using a template and not telling you, or they are about to lose money and take it out of your QA time.

Year two is where budgets actually die

Build cost gets negotiated. Running cost gets ignored, then shows up as a series of small invoices that nobody predicted.

For a static HTML template site, ongoing cost is close to zero: object storage plus a CDN, or a free tier on Netlify or Cloudflare Pages. No database, no patch cycle, no plugin conflicts at 3am. This is the strongest and least discussed argument in the custom website vs template debate: a static build has almost no attack surface and almost no maintenance surface. Add a hosted form endpoint and you have removed the last reason to run a server. Our guide to HTML form handling without a backend covers the patterns, including spam handling and consent logging.

WordPress changes the picture. You now own a patch cycle. Budget 2 to 4 hours a quarter for core, theme and plugin updates with a staging check, plus premium plugin renewals (ACF Pro, a forms plugin, a backup service) that add up to $300 to $800 a year without anyone noticing. Hosting matters more than people think here, and the shared-versus-managed decision has real cost consequences we broke down in choosing WordPress hosting.

Custom builds carry the heaviest tail. Dependencies rot. A Next.js major release, a Node LTS end-of-life, a breaking change in your CMS SDK: each one is a small project. Commission a custom build without a maintenance retainer and you have bought a site that will be functionally unmaintainable in about three years.

When custom is the only sane choice

We recommend a custom build in a minority of briefs, and the tell is always the same: the site does something.

• Non-trivial logic. Quoting engines, configurators, availability checks, anything with business rules in it.
• Permissions. The moment different users see different data, templates stop helping.
• Scale of content with structure. 5,000 products with faceted search and filter state in the URL is not a theme problem.
• The design is the product. If the brand’s differentiation is genuinely visual, a template will always look like a template to the people who care.
• Integration depth. Two-way sync with an ERP, SSO, audit logging.

What does not justify a custom build: “we want it to be unique”, “we might scale later”, “our brand is different”. Those are real feelings and terrible budget lines. A well-chosen template, retyped and recoloured properly, will look nothing like its demo. Most of what makes a site look generic is stock photography and default type scale, not the underlying grid.

The hybrid that wins most briefs

The configuration we ship most often at SemiColonWeb: a licensed component library as the design foundation, a CMS only where the client genuinely edits content, static hosting, and hosted services for anything that needs a server.

Practically, that means taking a multi-demo template like Canvas for the markup and components, then building the actual site as your own thing on top of it. You are buying a head start on 1,400 pre-built blocks and cross-browser CSS that someone else already debugged, not buying a finished site. The difference in mindset matters. Treat the template as a component library and you will be fine. Treat it as a finished website and you will fight it.

The counter-case, honestly stated: if your client will need to build new page layouts themselves every month, hand them a builder or a well-configured block-based WordPress setup and walk away. A static template site where every content change routes through a developer is a false economy. We have seen clients pay $200 in dev time to change a phone number. Twice.

A 20-minute decision framework

Answer these five in order. Stop at the first “yes”.

1. Does the site need server-side logic or per-user data? Yes means custom, or custom front end on a headless backend.
2. Will non-technical staff need to create new page layouts, not just edit text? Yes means a builder or block-based CMS.
3. Is the content set over roughly 200 pages, or does it need structured relationships? Yes means a CMS with a custom or template-based theme, not a builder.
4. Is there a budget under $10,000 and a deadline under eight weeks? Yes means template, and be firm about design deviation.
5. None of the above? Template. It is almost always template.

Then run one more check before you commit: write down the three things the client will most likely ask for in month six. New landing page. Case study section. Multi-language. If your chosen route makes any of those a rebuild rather than an addition, you chose wrong.