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.
- within the settingsLow effortsolvable from the options panel
- beyond themRises steeplyoverrides, workarounds, reading someone else's code
the break is not at some amount of customisation, but where the template's settings end
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 isn't merely permissible — it is the responsible choice. Anyone selling custom development here is invoicing their own professional entertainment.
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.
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.