Website builders versus a custom build: an honest comparison

That is not the answer an agency is supposed to give. It is the honest one.

The category has been argued badly for a decade. Builder companies claim you never need a developer. Agencies claim builders are unprofessional. Both are selling. What actually matters is how many pages you need, how often they change, and who is going to maintain the thing after launch.

What do builders genuinely do well?

They remove an entire class of problem you should not be spending attention on.

Hosting, security patches, SSL certificates, backups, and mobile layout are handled. For an owner running a restaurant or a two-truck plumbing company, that is real. Every hour you do not spend on a server is an hour spent on the business.

They are also fast to change. If your hours shift or you add a service, you edit it yourself in ten minutes. A custom site where every text change requires an email to a developer is a worse site in practice, no matter how well built it is.

And modern builders are not slow or unrankable. That criticism was true years ago and it is repeated by people who have not checked since. It also misplaces the cause. Google Research sampled 11 million mobile web domains over a representative 4G connection in January 2018 and found 79% of pages over 1MB, 53% over 2MB and 23% over 4MB, with 25% able to save more than 250KB by compressing images and text alone. Slow pages are mostly heavy pages. A custom build with six uncompressed hero photographs is slower than a builder site with three sensible ones.

If your business has fewer than about fifteen pages and you are the person editing them, a builder is not a compromise, it is the correct tool.

Where do builders actually break down?

Three places, and they are specific.

Page volume. If you serve twelve cities and offer eight services, you are looking at a lot of pages that share structure and differ in detail. Builders make you construct each one by hand, so page ninety looks nothing like page four and the whole thing drifts. This is the most common reason a growing home services company outgrows a builder.

Integration. The moment a form needs to write into your CRM, trigger a text message, and pass conversion data back to your ads account, builder plugins start doing three quarters of the job. Three quarters is worse than nothing, because you trust it.

Ownership of the output. Your content lives inside their system. Exporting a builder site is not a clean process. That is a constraint to know about before you have four years of pages inside it, not after.

There is a fourth issue that is not really the builder's fault. Builders make it easy to publish an inconsistent business. Different phone number in the footer than in the header, an old address on the contact page. Whitespark's 2026 Local Search Ranking Factors report, in which 47 local search experts scored 187 factors, puts HTML name, address and phone details matching your Google Business Profile at 15th with 153 points. That is expert opinion rather than a controlled test, and whether name, address, and phone consistency still matters has a more nuanced answer than the citation industry admits, but a site contradicting itself is never good.

What does the page count arithmetic look like?

Is a custom build worth it for a local business?

Sometimes, and the test is not prestige. It is repetition and integration.

If you need forty pages that follow the same pattern, a custom build lets you define the pattern once. Add a city, get a page, with the right internal links and the right schema, without anybody laying out a template by hand. That is a genuine time saving that compounds.

If your leads have to land somewhere specific, a custom build lets the form do exactly that. No plugin in the middle guessing.

If your brand is a real asset, custom is the only way to get the site to match it, because a builder template will always be a template with your logo on it. That matters more for some businesses than others, and what a logo actually does for a local business is a smaller claim than most branding pitches make.

What a custom build does not do is rank better by virtue of being custom. There is no ranking bonus for hand-written code. Anyone telling you otherwise is selling hours.

What about the AI features my platform keeps offering me?

Ignore most of them, and there is one specific file worth knowing about because your builder may already have created it.

Some platforms now auto-generate an `llms.txt` file, a plain text index intended to tell AI systems what your site contains. Wix does this. It is presented as AI visibility and it is not.

Ahrefs examined every domain in its web analytics product with traffic in May 2026, a population of 137,210 sites, checked which had a real llms.txt returning a 200 response, then looked at every request made to those paths by user agent. 28% of the population published one. 97% of those files received zero requests that month, from any bot or any human. Of the traffic that did happen, 96% was bots, and 77% of those bots were not AI tools at all. AI retrieval bots, the ones that actually produce citations, made 1.1% of the requests. Slackbot fetched llms.txt files more often than PerplexityBot did. And zero AI bots requested a file that did not exist, which means publishing one puts you on no list and not publishing removes you from none. Ahrefs sells SEO software, and its own caveat is that a fetch is not a read, so every figure there is a ceiling.

Google's position is shorter. In its guidance on generative AI features it states that you do not need to create machine readable files, AI text files, markup or Markdown to appear in Google Search, and that doing so will neither harm nor help your visibility, because Google Search ignores them.

So the file is not a reason to choose a platform, and its presence is not an achievement. If your builder generates one anyway, do one thing: open it and confirm it contains plain links and nothing instruction-shaped. A research crawler in Ahrefs's dataset identifies itself as a prompt-injection survey, which tells you somebody is systematically probing these files precisely because agents are built to trust them.

What is the real cost difference over five years?

Not the number you are picturing, because the comparison people make is wrong.

The builder comparison is subscription plus your own time. The custom comparison is build plus maintenance plus somebody available when a form stops working. Both have an ongoing number and neither is free. What website maintenance actually covers is the line item that gets ignored on both sides of this decision.

There is no published benchmark for either, so be careful with any range you are shown. Every "a site like this runs between this and that" figure in circulation traces to agency pricing pages quoting other agency pricing pages, with no survey, no sample and no field date behind it. Compare two real quotes for the same page count instead.

The variable that changes the math is churn. If your site changes weekly, builder plus you is efficient. If your site is static for years and the risk is that it silently breaks, custom plus a maintenance arrangement is calmer.

And in both cases the thing that determines whether the site earns anything is not the platform. It is whether a visitor knows what to do next. A builder site with a clear ask outperforms a custom site with a vague one, every time. Writing a call to action people actually act on is platform independent and it moves more revenue than the platform choice does.

What to do this week

Count your pages. Not the ones you have, the ones you need: every service, every city, every audience you sell to separately. Under fifteen, stop reading and stay on a builder.

Run the five step arithmetic above with your own numbers, especially step three, because maintenance load is what people underestimate.

Then list the systems your website has to talk to. Booking, CRM, POS, email tool, ads account. If the list is empty, a builder covers you. If it has two or more entries with real data moving between them, get someone to look at it before you commit.

Then find out what you own right now. Registrar, host, files, analytics. Do this before any migration conversation starts.

Last, be honest about who edits the site. If the answer is nobody, a custom build will go stale exactly as fast as a builder would, and you should plan for maintenance either way.

Questions about which one fits you?

Email me at eric@seod.com with the platform you are on now, roughly how many pages you have, and whether anything connects to your site. I will tell you plainly whether switching would change anything for you, including when the answer is no. I have talked more people out of migrations than into them.

More on the tradeoffs in the web design and branding library, including when a redesign is the wrong answer entirely.