Count the cost of ownership, not the launch price
The launch price is just the entry fee. After that come monthly platform fees, editing costs, integration expenses, and - if the site can't keep up - the cost of rebuilding from scratch. That last item is usually what eats through all the initial savings.
Take a 24-36 month horizon and add up four numbers: the upfront fee, monthly costs, how many edits you'll actually order per year, and what happens if you need a calculator or a client portal in twelve months. Once you do that, the comparison stops being a matter of opinion and becomes straightforward arithmetic.
What goes into the cost of a builder
A plan that lets you connect your own domain, someone to build the page, a design or template customisation, and connecting the form to email and a CRM. Third-party services are a separate line item: some integrations run through connectors that carry their own subscriptions.
Editing after launch is something you can do yourself - that's the main economic argument for a builder. Changing text, prices, images, or the order of blocks doesn't require a contractor. If you'll be making small changes frequently, those savings add up more than you'd expect.
The limit appears when you need a non-standard block. At that point, custom code gets embedded in the page, and you're paying a developer - but working inside someone else's platform. That typically costs more per unit of work and is more fragile to maintain.
What goes into the cost of custom code
A design mockup, markup, front-end build (we use React), server-side form handling, analytics setup, hosting, and a domain. Development is a one-time cost; after that, ongoing expenses are just hosting, the domain, and edits as needed.
Hosting a static landing page is cheap - often less than a builder subscription. But you probably won't be able to update text yourself without a contractor, unless a CMS or admin panel is built into the scope. That's a separate cost, and it's worth discussing in the brief rather than six months later.
The second advantage of custom code shows up on the second and third page. A finished template can be copied for a new audience for almost nothing: swap the text and images, the structure stays. On a builder, every copy is manual work again.
When a builder is genuinely the right call - and custom code would be overkill
There are situations where commissioning custom development makes no sense, and we say so directly.
If your situation fits this list, start with a builder. Validate demand, collect your first leads, and then decide whether custom code is worth it.
- You're testing a hypothesis: it's unclear whether there's real demand or whether the offer will work at all.
- One product, one call-to-action, a lead form - no logic or calculations on the page.
- Integrations are limited to email, a messaging app, and a basic CRM.
- Traffic is modest, there's no paid advertising, or the budget is minimal.
- You want to update the copy yourself, every week, without emailing a contractor.
Where the builder's economics break down
The first trigger is custom mechanics. A pricing calculator, a product configurator, parameter-based filtering, a client portal, or phone-number login. On a platform, these get built with workarounds, and each new workaround costs more than the last.
The second is paid traffic. You pay per click, and some visitors leave before the page finishes loading. You can check this for free: run the URL through PageSpeed Insights, look at the mobile tab, and also open the page on your own phone on a slow connection. If the first screen takes a few seconds to appear, the difference between subscription tiers is no longer the main cost.
The third is integrations with your internal systems: inventory, accounting software, payment processing, end-to-end analytics. Each chain through a third-party connector adds a subscription and a potential point of failure. When you have three or four of those chains, monthly costs catch up with one-time development faster than you'd expect.
The fourth is a design that needs to be reproduced precisely. A builder often gets you 'close to the mockup,' and that's a normal tradeoff for speed. If you have brand guidelines and care about the details, fighting the platform ends up costing more than just building it properly.
What to ask a contractor before paying
These questions take one evening and can save months.
One check for an honest quote: ask for it as a breakdown of blocks and tasks. If you receive a single line with a total - that's not a quote, it's a number, and there's nothing to meaningfully discuss.
- Where the code will be hosted, who owns it after payment, and whether you can take the repository.
- What can I change myself without you - just text, or blocks too?
- Where do leads go, and are they duplicated to email if the CRM is unavailable?
- What does an hour of support cost after launch, and how are tasks submitted?
- What would need to be rebuilt if a calculator or on-site payment is needed in a year?
- Show me a live example of your work on a phone - not a screenshot, a link.
A builder wins for hypothesis testing and frequent small edits; custom code wins when there's non-standard logic, paid traffic, and integrations with your internal systems. Count the costs over two or three years, not just the first invoice - and get any quote as an itemised list of blocks and tasks, not a single number.
Frequently asked
Can you move a site from a builder to custom code later?
You can, but it's not a migration - it's a rebuild. The design and content carry over; everything else gets built from scratch. You keep your domain, analytics tags, and historical data, but nothing you built inside the platform. So if you already know you'll need a calculator or a client portal in six months, it's cheaper not to start with a builder.
Do sites built on builders really rank worse in search?
The platform itself isn't the issue. Rankings come down to page structure, copy, headings, and mobile load speed. A builder can technically satisfy most baseline requirements; where it gets harder is first-screen load time on content-heavy pages. Check it with PageSpeed Insights - that's a more useful test than debating which engine is running underneath.
Which is cheaper to maintain?
If your edits are text, prices, and photos, a builder is cheaper - you handle those yourself. If your edits involve new blocks, integrations, and logic, custom code is cheaper: the work happens inside your own project, without working around platform constraints. Count how many of each type of edit you'll need, and the answer becomes obvious.
I already have a landing page on a builder but I'm getting few leads. Should I switch to custom code?
Find the cause first. Check in your analytics how many people reach the form and how many actually start filling it in, and test your mobile load speed. The problem is often the offer, the first screen, or a long form - not the technology. Switching to custom code won't fix that; it'll just shift the expense.