What a template can do, and where it stops
It's customary in this trade to look down on templates. That's a comfortable position, and simply not true — the question isn't whether a template is good, but what for.
Let me start with what we rarely say out loud: a template is often the right choice, and there's no shame in it. Anyone claiming otherwise has either not worked across enough budgets, or has an interest in selling something dearer.
What a good template genuinely gives you
A finished structure. A template isn't a collection of pictures but a considered layout: where the header sits, how it reflows on mobile, what happens with a long title. Someone has already done that work, and many people have tested it.
Responsiveness you don't have to reinvent. Handling screen sizes is dull and time-consuming work. In a widely used template it has been thought through, including at sizes you wouldn't think of on your own.
A quick start. If the task is to have something in two weeks that makes the business findable, a template isn't a compromise but common sense. The remaining budget can go where it actually counts: the copy and the photographs.
Where it stops
The boundary is where the wish steps outside the range of the settings. As long as the template's own switches get you what you want, everything is fast. The first request with no switch behind it is a different order of magnitude.
- custom layout, from scratch10 hoursthe structure is ours from the start
- the same forced out of a template20 hoursunderstanding, overriding, and surviving the next update
orders of magnitude, not measurements
The reason is structural. A template is built on its own logic, and every deviation works against it. Building a custom layout from scratch might take ten hours; forcing the same thing out of a template can take twenty — because first you have to understand how somebody else thought about it, then override it in a way an update won't wipe out.
This is the point where the decision ought to be reconsidered, and precisely the point where it never is: by then there's a half-finished site nobody wants to throw away.
The page builder is a separate question
A template and a page builder aren't the same thing, and the builder has a consequence that rarely gets mentioned: its output is stored in the builder's own format, not as portable HTML.
In practice this means the content survives — the text and the images aren't lost — but the layout isn't portable. If someone later drops the builder, the pages have to be rebuilt. That isn't a fault but the nature of the tool; the problem only arises when nobody said so in advance.
It has an operational consequence too: the builder's data is stored as JSON containing escaped URLs, which is why the old domain survives on images after a move even though the usual replacement ran. That's the subject of the piece on deploy traps.
When to choose a template
Four signs that together are decisive: the requirement is conventional (introduction, service list, contact); the content is the point, not the interface; you need to launch quickly; and the budget is finite, so where it goes matters.
In that situation a template is a defensible choice. Anyone selling more expensive custom development here is invoicing their own professional entertainment.
These four signs settled the question for a long time, and anyone who chose that way chose well. The reason, though, was price and time — which is what the last section is about.
When not to
If the site has a process of its own — booking, payment, access, notifications — a template doesn't speed things up, it gets in the way. In that kind of system the interface is the smaller part; the work is the joining up, and a ready-made theme doesn't help with that.
If the content doesn't fit the template's structure. A long, layered service description simply truncates or falls apart in many templates, and at that point we start adapting the content to the interface — which is backwards.
And if the site lives long, with many extensions. There, sooner or later every request lands beyond the limits of the settings, and the accumulated workarounds make the work slower than writing your own code would have been from the start.
What carried that argument
Three of the four signs above come down to the same thing: the template was faster and cheaper. The structure, the responsiveness and the bugs already walked through were paid-for work that did not have to be done again. That advantage was real.
The difference has since gone. A clean custom theme costs what configuring a bought template and fighting through its customisation costs — and the last ten percent above is left out of it, because there is nothing to override. The template's strongest argument was price, and it is the price that moved.
The other arguments stand. A template still gives a considered structure, and anyone it works for has no reason to replace it. A choice starting now, though, reaches a different answer than it did before. What that means in my own work is on the What I build with page.
Questions on this topic
When is a template the better choice over custom development?
When the requirement is conventional, the content is what matters, and you need to launch quickly. For a brochure site where text, images and a contact form are the job, a template is ready in days, works properly on every screen, and the remaining budget can go where it counts: the content.
Why does customisation get expensive?
Because a template is built on its own logic, and every deviation works against it. While the wish fits within the settings, it's quick; the moment it steps outside them, something has to be overridden that you can't see behind. The last ten percent can therefore cost more than the first ninety.
What does it mean that the builder's output isn't yours?
That the page structure is stored in the builder's own format, not as portable HTML. If you later drop the builder, the content survives but the layout doesn't — it has to be rebuilt. That isn't a fault, it's how these tools work; it just pays to know in advance.
Can you tell that a site was built from a template?
Usually yes, and that isn't a problem in itself. Visitors don't look at the technology; they look at whether they find what they came for. A template only becomes a visible weakness when the content doesn't fit its structure, and so gets truncated or falls apart.