A client asked us last spring to rebuild their marketing site “properly, from scratch.” Two calls in, it turned out the real problem was a slow theme and three plugins fighting each other. We fixed the load time in an afternoon and talked them out of the rebuild. That is the part of web work most people skip: deciding whether to build at all.
Custom web development gets sold as the serious choice, the thing real companies do. Sometimes it is. More often it is a bigger bill and a longer wait for a result a good template would have given you in a week. What follows is a builder’s view of when a custom site is worth it, how one actually gets made, and where these projects go wrong. It sits next to our piece on agentic AI, our take on custom software, and how we build for the web at PTAS.
What a custom build actually buys you
Custom web development is a site or web app built around your content, your users, and the systems you already run, instead of a theme you bend your business to fit. That is the whole definition. Everything after it is detail.
What you are really buying is fit and control. The pages do what your business does, in the order it does it, and you decide what changes next. A template hands you someone else’s idea of how a site should behave, which is fine right up until your content stops looking like everyone else’s, or you need it to talk to a system the theme author never imagined.
The catch is that fit and control are also the work. You own the performance budget. You own the security updates. You own the call, a year from now, about whether it still earns its hosting bill. None of that shows up in the design mockup.
When a template is the right call
Most of the time, use a template. I say that as someone who builds custom sites for a living. If a standard marketing site, blog, or simple store does the job, a good theme on WordPress, Webflow, or Shopify will be cheaper and faster than anything we can hand-build, and it keeps getting better while you sleep because someone else is paying for that.
Custom starts to make sense in a few specific spots. When the site is how you sell, and a half-second of load time or one awkward step in the flow costs you real money. When you have honestly tried the builders and they cannot model how your product or booking or quoting actually works. When the site has to plug into your own software, your pricing engine, or your data, and the template can only fake it with a form. Those are real reasons. “We want something that feels premium” usually is not, at least not on its own.
How a web build actually goes
People picture a web build as a long stretch of design and code. The code is the easy part. Most projects live or die in the weeks on either side of it. The shape is almost always the same four phases.
Discovery
Work out what the site has to do, who it is for, and what counts as a win. Most flops trace straight back to skipping this.
Design
Decide the structure: pages, the path you want people to take, and how it connects to your other systems. Expensive mistakes are made or avoided here.
Build
Ship real pages every week or two, so you react to a working screen on your phone instead of a flat picture in a deck.
Run
It keeps needing updates, security patches, and small content changes after launch. Budget for that or regret it later.
Discovery, or working out what the site is for
This is where someone sits with you and figures out what the site has to do, which is harder than it sounds, because people describe the page they already have, not the result they want. The job here is to separate the one or two things that move the business from the long list of things that would be nice. A site that does three things well beats one that does fifteen badly.
What the first two weeks look like
We map the journeys that matter, usually three at most: the visitor who is ready to buy, the one comparing you to two competitors, and the one who landed by accident and needs a reason to stay. Then we write down what each of them should be able to do, and how we will know it worked. If we cannot measure it, we do not build it yet.
Design and the front end
Design is where the awkward questions surface. Where does the price live? What happens on a slow phone on a train? Which step are people quietly abandoning today? We answer those on paper and in clickable screens before anyone writes the production code, because changing a layout in a design tool costs minutes and changing it in a shipped site costs days.
Building and shipping in slices
We build the site in pieces you can actually open, starting with the page that carries the most weight. You get something real on your phone within a couple of weeks, react to it, and we adjust. The alternative, where you sign off a flat mockup and see the working site three months later, is how teams end up paying to fix things they could have caught in week two.
A quick example
On one build the homepage tested beautifully and the pricing page was the disaster. People scrolled past the plans entirely. We had shipped pricing in week three precisely so we could find that out early, moved the comparison above the fold, and the abandon rate dropped before launch. If pricing had been the last thing we touched, we would have learned it from the analytics after go-live, which is the most expensive place to learn anything.
Some honest numbers
I am wary of the statistics that get quoted in posts like this. “Custom sites convert three times better” tells you nothing about your situation, and I have never seen the study behind it. Here is what we actually see across web builds, with the obvious caveat that yours will differ.
Ranges PTAS sees across real web projects, not industry benchmarks. Yours depend on how much content you have and how many systems the site has to talk to.
The site is how the business presents itself
A website is the version of your company most people meet first, and usually the only one they meet at all. So the way it presents the business is not decoration, it is the product doing its job. Three things carry most of that weight, and a custom build gives you direct control over all three.
Speed, because patience is short
A page that takes four seconds loses people who would have stayed for one. Search engines notice too, and rank accordingly through Core Web Vitals. On a template you tune speed at the edges. On a custom build you control the levers that matter: how images load, what code ships on first paint, what gets cached and where.
Clarity, because nobody reads
Within a few seconds a visitor decides who you are, whether you can help, and what to do next. If the page makes them work for those answers, they leave. Custom work lets you build that hierarchy on purpose instead of arranging it inside the slots a theme hands you.
Access, because it is also a wider market
Building to WCAG accessibility standards is the right thing to do, and it also reaches the large share of people who use the web with a screen reader, a keyboard, or a phone in bright sun. Accessible markup tends to be cleaner markup, which search engines reward as a side effect. You get the ethics and the reach in the same move.
The ways web projects go wrong
When a build disappoints, it is rarely the code.
Designing for the demo, not the data. The mockup uses three perfect paragraphs and a hero photo from a stock library. Then the real content arrives: a 400-word legal disclaimer, a product with no good photo, a name twice as long as the placeholder. Design with your actual content, or you will rebuild every page the week before launch.
Pretending the site is finished at launch. A website is not a poster you print once. It needs security updates, dependency upgrades, and small fixes for as long as it is live. Teams that skip this end up with a site nobody dares touch, which is how a polished launch turns into an embarrassing footer date two years on.
Buying on the lowest quote. The cheapest bid usually wins by leaving things out: testing, accessibility, the analytics that tell you whether any of it worked. You pay for those later, with interest, and the bill tends to arrive the week traffic finally shows up.
So, should you build custom?
If a template does the job, use it and spend your energy somewhere it matters more. If the site is core to how you sell or operate, nothing off the shelf fits how you actually work, or you need it wired into your own systems, a custom build can pay for itself many times over. The honest version is that it is a commitment to keep maintaining something, not a one-time purchase, and the teams who treat it that way are the ones still happy with their site two years later.
If you are not sure which side of that line you sit on, that is worth a conversation before it is worth a quote. A fair number of our scoping calls end with us telling someone a good template will do. That is a perfectly good outcome.