, updated · 3 min read
Why we build custom over templates
Why templates are fast at first and slower later, when they are still the right choice, and what to ask before picking one.
The Template Trap
Templates look excellent in a demo. Pick a theme, drop in a logo, change some colours, and something is live by the weekend. The trouble arrives later, and it arrives in a predictable order.
First you need a feature the template does not support. Then a plugin update changes a layout you had customised. Then you discover the data model belongs to someone else and your requirements have to bend around it. The first fifth of the work is remarkably fast. The rest is slower than starting from a blank page would have been.
What Custom Actually Means
Custom does not mean writing everything from nothing. Nobody sensible builds their own routing, their own component primitives or their own database driver.
It means choosing a foundation deliberately and building only what the product needs on top of it. No features you are shipping to users but not using. No third-party plugin dictating how your records are shaped. No design decisions inherited from a theme built for a different business.
The result is a codebase where a change you need is a change you can make, rather than a negotiation with something you do not control.
The Cost Comparison People Get Wrong
Custom costs more at the start. The comparison that matters is not the first invoice but the second year.
A template project tends to accumulate workarounds. Each one is small, each one is reasonable at the time, and together they become the reason a simple request takes a fortnight. Custom projects accumulate too, but they accumulate in code you can read, delete and restructure.
The honest version is this: if the product will not change much, the template wins. If it will, the template is a loan with interest that compounds.
Where Templates Are The Right Answer
A marketing site that will not change structurally, a campaign landing page, an internal tool with five users and no roadmap. These are good uses of something off the shelf, and building them from scratch wastes money.
The real question is whether this particular product is going to keep changing, and whether the thing you are building is core to the business or adjacent to it.
Questions Worth Asking First
- Will the data model be unusual? If your records do not look like blog posts or products, a content-shaped template will fight you.
- Who owns it in two years? A codebase your team can hire for is worth more than one dependent on a theme with an uncertain future.
- What happens when the template stops being maintained? This is not a rare event.
- Is this the product or is it around the product? Spend your effort on the part that is actually yours.
A Reasonable Middle
Plenty of projects sit between the two. Use a template for the marketing site and build the application properly. Use a component library rather than a full theme, so you inherit the tedious parts without inheriting someone else's architecture.
The failure mode we see most is not choosing a template. It is choosing one for something that was always going to become a real product, and discovering that twelve months in.
