Choosing a CMS: builder, WordPress or custom development

The three honest options — and why there are only three

Short answer: there are exactly three, and they are not a ladder from bad to good. They are a scale of how much of the system someone else runs for you, and how much control you hand over in exchange.

A website builder — Wix, Squarespace, Webflow, Tilda and relatives. You rent everything at once: the editor, hosting, updates, certificates, protection. You assemble pages by dragging blocks, and you almost never think about a server.

A ready CMS — WordPress and its colleagues. This is software you install on your own hosting. The core, the theme and the plugins are someone else's code, but they are yours: they sit on your server, the database is yours, you can change anything. The maintenance comes with the keys.

Custom development — a site written for you: a modern framework, a static build, a headless CMS, or a blend. Every line exists because you asked for it. And every line is maintained by somebody.

The point worth reading on for

The difference between the options is not quality. Excellent sites get built on all three, and terrible ones do too. The difference is where the complexity ends up. With a builder, the vendor absorbs it and you pay in rent and boundaries. With WordPress, it lives in plugins and updates, and you pay in attention. With custom, it lives with your team, and you pay upfront and in dependence on a developer.

Let us say the awkward part out loud, even though we are a studio that sells custom work: most small business websites do not need custom development. A brochure site, a portfolio, a landing page, a blog, a small shop — all of these live happily on a builder or on WordPress for a decade. Custom pays off when you have logic that does not exist in a box, or scale at which the box starts fighting you. Without one of those two, paying for custom means buying yourself obligations.

When a builder is genuinely the right call

A builder is the correct decision when the site has to exist quickly, cost predictably, and never need a developer for routine edits. This is not the beginner option. It is an engineering choice with concrete advantages.

What you actually get

• Launch in days rather than months: template, copy, photos, live.
• Hosting, SSL, CDN, backups and security patches are included in the subscription and require nothing from you.
• An editor your marketer uses alone, without emailing an agency and waiting two days.
• One monthly invoice instead of five separate cost lines.
• No midnight messages saying the site is down — a whole company is on call for that.

What that convenience costs

Boundaries. A builder is excellent inside its model and hits a wall outside it. A non-standard calculator, an integration with your inventory system, a members' area with real roles, a filter across dozens of parameters — this is where workarounds start, and rebuilds follow.

Second, a performance ceiling. The platform ships its own general-purpose code on every page and you cannot delete it. Usually that is fine. If you are fighting for tenths of a second, you will feel the ceiling.

Third, getting your things out. Most platforms offer an export, but a partial one: text and images leave, design and logic stay behind. Moving means rebuilding.

Who should pick it today

Budget is tight, the site is simple, you need to start now, and testing an idea matters more than building a fortress. A local service, a studio, a café, a consultant, the first version of a product site. Even a small shop: if you are still finding out whether anyone buys your product at all, a builder answers that question cheaper than anything else. What comes after is a different story — we walked through it in our piece on building an online store from scratch, where you can see the order volume at which a storefront stops being simple.

The honest sign that it is time to leave a builder: for the third month running you keep hearing "the platform can't do that." Not a day earlier.

When WordPress genuinely fits

WordPress fits when you publish a lot, want to keep your code and data, and are willing either to look after the system yourself or to pay someone to do it. It is the middle ground, and it has earned its place.

Strengths nobody has taken away

Content. WordPress grew out of a blog, and editorial work is still its native habitat. Drafts, revisions, scheduled posts, author and editor roles, categories, tags, search — all present out of the box, no plugin required. With several authors and a steady stream of articles, you will feel the difference.

The ecosystem. Almost every ordinary problem has been solved already: forms, SEO, caching, multilingual sites, a shop through WooCommerce, bookings, memberships. You assemble rather than build.

The talent pool. WordPress people are easy to find in any city at any price. That is underrated insurance: if your contractor disappears, someone picks the site up within a week. Try that with a rare framework.

Ownership. The site sits on your hosting. The database is yours, the files are yours, the licence is free. Want a different host? Copy and move. Nobody can double your plan or close your account.

Where it is the best answer

• Content sites and media: a company blog, a magazine, a knowledge base, a directory.
• Corporate sites of 20–200 pages that get edited regularly.
• Mid-sized shops where a standard catalogue and cart are enough.
• Projects where independence from a vendor matters but the custom budget does not exist.
• Sites an in-house marketer will run, not an agency.

