Let us start by conceding the strongest version of the other side.
A page builder got your business online in a week for a few hundred dollars. It let a non-technical marketer change a headline at nine on a Friday night without opening a ticket. Those are real wins and anyone who dismisses them has never run a small business.
So this is not an argument that builders are unprofessional, or that custom code is inherently better. It is a narrower and more useful argument:
A page builder converts a one-time build cost into a permanent operating cost — and prices your exit so that the operating cost is hard to escape.
That is a financing decision dressed as a technical one, and almost nobody evaluates it as such.
Separate two things you have merged
Most of the confusion here comes from one conflation. "I want to edit my own content" and "I want to assemble my own layouts" are different requirements with completely different costs.
Editing content — changing text, swapping an image, publishing a post, adding a team member, updating a price — is something every business should be able to do without a developer. We agree with this so strongly that a custom admin panel you edit yourself is a line item on our corporate plan, and a CMS you can edit is in the scope of every website we build.
Assembling layouts — dragging a new three-column section into place, choosing a spacing value, picking a font for one block — is the part that costs you. It is what the builder runtime exists to enable, and it is what produces the compounding problems below.
You can have the first without the second. Almost nobody is offered that choice, because the products that provide the first are bundled with the second by default.
The three-year picture
Price the whole thing, not the build.
| Page builder | Custom build with a CMS | |
|---|---|---|
| Initial build | Low | Higher |
| Licence + premium plugins | Every year, rising | None |
| Performance | Builder runtime + every plugin's assets, on every page | Ships what the page needs |
| Design drift | Accumulates — every editor makes small choices | Constrained by the design system |
| "We cannot fix that" | Common; you do not own the code | Rare; it is your code |
| Cost to leave | Rebuild plus content migration | Hand over the repo |
The row that decides it is the last one, and it is the one nobody quotes.
The only honest measure of lock-in is what it costs to leave. Not whether you are allowed to leave — everyone is allowed. Whether the content you have created over three years exists in a form another system can read, or whether it exists as layout markup entangled with a specific plugin's shortcodes, which is another way of saying it does not exist at all outside that product.
Run the test on your own site right now: ask whoever maintains it what it would take to move to a different platform with the content intact. If the answer includes the phrase "we would basically redo it", you have your number, and you have been paying interest on it.
The compounding costs, specifically
Performance. A builder ships a general-purpose runtime capable of rendering anything you might drag in, plus the CSS and JavaScript of every installed plugin, on every page — including the ones that use none of it. You do not control the composition, which means you cannot fix it. And as we set out in speed is a pricing decision, that is not an abstract complaint: Vodafone's own A/B test showed a 31% better LCP producing 8% more sales.
Design entropy. Give five people the ability to choose spacing and after eighteen months you have eleven different button styles and four heading scales. This is not a discipline failure; it is what happens when a tool exposes a thousand decisions to people whose job is not making them. A design system with tokens removes the decision rather than documenting the right answer.
The plugin dependency chain. Each plugin is a third party with its own release schedule, its own security record and its own incentive to add an upsell. A site with fifteen plugins has fifteen organisations who can break it, and a maintenance window every time one of them updates.
The unfixable bug. At some point you will need something the builder does not do — a specific checkout behaviour, an integration, an accessibility fix inside a component you did not write. The answer will be that it is not possible, or that there is a plugin for it. That sentence, repeated over years, is the actual cost.
What "you own it" should mean
Ownership is the word most abused in this industry, so here is a concrete definition. You own your site if all five of these are true:
- The source code is in your Git organisation, today, not on request.
- The design files are editable, not flat exports.
- The hosting, domain and third-party accounts are in your name, with you holding the credentials.
- There is no licence to renew to keep the site running.
- Another developer could pick it up and continue without contacting the original builder.
We put that in writing because it is the thing clients get wrong most often: you own the code and every account from day one — if we vanished tomorrow, another developer could pick it up. Source code is included on every plan, from the $99 landing page upward.
A builder subscription fails points four and five by design. That is not a flaw in the product; it is the business model.
What we actually ship instead
To be concrete about the alternative, because "custom" is not a spec.
For a corporate site, a component-based build with a CMS your team edits — Nuxt Content or a real admin panel — where the editable surface is content, not layout. Editors change words, images, prices and pages. They cannot change the spacing scale, because they should not have to think about it.
When the content model is genuinely complex, we ship a proper CMS. WAYU Malaysia runs Payload CMS 3 inside the same Next.js application, with 15 collections, locale-prefixed routes for four languages, and role-based access so department coordinators edit only their own department. Built in two weeks.
And the admin panel is a product, not an afterthought. On Knigopoisk the Filament back office runs 48 resources, 68 relation managers and roughly 300 table columns, fully localised into Russian — with a regression test that fails the build if a column ships without a label. That is what taking the editor's experience seriously looks like, and it is the part page-builder marketing claims as its own advantage.
Run the leave test properly
"What would it cost to move?" gets answered with a shrug. Here is the version that produces a number.
Step 1 — try to export one page. Not the site. One content-heavy page. Ask for it as structured data: headings, paragraphs, images, links. If what comes back is a wall of markup containing plugin shortcodes and layout wrappers, your content and your presentation are the same object, and separating them is manual work per page.
Step 2 — count the pages that would need that treatment. Multiply by however long one takes. This is usually the largest single number in the whole exercise and the one nobody budgets for.
Step 3 — list what is not content. Forms and where they deliver. Integrations. Redirects accumulated over years. The checkout. Anything a plugin does that your team now depends on. Each one is a decision: rebuild, replace, or drop.
Step 4 — find who knows how it works. If the answer is a freelancer who stopped replying in 2024, add that to the estimate, because the first week of any migration is archaeology.
Step 5 — check what breaks in search. Every URL that changes is a page whose accumulated history you either carry over with a redirect or throw away. Finkonkurs replaced an entire platform on a domain dating to 2010, and the way that was survivable was a middleware serving the old site's snapshot at its original URLs — all 1,047 pages of it — with targeted 301s for the rest. Without that plan, a relaunch is a traffic event, not a technology one.
Now you have a figure. That figure is what your subscription has actually been buying, and it grows every month you keep paying it.
When a builder is the right answer
Being honest about this is more useful than winning the argument.
Use a builder when: the site is a placeholder while you find out whether the business works; the whole thing is under five pages and will not grow; nobody in the business will ever need a custom behaviour; and the three-year cost of the subscription is genuinely less than a build.
Do not use one when: the site is a primary sales channel; you have a catalogue; you need integrations with systems you run; performance affects revenue; you sell into the EU and accessibility compliance is load-bearing; or the cost of being unable to change something is high.
The tipping point is usually earlier than people expect — typically the first time someone says "the site cannot do that, so we will change the process instead."
The migration question
If you are already on a builder and the three-year table has convinced you, the sensible path is not a dramatic rebuild.
It is: extract the content into a structured form first, while you still can; agree what the actual content model is; then build. The order matters, because most failed migrations fail at the content step, after the new site is already half-built.
Our websites service covers this from $99 with a 3–5 day delivery on a landing page and 7–10 days for a corporate site, with the CMS handover and a walkthrough for your team included. If we look at your site and think a builder is still the right answer for you, we will say so — telling clients the truth about what they need, including when it is less than they asked for, is one of our five commitments.
Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.
Frequently asked questions
Is WordPress itself the problem?
No. WordPress as a content management system with a purpose-built theme is a legitimate choice. The compounding costs described here come from the visual builder layer and the plugin stack that usually accompanies it, not from the CMS underneath.
Will a custom site mean calling a developer for every change?
Only if it was built badly. A correctly built site gives your team full control over content — text, images, pages, prices, posts — and no control over layout mechanics. That boundary is the feature.
What about AI website builders?
Same analysis, with one addition. They produce output faster and they produce output that looks like everyone else's, for reasons we cover in everything looks the same now. The ownership and exit questions are identical: ask where the code lives and what leaving costs.
How much more does a custom build cost?
Less than most people assume, and the comparison should be over three years including subscriptions, plugins and the one project you could not do. Our published entry prices start at $99 precisely so this comparison can be made without a sales call.
Can I keep my existing design?
Usually yes, and it is often the cheapest path — rebuild the same design on a clean foundation, then improve it once you control it. Redesigning and rebuilding at the same time doubles the risk for no structural benefit.
