Why a template site is usually the right answer, and when it is not

Why this advice rarely comes from web developers

There is an obvious reason a web developer seldom recommends a template: templates are cheap and custom builds are not. That incentive is worth naming at the start of a piece written by people who build custom sites.

The position is still that most businesses should buy a template. A good one is tested across thousands of sites, maintained by somebody whose only job is maintaining it, fast by default, and available immediately for a fraction of what a build costs. Against that, a bespoke brochure site for a twenty-person company is usually an expensive way to arrive at the same place more slowly.

What changes the answer is function rather than appearance. If a site has to do something, as opposed to describe something, the calculation shifts. The rest of this piece is about telling those cases apart.

It is also worth separating two things that get sold together. A template is a starting point for the design and the code. An agency relationship is a starting point for the thinking: who the site is for, what it should say, what a visitor should do next. You can buy the second without buying a custom build, and for most businesses that combination gives the best result for the money: professional thinking applied to a solid template, rather than amateur thinking applied to a bespoke one.

What a template genuinely does well

Modern templates are good, and the objections to them are mostly a decade out of date. They are responsive, they are reasonably fast if you do not load them with plugins, and they handle the things small sites get wrong: readable type, sensible navigation, forms that work on a phone.

They also solve a problem that nobody budgets for, which is maintenance. A template is updated by its maintainer as browsers change and security issues appear. A custom site is updated by whoever you can persuade to look at it, which after two years may be nobody.

For a business whose website exists to explain what it does, show credibility and collect enquiries, that package is hard to beat on value. Spending the difference on photography, on writing the pages properly, or on the search work covered on our SEO page usually produces more enquiries than spending it on a bespoke build.

There is a hidden advantage to templates that rarely gets mentioned, which is that somebody else has already made the boring decisions correctly. Heading sizes that work on a phone, form fields that do not break on an older browser, focus states that let somebody navigate by keyboard. A custom build has to get all of those right from scratch, and plenty do not, because they are invisible until somebody is affected by them.

The cases where custom is genuinely the answer

Custom earns its cost when the site has to do a job that a template is not shaped for. In practice that is a shorter list than most proposals suggest, and it is worth being specific about.

A warning about the middle ground. Many projects described as custom are a template with substantial modification, which can be the worst of both: the maintenance burden of bespoke code with the constraints of somebody else's structure, and an upgrade path that breaks because the template has been altered beyond recognition. If a proposal is a heavily modified template, ask directly what happens when the template releases a major update.

• The site has to read from or write to your own systems: stock, pricing, job records, a booking diary.
• There is a workflow with steps, states and permissions, which is an application wearing a website's clothes.
• Content exists at a scale where structure matters more than styling, such as hundreds of pages generated from data.
• A calculator, configurator or tool is the reason people visit, rather than a decoration on a page.
• Performance or accessibility requirements are specific enough that inheriting a template's decisions is a risk.

The question that separates a site from an application

A useful test is whether the thing you are describing has users or visitors. Visitors read, look and perhaps fill in a form. Users log in, do something, and expect the result to still be there tomorrow.

Anything with users is an application, and the conversation should move accordingly, because the cost, the maintenance and the risk are all different. That is the territory the custom web application development page covers, and it is a different purchase from a website even when it sits on the same domain.

The confusion between the two is where budgets get lost. A project sold as a website that turns out to need accounts, roles and a database is an application that was priced as a brochure, and it will overrun.

There is a third category that confuses the decision further: a mostly static site with one interactive piece. A brochure site with a quote calculator, or a services site with a client login. The instinct is to go fully custom because one part needs it, and that is usually wrong. The better pattern is a template for the pages and a purpose-built tool for the one thing that needs building, kept separate so the simple part stays simple and the complicated part can be maintained on its own terms.

The cost that is not in the quote

Comparing a template price against a build price compares the wrong numbers, because the build price covers the first version and nothing after it.

A custom site has to be maintained: dependencies update, browsers change, a security issue appears in something it relies on, and somebody has to know enough to act. If that person is a freelancer who has moved on, the real cost of the custom site arrives two years later as a rebuild.

So the honest comparison is over several years, including who will look after it. A business with no technical staff and no support arrangement should weight that heavily. One with an existing arrangement, such as the kind covered on the managed IT support page, carries it more easily because somebody is already accountable.

The second uncosted item is content. A new site needs its pages written, and that work is the same whether the underlying build is bespoke or not. Projects stall at this point far more often than at any technical stage, because writing twenty pages properly is harder than it sounds and usually falls to somebody who already has a job. Budget the time rather than assuming it will happen around the build.

What matters more than either choice

Most sites that underperform do not underperform because of the template question. They underperform because they are slow, because the pages do not say what people search for, or because nothing explains what the business actually does.

Speed is measurable and worth taking seriously: Google publishes the Core Web Vitals thresholds and a heavy custom build regularly scores worse than a clean template, because custom is not automatically fast. Structure is the other half, and Google's own guidance on helpful content is clearer than most agency advice about what actually earns visibility.

Whichever route you take, the writing and the structure do more work than the styling. A plain template with pages that answer real questions will outperform a beautiful bespoke site that says nothing specific, and we have never seen it go the other way.

Accessibility belongs in the same category: not a reason to choose either option, but a standard both should meet. The W3C publishes WCAG as the reference, and the practical items are contrast, keyboard navigation, labelled form fields and alternative text on images. Good templates handle most of it by default, which is one more argument for them, and custom builds have to be asked for it explicitly.

None of this is an argument against caring how a site looks. Design carries credibility, and a site that looks neglected costs trust before anyone reads a word. The argument is narrower: that the visual result depends far more on typography, photography and restraint than on whether the underlying code was written for you, and that money spent on the first three is more visible than money spent on the fourth.

How to decide in an afternoon

Write down what the site has to do, as verbs rather than as pages. Explain the service. Show the work. Collect an enquiry. Take a booking. Check stock. Calculate a price. Let a client see their job status.

Then mark each one as something a template handles, something a template handles with a plugin, or something it cannot do. If everything is in the first two groups, buy the template and spend the difference on content and photography. If two or three land in the third group, you have a custom project, and it should be scoped around those specific functions rather than around a redesign.

If the list is genuinely unclear, that is a conversation rather than a quote. Our custom website development page sets out how we work when custom is the answer, and we will say when it is not. Get in touch if you want the list looked at with you.

One practical caution on timing. Replacing a site that currently produces enquiries deserves more care than building a first one, because there is something to lose. Record what the existing pages rank for and which ones produce contact before anything changes, and make sure every old address points at its replacement. A redesign that quietly drops half the pages is the most expensive version of this decision, and it happens most often when the project was framed as a visual refresh rather than as a migration.

Whichever you choose, settle what you will own before work begins. What handing over the code should mean covers the four things to hold.

If the site also needs to be quotable by AI assistants rather than only found by Google, the build decisions that make that possible are set out in what makes a website readable by AI assistants.

Frequently asked questions

Written by Srinivasan Ramachandran, Founder, Listonics · Published Oct 11, 2026 · Last reviewed October 13, 2026 · 2,088 words