A template is the right choice for most software companies until one of three things happens: the site can no longer explain what you built, it cannot change at the speed you are learning, or the platform is stopping you being found. Until then, custom development is an expensive fix for a problem you do not have.
That is not the usual advice on this subject, because the usual advice is written by people selling custom builds. Here is the version that accounts for where you actually are.
Why templates are correct early
Before you know who buys and why, your site is a hypothesis. Hypotheses change weekly. A template lets you change them in an afternoon, for the price of a subscription, without opening a ticket with anyone.
More importantly, the constraint early on is almost never the website. It is that not enough people have heard of you, or that the ones who have cannot tell what you do. Neither is fixed by a rebuild. Founders reach for a redesign because it feels productive and because it is easier than the messaging work underneath it.
If your positioning is still moving, a custom site will preserve last quarter's confusion in more expensive code.
The three thresholds
Templates stop being adequate at identifiable points. Not before.
The site cannot explain the product
This is the most common and the most misdiagnosed. If you are selling something genuinely new, or technical enough that the value is in how it works, template structures fight you. They are built around a hero, three benefit cards and a testimonial strip, which suits a service business and suits a novel product badly. When you find yourself repeatedly cutting the explanation to fit the layout, the layout is now the problem.
You cannot ship at the speed you are learning
You test a message on a call, it lands, and you want it on the site that day. If that takes a week, or a developer, or a workaround, the site has become a bottleneck on learning rather than a record of it.
The platform is limiting how you are found
Slow pages, unreliable markup, no control over what gets rendered server-side. This is the one founders notice last and it compounds quietly. If crawlers cannot read your content, nothing else about the site matters.
One threshold crossed is a reason to consider it. None crossed is a reason to wait.
What a custom build actually buys you
Not aesthetics. You can get a good-looking site from a template and a designer for a fraction of the cost.
What you buy is control over structure, meaning the freedom to organize a page around your argument rather than around a template's assumptions. For a product that needs explaining, that is the whole difference between a site that converts and one that people bounce off politely.
You buy speed you own. Performance stops being a property of someone else's platform and starts being something you can fix.
You buy control over what machines see. This matters more than it did. Search crawlers and AI answer engines read your markup, and increasingly the second group decides whether you get mentioned at all. If your content only exists after JavaScript runs, some of those crawlers will never see it. A custom build lets you decide what is in the HTML.
And you buy a system rather than a page. Components you reuse, content you can add without a developer, a structure that survives the next twenty pages.
What it does not buy you
Traffic. A custom site does not rank because it is custom. It ranks for the same reasons any site ranks, and a beautifully engineered site with nothing to say will sit at position 60 like everything else.
Conversions, by itself. Layout helps at the margin. What converts is whether the page makes a specific promise to a specific person, and that is a writing problem before it is a design problem. Most of the lift people attribute to a redesign came from the message rewrite that happened alongside it.
Time. A real build takes months, and during those months your positioning will move. Plan for the site to be wrong by launch and easy to correct.
Where the money actually goes
Anyone quoting you a price range without seeing the project is guessing, so we will not print one here. The cost is driven by four things, and knowing them lets you read a quote properly.
Scope is measured in unique page types, not pages. Twenty pages sharing three templates is a small project; six pages that each work differently is not.
Integrations are where estimates go wrong. Anything talking to another system, whether auth, billing, a CMS or a product API, carries risk, so ask specifically what happens when one of them changes.
Content is the most underestimated line and it is usually yours. Builds stall waiting for copy far more often than for code.
Who does the work decides more than the day rate. A senior person for six weeks and a junior team for six months can price identically and produce very different results.
The question worth asking a prospective partner is not what it costs. It is what you own at the end and how you change it without them.
Questions to ask before you commit
Ask what happens when you want to change a page yourself. If the answer routes through them for anything beyond text edits, you have bought a dependency rather than an asset.
Ask what the content will look like in raw HTML, before JavaScript. If they do not immediately know why you asked, they are not thinking about how you get found.
Ask them to describe a project where the approach did not work.
Ask who writes the copy. If the answer is you, that is fine and it needs to be in the plan, because it is the thing most likely to delay the launch.
Ask what they would do instead if you told them your budget was a quarter of the estimate. A good answer exists. An offended one tells you something.
What good looks like afterwards
Not a launch announcement. Three practical outcomes.
You can publish a new page without asking anyone. You can find the sentence that explains your product on the page, in the first screen, in plain language. And someone fetching the page without running JavaScript sees the content.
If a rebuild does not deliver those three, it was a redecoration.
The smaller and less glamorous work often matters more than the rebuild: the marketing surface nobody owns covers the microcopy that quietly determines whether people get through your product at all. If you are assessing an existing site rather than replacing it, the website redesign checklist is the more useful starting point.