Nobody buys a template site and regrets it in the first month. That is the whole problem. The template does exactly what it promised: a professional-looking site, live in three weeks, for a fraction of what custom development costs. Judged on the day it launches, it is the correct decision, and anybody who tells you otherwise is selling something.

The bill arrives later, and it does not look like a bill. It looks like a series of small requests that each take much longer than they should.

The first workaround is always reasonable

Here is the shape it takes, and it is remarkably consistent across the rebuilds we get called into. Someone in the business asks for something ordinary — show pricing differently for wholesale customers, add a field to the enquiry form that routes to a different team, display stock levels from the warehouse system. Nothing exotic.

The template does not support it. Not because the author was careless, but because they were building for the general case and your business has just asked a specific question. So somebody finds a way: a plugin that almost fits, a snippet pasted into the theme's functions file, a custom field bolted onto a content type that was never meant to carry it.

That workaround is genuinely the right call in isolation. It costs four hours instead of four weeks. The problem is that it is now load-bearing, undocumented, and invisible to the next person — including the template author, who will ship an update that assumes their own code is still intact.

Every workaround raises the cost of the next one. That is the entire mechanism.

Compounding, not accumulating

Technical debt on a custom codebase accumulates. You add things, they sit there, you pay interest. Unpleasant but linear, and a competent team can pay it down deliberately.

Debt on a template compounds, because each workaround constrains what the next one can do. Workaround three has to be compatible with one and two. Workaround nine has to be compatible with eight predecessors, none of which were designed to coexist, several of which were written by people who have left. By the time the business asks for something genuinely important, the honest estimate is not "two weeks" — it is "two weeks, and there is a real chance it breaks checkout".

This is why template site rebuilds so often get triggered by a request that sounds trivial. It was trivial. It just happened to be the one that finally exceeded what the accumulated workarounds could absorb.

Four symptoms, in the order they usually appear

1. Updates become frightening

The theme or plugin update has security fixes in it. Nobody applies it, because last time something broke and it took a day to find out what. So the site sits on an outdated version with published vulnerabilities, and the decision not to update is never actually made by anyone — it just keeps not happening.

2. Simple changes need a specialist

Editing a page is easy; changing how pages work is not. Marketing can update copy but cannot add a section, because the sections are defined in a theme file that three workarounds depend on. Every structural change queues behind whoever understands the accumulated exceptions.

3. Performance degrades without anyone changing anything

Each plugin loads its own CSS and JavaScript on every page, whether or not that page uses the feature. Fourteen plugins later the homepage ships two megabytes of code to render a headline and a photograph. Nobody made the site slow; it got slow by addition. This one shows up in Core Web Vitals long before anyone connects it to revenue.

4. Integration requests get quietly declined

The most expensive symptom, because it never appears as a cost. Someone proposes connecting the site to the ERP, the CRM, or the inventory system. The estimate comes back high enough that the project dies, and the business carries on with a manual process. The template did not just fail to deliver a feature — it removed an option, and the removal was never recorded as a decision.

When a template is still the right answer

We build custom systems for a living and we will still tell you to use a template sometimes. That is not modesty; it is that the failure mode above requires a specific precondition — a business whose requirements will diverge from the general case.

Templates hold up indefinitely when all of the following stay true:

  • The site is primarily informational and the content model is genuinely simple.
  • No integration with an internal system is needed, now or plausibly later.
  • Nobody has asked for behaviour the platform does not offer natively.
  • The site is not a material part of how revenue is generated.

A local service business with eight pages and a contact form should not be commissioning custom development. It would be a waste of their money and we would say so on the assessment call.

The actual decision

The question is not "template or custom" in the abstract. It is: how far will this business's requirements diverge from the general case, and how soon? If the answer is "not much, not soon", buy the template and spend the difference on something else. If the answer is "significantly, and we already have three examples", every month spent on the template is buying debt at a compounding rate.

The tell is the workaround count. One is fine. Three is a signal. When you cannot remember them all without asking someone, the platform has already stopped being the cheap option — the spending just moved somewhere nobody is tracking it.

If that describes your site, a redesign that audits before it rebuilds is the version of this work that keeps what already earns. And if you would rather find out what the workarounds are actually costing before committing to anything, send us the URL — the assessment is free and occasionally concludes that you should leave it alone.