The case for bespoke

Why the best digital products aren’t built from templates — and what you actually get when you invest in something made from scratch.

The honest pitch against templates

I’m not going to pretend templates are wrong. Squarespace built a legitimate business. Webflow is genuinely impressive. For a lot of use cases, picking a good theme and customising it is the right call — faster, cheaper, and more than good enough.

But “more than good enough” is doing a lot of work in that sentence. Good enough compared to what? Compared to what your competitors are doing? Compared to what your customers expect? Compared to what the software could do if it weren’t constrained by someone else’s design decisions?

The problem with templates isn’t the templates themselves. It’s that they optimise for the average case. Your case is not average. Your workflows, your customers, your content, your edge cases — none of them were in the product brief when that template was built.

What you actually pay for with bespoke

When a client comes to me for a custom web app, I’m not charging for lines of code. I’m charging for the thinking that happens before the code gets written — the questions that expose assumptions, the scope that gets drawn carefully so nothing important is left out, the architecture decisions that make the next feature cheap instead of expensive.

The real value A custom build doesn’t just do what you need today. Done right, it can do what you’ll need in six months without a rebuild.

Template-based products get expensive fast when requirements diverge from what the template assumed. Custom builds start expensive and get cheaper — the marginal cost of the next feature, once the foundation is right, drops dramatically.

The aesthetic argument

Beyond function, there’s a reason bespoke things feel different. When every element has been considered — not inherited from a component library or constrained by a theme’s opinion of what a button should look like — the result has a coherence that’s hard to fake.

“You can tell within ten seconds whether a site was built or bought. The clients who understand this are the ones worth working with.”

This matters most for brands where the digital experience is the product — where first impressions carry real commercial weight, and where “looking like everyone else” is exactly the thing you’re trying to avoid.

When not to go bespoke

A content site for a business where the web presence is an afterthought? Use a template. A blog? Use a CMS. A landing page for an idea you’re testing before committing? Carrd, Webflow, whatever ships fastest.

Bespoke is right when the software is the experience. When the interaction model matters, when performance is a feature, when you have requirements that no template was designed to handle.

My job, when a client calls, is to figure out which of those situations they’re actually in — and to tell them honestly which path makes sense. Sometimes that means I talk myself out of work. That’s fine. The clients who come back are the ones who remember I gave them a straight answer.

Starting from scratch, done right

“Built from scratch” sounds slower than it is. With the right toolchain and a designer who’s done it before, a custom web application can be live in weeks, not months. The difference is that you end up with something that fits — your brand, your workflow, your edge cases — instead of something that almost fits and requires constant workarounds to make usable.

The projects I’m proudest of are the ones where the client stopped thinking about the software. Where it receded into the background and let them focus on their actual work. That’s the goal: invisible infrastructure, not impressive technology.

The right tool for the job is rarely the most popular tool — it’s the one that fits how you actually work.

If you’re deciding between a template and something bespoke, the question isn’t really about cost. It’s about what your product needs to be. If you need a brochure, use a template. If you need a tool — something that will handle real users, real data, and real complexity — consider building it properly once rather than retrofitting it forever.

That’s not always the answer I give. But it’s always the honest one.

← Why I built Rubbish Day What 3D rendering taught me about design →