If your project is on that list, stop shopping. WordPress will do the job, and paying for custom adds nothing but an invoice.

The real cost of WordPress: plugins, updates, security, speed

Now the honest part that proposals print in small type. WordPress is free as software and not remotely free as a system. This is not an argument against it — it is a budget line to write down in advance.

Plugins are subscriptions and other people's code

A typical working site runs on a dozen or two plugins. Some are paid, and paid annually: a premium theme, forms, an SEO suite, caching, translation, plus shipping and payments if you sell. Every renewal is a line in the budget. Every plugin is code you did not write, have not read and do not control.

Updates are work, not a button

Core, theme and plugins update constantly and independently of one another. Usually it goes smoothly. Occasionally an update breaks the layout or collides with a neighbour, and customers meet a white screen. That is why a grown-up WordPress site needs staging, backups and a person who checks what happened after the update. Without that person, the site simply stops updating — the worst outcome of all.

Security is a function of plugin count

The core itself is developed carefully and holes in it are rare. The overwhelming majority of hacks arrive through outdated plugins and themes, weak passwords and abandoned sites. The logic is plain: the more third-party code you carry and the longer it goes untouched, the wider the attack surface. Manageable? Completely. Automatic? Never.

Speed is a matter of discipline

WordPress can be very fast. But by default it builds each page on the fly, loads the styles and scripts of every plugin, and often runs under a visual builder that adds its own weight. Hence the recipe: a light theme, few plugins, caching, decent hosting, compressed images. Follow it and your numbers will be excellent. Skip it and you get "why is a simple page this slow?"

How to count it honestly

Add up: the build, annual plugin licences, hosting, maintenance (updates, backups, monitoring) and a small reserve for "something broke." The total lands surprisingly close to a builder subscription — except this one buys you freedom and ownership. That is the real trade.

When custom, static or headless is worth it

Custom development pays off in four cases: you have unique logic, you are fighting for performance, you have unusual security requirements, or you have outgrown the box. If none of those describe you, keep your money.

Unique logic

The most common honest reason. The site stopped being a brochure and became a tool: pricing calculated by your rules, an account area with real roles, sync with your warehouse and accounting, an ordering process that resembles no cart template on earth. The plugin either does not exist, or it exists and does 70% of what you need — and the remaining 30% eats more effort than a proper build would have. When a site turns into a product it changes nature; we covered that separately in our guide to building a web application and SaaS.

Performance as money

When traffic is large and conversion is sensitive to speed, tenths of a second stop being an aesthetic concern. A static build or a headless approach raises a ceiling the box cannot: the page comes off a CDN almost instantly, there is no surplus code on the client, no database in the request path.

Security and requirements

There is nothing to break into on a static site: no admin panel, no database, no executable code on the server. For projects where a leak is expensive or an external audit is coming, that carries weight. Custom also lets you implement exactly the access and storage rules you are held to, rather than the ones a plugin author imagined.

Scale and no lock-in

At a large volume of pages, languages and integrations, the box starts dictating terms. Custom removes the ceiling: your data model, your API, your deploy. The code belongs to you, the repository is yours, the contractor is replaceable.

What custom actually costs

More upfront — obviously. Slower — also true. But that is not the main thing: custom needs someone to maintain it. Dependencies age, language versions ship, requirements move. If you are not ready for an ongoing relationship with a developer, a custom site turns into a beautiful monument nobody dares touch by year three. That is the hidden price nobody warns you about.

Three-year cost of ownership, not the launch price

The classic mistake is comparing launch prices. A site lives for years, and the total decides. Count on a three-year horizon: that is long enough for a platform to show its character and for a site to age.

What the total is made of

1. Launch — design, build, copy, content migration.
2. Platform — a builder subscription, or hosting plus plugin licences.
3. Maintenance — updates, backups, monitoring, small repairs.
4. Changes — new pages, sections, campaigns, integrations. This line is almost always bigger than people expect.
5. Risk — downtime, a hack, lost rankings, a forced migration.

How the three behave over time

Builder: cheap launch, then a flat monthly payment. The curve is nearly horizontal and predictable. It spikes in exactly one situation — when you needed the impossible and the workarounds began.

WordPress: a middling launch, then two permanent lines — licences and maintenance. The curve is gentle but never zero, and it is vengeful: save on maintenance and you pay in recovery.

