Build from scratch, or use a template? An honest framework.
The practice says we build from a blank repository on every engagement. That is not the right answer for every project. Here is when it is, and when it isn't.
The practice has a line we use a lot: every engagement begins on a blank repository. It is true, and it is the right policy for the work this practice takes on. But it is also the kind of line that, if applied to every prospect's project regardless of fit, would be doing the prospect a disservice. So here is the honest framework — when building from scratch is the right answer, and when a template is the better one.
Use a template when the project is a standard solved problem. The fastest way to identify one: ask whether the project's success depends on it being uniquely yours, or just on it being good. A five-page marketing site for a small business is a standard solved problem; thousands of small businesses have shipped them, and Webflow / Squarespace / Wix all have templates that get you 80% of the way for a small fraction of what a custom build would cost. If the difference between a template and a custom build is only the color palette and the copy, the template wins on every axis — time, cost, maintainability, and your team's ability to update it without us in the loop.
Use a template when the time-to-market constraint is severe. A startup that needs a landing page to start collecting waitlist signups by Friday should not be hiring a custom shop. A coach who wants to start taking bookings next week should not wait six weeks for a bespoke booking flow. The right move is to ship a template now, validate the demand, and then consider whether a custom rebuild later is justified by what you've learned. The mistake we see most often is the inverse — a prospect who wants to do everything custom from day one and ends up spending six months on the website while the actual business waits.
Use a template when the budget is genuinely tight. Custom software costs what it costs because of the time required to do it well. A template costs less because most of the work has already been done. If the budget for the entire project is under, say, $5,000, the honest answer is that the budget is too small to do a custom build well — and we will tell you so during discovery, with a referral to a template-based path. Nothing erodes a vendor relationship faster than agreeing to do a custom build on a template budget; the corners that get cut to fit will haunt the work for years.
Build from scratch when the operation depends on it being *yours*. A custom intake flow with conditional logic that mirrors how your specific business qualifies leads is not a template-able problem; the business logic is the build. A coach's website with a standard "schedule a session" button is a template problem. A coach's website with a custom multi-step intake that pulls in the prospect's training history, calculates their starting program, and routes them to one of three coaching tracks is not a template problem. The dividing line is whether the unique-to-you logic is the substance of the experience or a decoration on top of a generic one.
Build from scratch when the build will be the operational system that runs the business. Internal tools — CRMs, ops consoles, custom dashboards, workflow systems — almost never have a template that fits well, because every business runs its operation slightly differently and the cost of adapting a generic template to the actual workflow usually exceeds the cost of building the workflow's right shape from the start. The exception is when the workflow is genuinely standard (a basic CRM, a standard project tracker), in which case you should use the SaaS that already exists rather than build one.
Build from scratch when the integration surface is unusual. Most templates assume the standard set of integrations (Stripe for payments, Mailchimp for email, etc.). The moment your project needs to talk to a system that is not in the template's default integration list, the cost of forcing the template to do something it was not designed for usually exceeds the cost of building the right thing from the start. This is also where we see the most overpromising from template-based agencies — promises of "we can integrate anything" that turn into "actually that integration is a custom build inside the template, and it costs $X more."
Build from scratch when the maintenance horizon is long. Templates are maintained by their vendors, and template vendors come and go. If the system needs to run for ten years and survive the disappearance of its underlying template (Squarespace going out of business, a WordPress theme being abandoned, a no-code platform pivoting away from your use case), the long-term cost of being dependent on the template vendor exceeds the upfront savings. Custom builds, by contrast, are dependent on the language and framework — which are far more durable than any specific template.
Build from scratch when the security surface is sensitive. Templates carry the security posture of the entire pool of sites that use the template; one vulnerability in the template affects everyone. Custom builds carry the security posture of the engineers who wrote them — and if those engineers treat security as a design constraint from day one (we do), the result is structurally more defensible than the template.
There is one important nuance that does not fit cleanly on either side: most engagements are not purely one or the other. A custom build for a coach's website may use an off-the-shelf authentication library, a standard payments SDK, and a battle-tested email-sending service — but the website's actual shape, the intake logic, the conversion path, and the editorial structure are all custom. The question is not "template vs. custom" as a binary; it is "which layers of this build should be inherited from a well-maintained third party, and which layers should be written specifically for this business." Senior engineering is in the second decision.
When a prospect asks us "should we use a template or build from scratch?" the honest answer requires understanding the project. If the answer is "use a template," we say so and recommend one. If the answer is "build from scratch," we explain why and quote the work. We have referred away enough small-budget marketing-site projects to template-based competitors that the policy is not theoretical — it is just the right thing to do.
The compressed version: templates are tools, not enemies; custom is craft, not always the answer. The right path for any given project is the one that delivers a system the business can run on for as long as the business needs it to run, at a cost the business can justify, with a maintainability story that does not depend on us being around forever.
If you have a project in front of you and you are not sure which side of the line it falls on, write to us. We will tell you, even if the answer is that you should not hire us.