Website Builder vs Developer: The Row Nobody Prices
Six image findings worth 1.67s of load delay, three a11y defects that survived a Lighthouse 100, and the third path both options' marketing pages skip.
A website builder is a hosted drag-and-drop platform — Wix, Squarespace, Shopify — where you trade control for speed and pay monthly forever. A developer writes the site in code, which costs more up front and gives you something you own. The choice is not really builder-versus-developer, though: it is whether anyone on your side will ever need to change the thing after launch.
That question has a better answer than either option's marketing page, and it is not the one the comparison posts usually land on. Below is the honest version, including a third path those posts skip, and some numbers measured on a real site rather than quoted from a pricing table.
The comparison, on the axes that actually diverge
| Website builder | Developer | Template + developer | |
|---|---|---|---|
| Up-front cost | ~$0 | High | Low (template price) |
| Ongoing cost | A subscription, indefinitely | Hosting only | Hosting only |
| Time to launch | Days to weeks | Weeks to months | Days to weeks |
| You own the output | No | Yes | Yes |
| Ceiling on customisation | The platform's | None | None |
| Who can edit it later | Anyone | A developer | A developer |
| Performance is your problem | No | Yes | Partly — see below |
| Accessibility is your problem | Partly | Yes | Partly |
Most of that table is uncontroversial and you can find it anywhere. Two rows are the ones worth arguing about.
"You own the output." On a builder you are renting the output. The practical test is not philosophical: export your site and try to host it somewhere else. If you cannot, then every future decision — pricing changes, a feature you need, the platform sunsetting a product — is made by someone else. That is a real risk and it is also frequently an acceptable one. A restaurant with a menu and a map does not need to own its markup.
"Performance is your problem." This is the row that reverses the usual conclusion, and it is where measured numbers beat opinions.
The row nobody prices: quality is work, not a side effect
The pitch for hiring a developer is that a hand-built site is faster and more accessible than a builder's. That is achievable, not automatic — and the gap between those two words is billable hours that estimates routinely leave out.
This storefront is a hand-built Next.js and Tailwind site, and it is measured rather than assumed. Current Lighthouse scores, desktop, across eight main routes: performance 100, accessibility 100, SEO 100 on all eight. On mobile — which is the half most projects never measure — performance runs 89 to 99, with accessibility and SEO at 100 throughout.
Those numbers took dedicated passes to get, not good intentions. Three examples of what "accessibility is your problem" means in practice, all three found on pages that were already scoring 100 before anyone looked closely:
/bloghad no<h1>at all. The index heading used a defaulth2, so the page never stated its own subject — invisible in an automated score, obvious to a screen-reader user landing there./docsskipped fromh1straight toh3. A broken outline, again passing the automated check.- A tag chip missed AA contrast by a hundredth. Brand blue
#465fffon a#f2f7fftint at 12px measures 4.49:1. The AA threshold is 4.5:1. It shipped looking perfectly fine and was non-compliant.
None of those three is visible in a design comp, and none was caught by the score that was already 100. That is the honest argument for a developer: not that code is automatically better, but that someone has to go looking. It is also the honest argument against assuming a custom build gives you quality for free — should I hire a web designer is the longer version of that point.
A builder, meanwhile, hands you its platform's performance and a theme's accessibility. Sometimes that is better than what a rushed custom build produces. It is rarely better than what a careful one produces, and you cannot fix it when it is wrong.
What "you cannot fix it" costs: six image findings
The clearest way to see the difference is a list of things that were wrong on this site, were found by measuring, and were fixable because the markup was ours. The home page was shipping 2.6 MB of images and /templates 14.7 MB across its grid. The audit that followed:
| Finding | Before → after |
|---|---|
| Card covers served the full SEO-size JPEG | 255 KiB → 33 KiB per cover |
| 440 carousel slides were JPEG | public/images 117 MB → 93 MB |
| Logo was 681×239 for a mark rendered at 32px — on every page, twice | 70 KiB → 9 KiB |
| Hero art had no small-screen alternate | 87 → 45 KiB, plus an 800w srcset |
| 19 marketing images were unconverted (some PNGs were secretly JPEGs) | 1793 KiB → 550 KiB |
The LCP image on /templates was loading="lazy" | 1.67s of load delay recovered; mobile 85 → 92 |
That last row is the one to hold on to. A single wrong attribute on a single image cost 1.67 seconds of load delay, because the browser could not discover the image until layout had run. Finding it required measuring; fixing it required owning the component.
On a builder, four of those six findings are not yours to fix. You can compress what you upload, and that is roughly where your control ends — image sizing, loading attributes, srcset generation and theme asset weight all belong to the platform. On a custom build every one of them is a lever, which is also to say every one of them is a chore nobody does unless it is in the budget.
What the monthly fee actually compounds to
The builder's monthly fee is the number people underweight, because it is small and recurring while the developer's invoice is large and one-off. Check it yourself for the plan you would actually need — the tier with a custom domain and no platform branding, not the free one — and multiply by sixty. That is a five-year commitment at the end of which you own nothing, and your content is still inside someone else's editor.
The counter-argument is just as real: a developer's quote is not the end of your spending either. A custom site has a maintenance line — dependency updates, a framework major, the post-launch rework pass that every project has and no estimate contains. Website maintenance cost and website development cost break both halves down; the short version is that "one-off vs monthly" is the wrong frame, and total cost over the period you will actually own the site is the right one.
The third path the comparison usually omits
Both options are presented as a binary, and there is a middle that gets most of the developer column's benefits at a fraction of the up-front cost: buy the UI, hire for the parts that are yours.
A production template is a finished, owned codebase — real code on your machine, deployable anywhere, no monthly platform fee, no customisation ceiling. What you are buying is the four-to-nine weeks of UI work that sits between an installed framework and a presentable site, which is the expensive and least differentiated part of the quote. Your developer then spends their hours on the parts a template cannot know: your content, your integrations, your business logic.
This is not a free lunch, and the table above says "partly" for a reason. A template hands you a measured starting point — the accessibility and performance passes are already done, which is genuinely most of the work — but it cannot keep them for you. Add a heavy hero image or a third-party script and you own the regression. What you get is a floor, not a guarantee.
Template vs building from scratch prices this path properly, including the cases where it loses.
Which to choose
| If this is you | Choose |
|---|---|
| Brochure site, content rarely changes, no developer on hand | Builder |
| Non-technical team that must edit copy daily, no dev budget | Builder |
| Genuinely novel product, custom logic, no reference design | Developer, from scratch |
| Strict performance or accessibility obligations | Developer — and budget the passes |
| Standard shape (marketing site, dashboard, storefront), have or can hire a developer | Template + developer |
| Will outgrow a builder within two years | Skip the builder; migrating later costs more |
That last row is the one that quietly decides most of these. Moving off a builder means rebuilding, and if you have accumulated search rankings in the meantime, it means migrating without losing them too. Choosing the builder is cheap; choosing it twice is not.
FAQ
Is a website builder worse for SEO? Not inherently. Modern builders emit reasonable markup and handle sitemaps. What you lose is the ability to fix anything they get wrong — control over metadata, structured data, redirects and crawl behaviour stops where the platform's settings stop.
Can a developer just build on top of a website builder? Sometimes, and it is often the worst of both: you keep the monthly fee and the platform ceiling, and you pay developer rates to work around them. If a developer is involved anyway, the builder is usually the thing to drop.
How much of a custom build is design versus code? On a conventional marketing site or dashboard, the UI layer is the bulk of it, which is exactly why the template path exists. Novel interaction or real business logic flips that ratio — that is when building from scratch earns its cost.
Do I need 100 Lighthouse scores? No. They are a proxy, not a goal, and the three defects above all survived a 100. Treat the score as a floor that catches regressions, and treat accessibility as something a person checks.
Templates built for the third path
If the last row of that table is you, the starting point matters: a template that already carries the measured passes saves you the part of the invoice that buys no differentiation. The Next.js landing page templates and Tailwind landing page templates are built and measured the way this post describes — owned code, no platform fee, accessibility and performance work already done.