Custom: an expensive launch, then cheap to run (static hosting costs pennies), but every new feature is developer time. The curve is a staircase: quiet, quiet, then a sprint.

The arithmetic worth doing yourself

Take a sheet of paper and write your own numbers. Builder subscription × 36. WordPress hosting × 36, plus plugin renewals × 3, plus a maintenance retainer × 36. Custom: the build estimate, plus hosting × 36, plus an honest guess at changes. Do not copy someone else's table — what matters is your rates and your appetite for change.

Almost always the same thing turns up: over three years the gap between the options is far narrower than it looks on day one. A builder is not as cheap as month one suggests. Custom is not as frightening as the estimate suggests. And what decides in the end is not price, but how many times across those three years you hear the words "the platform can't do that."

Speed and SEO: what actually decides

Answer first: search rewards the implementation, not the platform. Sites on all three options rank well, and sites on all three rank badly. A search engine does not care what assembled your HTML.

What genuinely matters

• A sensible URL structure and no duplicates.
• Unique titles and descriptions you wrote, not ones generated from a template name.
• Loading speed and layout that does not jump while it loads.
• Correct redirects, a sitemap, structured data, and hreflang if you run multiple languages.
• Content that answers the question better than the neighbours in the results.

Not one of those is a privilege of custom code. The only difference is how easily each option lets you get there.

Where each option stands

Builders hand you a decent baseline for free: responsive layout, image compression, a certificate, reasonable HTML. The ceiling is the platform code you cannot remove and the limited access to fine controls. For a local business or a small site, you will never touch that ceiling.

WordPress can do everything: SEO plugins give full control over metadata, redirects and structured data. But speed has to be earned — with a light theme, caching and plugin discipline. A heavy visual builder on top of WordPress destroys your numbers faster than anything else on this page.

Static and headless offer the best ceiling: prebuilt HTML from a CDN, nothing surplus on the client, total authority over every tag. But a ceiling is a possibility, not a result — a badly built custom site crawls just as well as a plugin zoo. You can see real builds and how they behave in our studio portfolio.

The takeaway without illusions

If someone promises you rankings "because it is custom," that is a sales pitch, not expertise. You choose a platform by the job. Traffic comes from structure, content and care.

Security and updates: whose job is this

The real security question is not "which is safer." It is "who is doing this on a Thursday evening." The answer is what separates the three options.

Builder: somebody else's job — and that is a feature

The platform patches vulnerabilities, renews certificates, holds off bots and takes backups. You physically cannot forget to update. For a business with no technical staff this may be the builder's single greatest advantage, and it is rarely given credit. The flip side: you depend entirely on somebody else's diligence and somebody else's rules.

WordPress: your job — and it is manageable

This one is fair: you own it, so you answer for it. The working minimum looks like this:

• fewer plugins means less attack surface — delete what you do not use;
• security auto-updates on, major updates through staging;
• backups stored off the server and, crucially, a restore you have actually tested;
• two-factor authentication on the admin panel and no user called admin;
• only plugins updated recently and maintained by a living author.

Do all that and the site stands for years. Skip it and it is a matter of time.

Custom and static: almost no surface

A static site has no admin panel and no database. There is nothing to break into — only the infrastructure remains. It is the calmest of the three. But "nothing to break" does not mean "nothing to do": dependencies age, a runtime version leaves support, forms and APIs carry their own risks. The work simply moves from an admin panel to a repository.

The practical test

Ask yourself who will actually handle updates a year from now, once the enthusiasm has worn off. If there is no answer, choose the option where the vendor handles it. That is not weakness. That is sobriety.

Who will edit the content, and how

The most underrated criterion in the whole decision. Not "what is it built on" but "can Maria in marketing change a price on a Thursday without messaging anyone." If she cannot, the site will slowly die, however beautiful the code.

Builder: the clear winner here

Visual editor, drag the block, see it instantly. A non-technical person is comfortable within an hour and independent forever after. The one risk is that the same person can pull the design apart. That is solved with locked block templates and permissions.

WordPress: good, unless you turn it into a monster

The WordPress admin is clear and familiar to millions. The block editor lets people assemble pages without a developer. Trouble starts when a heavy page builder goes on top, with a hundred settings inside every block: officially anyone can edit, in practice only the person who built it. The good practice is to define your content fields in advance, so the editor fills in meaning rather than nudging margins.

Custom: depends entirely on what you ordered

Here is the honest warning. A custom site has no admin panel by itself. If one was not written into the estimate, every text change becomes a developer ticket, a wait and an invoice. Six months later the company stops updating the site, because "it is easier not to touch it."

That is why serious custom work always has a second half: a headless CMS or a purpose-built admin where content is edited through clear fields. It costs separate money, and that money goes in the budget from the start. Ask your contractor directly: "who changes this sentence a year from now, and how?" The quality of the answer tells you a great deal.

Lock-in, ownership and moving between options

Lock-in is not about villainous vendors. It is about what leaving will cost. Price the exit before you enter, not after.

What must be yours under any option

• The domain — registered to your company, with registrar access in your hands. Not your contractor's.
• The content — copy and original images stored somewhere other than the site.
• The analytics — properties created under your own account.
• Code and access — if it is custom, the repository and server are in your name, and the contract says who owns the source.

That is the baseline. Without it you are not renting a platform, you are renting your own business.

The real degree of lock-in

Builder — maximum. An export usually exists, but text and images are what leave; design, blocks, forms and logic stay on the platform. Moving equals rebuilding.

WordPress — minimal on code and data: the database and files are yours and copy wholesale. The lock-in hides elsewhere — in the plugins. A site built on one specific page builder will carry its content out but not its layout.

Custom — no vendor lock-in, but a dependence on competence. The code is yours, yet handing it to a new team costs more the more exotic the stack and the thinner the documentation.

How migrations actually go

The direction is nearly always the same: builder → WordPress, WordPress → headless or custom. The reverse happens too, and there is no shame in it: if a site has accumulated code nobody uses, moving down to a box is a health measure.

Whatever you choose, the technique is identical: keep the page addresses or set up page-level redirects, carry the metadata across, do not lose the images, verify forms and analytics goals, and only then point the domain. Traffic is not lost by changing platform. It is lost by losing URLs.

How to decide: a short framework by scenario

Drop the question "which is best." Ask four other questions and the answer assembles itself.

1. Do you have logic that does not exist in a box? If not — take the box.
2. Who edits the content? If it is not you, and not slowly, you need a real editor.
3. Who owns updates? If nobody does, you need a vendor.
4. What happens in three years? If the site doubles, price the ceiling now.

Scenarios and the honest answer

Local business, under 15 pages, no technical staff. A builder. Full stop. Custom here is money set on fire.

A campaign landing page needed yesterday. A builder. Speed to launch beats everything else.

A company with a blog, 50+ pages, an in-house marketer. WordPress with a light theme and a short plugin list.

A shop with a standard catalogue and ordinary shipping. WordPress plus WooCommerce, or a ready e-commerce platform. Custom only when the ordering logic is genuinely your own.

Many languages, many pages, betting on organic. A fork in the road: WordPress with honest multilingual handling, or static/headless. Volume and speed requirements decide.

An account area, calculations, integration with your accounting system. Custom. Here the box costs more than the build.

The site is the face of the product, the design is unique, speed is critical. Static or headless.

You do not know whether the idea will fly. A builder for six months. Prove the demand, then build.

If your case sits on a boundary, that is normal — the boundaries are blurry. We tell clients plainly when a box solves their problem, and take on development work when it is genuinely justified.

Your decision checklist

Work through this before you sign anything. Each item is a question you should be able to answer concretely, not by feel.

The job

• What must the site do in a year — not how should it look at launch?
• Is there a single feature that definitely does not exist in ready solutions? Say it out loud.
• How many pages and languages will exist in three years?

The people

• Who exactly edits copy and prices? Can they do it today?
• Who owns updates and backups? A name, not "the agency."
• What happens if that person leaves?

The money

• Have you added up 36 months, rather than comparing launch prices?
• Are plugin licences, hosting, maintenance and future changes in the total?
• Is there a reserve for changes you cannot see yet?

The risks

• Are the domain and analytics registered to your company?
• Does the contract state who owns the code and the content?
• Do backups exist, and have you ever tested restoring from one?
• What would leaving this platform cost in two years?

The honesty test

• Did the contractor explain why this option — or just propose what they happen to build?
• Have you heard the words "you don't need that" even once? If not, be careful.

If you can answer most of these, you have already chosen — you just have to admit it. If you cannot, start with the answers rather than the platform. Want a second opinion on a specific project? Get in touch — we will say so plainly if a builder solves your problem, and explain why.

FAQ