What to build your company website on — five paths, and the cost of leaving each one

The question "which platform is best" comes up in almost every first conversation, and it is the wrong question.

These platforms do not differ in quality. They differ in where their scope ends — and in how much it costs to move out once you reach that edge. The first is written up in every vendor's marketing. The second never is.

This piece lines up five paths in one table, names the point each one stops being enough, and lays out the exit rules we verified with the vendors: what you take with you, and what stays behind.

Five paths in one table

SaaS builders — Webflow, Squarespace, Wix

You pay a subscription, you get a visual editor and hosting included. The site goes up fast, because there is nothing to stand up. You have no access to the code and nothing to maintain — which is an advantage right up to the point where it becomes a problem.

They differ more from each other than the shared category name suggests. Webflow targets designers: control over layout close to writing code, able to handle dynamic content, but it demands understanding how the site works. Squarespace sits at the other end — closed templates, few decisions, a fast result. Wix sits in the middle, with the largest set of ready-made features and the largest set of things you cannot change.

For a company, more important than these differences is what they share: on any of them, you are building on someone else's ground. We come back to this in the section on exit cost, where that trait turns into an actual figure.

WordPress with a visual page builder — Elementor, Divi, Gutenberg

The code and database are yours, you choose your own hosting, and the layout is clicked together in a page builder — the largest pool of freelancers and agencies on the market, and the largest pool of plugins.

One distinction trips people up the most, and the most expensively: WordPress.com is not the same thing as WordPress.org. The first is a subscription service hosted by Automattic, with plan limits attached — and, as with every subscription platform here, its promotional price and its renewal price are two different numbers, so check the second before committing on the strength of the first. The second is software you install on your own hosting, at no cost. When someone says "we'll put this on WordPress," they almost always mean the second — worth asking, because the consequences match the closed builders above.

WordPress with a custom-built theme

Same back end, but the design is built for you rather than picked off the shelf. Editors change the content; a layout change goes back to the vendor. The option that gets the most quotes and the least attention in articles about technology.

Who it suits: a company wanting to look different from the competitor on the same template, while staying inside a system every vendor knows. The catch: a theme built for you is only as good as the team that wrote it, and just as hard for the next vendor to take over without documentation — the same trap as fully custom builds, at a smaller scale.

Headless CMS — Payload, Contentful, Strapi

Content lives apart from presentation and is served through a programming interface. It makes sense when the same content has to land in several places, or when you are building an application anyway — a decision that has its own article.

Inside this path is a second fork: a system on a vendor's subscription (Contentful, Sanity) or on your own server (Payload, Strapi). The first takes maintenance off your hands and leaves content with someone else; the second does the opposite. For regulated industries — finance, healthcare, public procurement — the second is sometimes the only one allowed. Shared limitation: without someone to maintain it, the system stalls at the first change nobody can make in the panel.

Custom-built solution

An application written for your process, where the website is one of its views — chosen when the product is what the software does, not what the site shows.

Who it suits: companies where the website is the entry point to a system — a configurator, calculator, customer portal, order panel. The catch: every off-the-shelf feature elsewhere is a line item here, so this path only makes sense when the gap between your process and the standard one is real.

The point where each path stops being enough

Choosing a platform is worth doing not by what it can do, but by the moment it stops being enough — because that moment almost always arrives sooner than the sales pitch assumes.

A SaaS builder runs out on content complexity. As long as you have a dozen or so subpages and a contact form, everything works. Past roughly a hundred subpages linked by relations — or a second language version — workarounds start: scripts pasted from a forum, fields pretending to be relations, manual copy-pasting. The platform never planned for this, so every further feature is a patch.

WordPress with plugins runs out on performance. No magic number, but in our own implementations the turning point sits around thirty plugins: each adds its own scripts and styles, loaded even where not needed. Past a point, the next feature costs more performance than it is worth — and performance is what Google judges a site on. How to check this on your own site, we cover in our piece on testing.

WordPress with a custom theme runs out on the second channel. It holds up for a long time — until the same content also has to reach an app, a showroom screen, or a partner's catalogue. That is when the monolith gets in the way, because content is fused to presentation.

Headless runs out on the lack of an owner. Not the technology — the fact that nobody maintains it: no in-house developer, no agency on a standing contract, no vendor with a written response time.

A custom-built solution runs out on scope. If what you are building would fit inside an off-the-shelf system, you are paying to build something that already exists, for a fraction of the price.

Being honest about these thresholds: our own observation from our own implementations, not a measured benchmark — but each is something you can check on your own site in about fifteen minutes, by counting subpages, plugins or channels.

The cost of leaving — the one difference no vendor page shows you

This is where the five paths genuinely pull apart. We verified the rules below with the vendors themselves on 11 September 2026.

Wix: you cannot take the site with you

The site itself cannot be exported — it only runs on Wix's own servers, because the whole service is built that way. What you can take out is data: collections and products as CSV files, content for translation (Wix support). Everything you actually see — the layout, the styling, the interactions — stays behind.

Squarespace: an XML file missing half the site

The export covers layout pages, one blog with its posts, text and image blocks, and galleries. It does not cover: the shop and its product blocks, video and audio blocks, additional blogs beyond the first, dropdown menus, drafts, or custom styling and custom CSS. The documentation states outright that content cannot be moved from one Squarespace site to another (Squarespace support).

Webflow: code, yes — but not everything, and not on every plan

Code export — HTML, CSS, JavaScript and assets — is available only on paid Workspace plans, not on site plans. The export does not include CMS content, user accounts or the store; dynamic content has to be pulled out collection by collection, and forms stop working once moved (Webflow help).

WordPress and custom builds: you take everything

The database, the files, the theme, the plugins — these are your things, on your server. Moving house is technical work, but nothing has to be rebuilt from scratch. With a custom build or self-hosted headless, the same applies to the code: the repository goes wherever you want, even to cheaper hosting.

What that means for the bill

Leaving a closed builder is not a migration, it is building a new site — content moves, but the visual layer has to be assembled again from scratch. Take the order of magnitude from the price of a fresh build, not a move: our website cost piece lays out what a build costs across the market, and our calculator will price your case.

Worth saying plainly: a subscription platform's terms and pricing are the vendor's decision, not yours. You find out about a change after the fact, and your ability to react depends on what you can take with you — which is why the cost of leaving is part of the cost of joining, even though no quote shows it that way.

What each path costs, year after year

Build prices are in the quotes; the costs that come back every year usually are not.

SaaS builder. Subscription plus domain, no separate hosting bill. Simple to budget, growing with team size and higher-tier features — and can look different at renewal than at purchase, a pattern across almost every subscription tool we have priced, not just website builders.

WordPress with an off-the-shelf theme and plugins. Hosting plus licences plus care. The least predictable is care itself: billed as a monthly retainer or by the hour, both varying too widely by provider and market for one figure to mean much — plus plugin renewals. One we can price: a popular visual page builder renews annually between €228 and €540 depending on plan (our SaaS pricing survey, captured 26 August 2026).

WordPress with a custom theme. Same hosting and care, fewer licences, but vendor time for every layout change.

Headless and custom-built. Application hosting plus developer time. No licence fees if open source; the whole cost sits in keeping the skills to run it.

Worth taking from this list: none of these paths is "free of fixed costs." They differ in who you pay — a vendor's subscription, a plugin maker, or your own vendor's time.

"Webflow or WordPress" — why that question leads nowhere

Asked that way, the question puts a closed service against open software deployable five different ways. The answer "Webflow" or "WordPress" tells you nothing about what you actually get.

What actually settles it has three parts: who changes the design, how much complexity the content will carry in two years, and what you would take with you if you had to move. Answer those, and the five paths usually narrow to one or two — without comparing features nobody would use.

Check which path you are on

The list below does not ask about preferences, only about requirements you have now, or will have in two years. Every box you tick moves you further along the map of five paths — the more you tick, the sooner the path your gut suggests will run out.

Three companies, three paths — what it looks like in practice

These examples are composites of cases we have seen; they do not describe a single client.

A law firm, six subpages, one person handling content. Needs: look credible, be findable by name and specialism, take enquiries through a form. They would tick maybe one item above. A SaaS builder or WordPress with an off-the-shelf theme — every euro beyond that buys something this firm will never use. A risk worth accepting knowingly: with a builder, they will not take the design with them in three years.

A manufacturer with a catalogue and distributors. Needs: four hundred products with specifications, one price list for partners and another for end customers, the same catalogue as a PDF for reps, an integration with the warehouse. They would tick five or six items. A custom theme stops being enough the moment a PDF and an integration show up — the content has to be available outside the website. Textbook case for headless, not because it is more modern, only because the catalogue stopped being part of the website.

A service company with a client portal. Needs: a sales-facing site, and behind a login, order history, documents and invoices. They would tick three or four items, including logged-in content. Splitting it into two things: a simple site for what is fast and cheap to maintain, and a separate application for the portal. The most common mistake here is making one do the job of the other — a portal bolted onto a site with plugins, or a site drawn inside an application nobody wants to edit content in.

Moving between paths — what it actually takes

Changing platform is not one task, it is four — and quotes usually show only the first.

Content moves most easily: export, field mapping, import — hours of work at a few dozen subpages, days and scripts at a few thousand.

Design moves worse, the more closed the previous platform was. WordPress to WordPress, the theme travels with the content; from a SaaS builder, it does not travel at all.

URLs are what migrations trip over most often. A changed URL needs a redirect issued before the old one stops working — covering every URL, not just the ones in the menu. We cover this more broadly in our piece on testing a site.

Features are everything else: forms, integrations, newsletter, shop. Ready-made on the builder and on WordPress; after the move, rebuilt or replaced. The largest line item, and the one that can blow the migration budget.

Practical takeaway: a move is cheaper when the previous platform hands back what is yours — exactly what the previous section described. That is why the cost of leaving is worth costing at the point of joining, not leaving.

What choosing a platform does not settle

It does not settle whether anyone will find your site, understand the offer, or leave their contact details.

On every one of these five paths you can build a site that sells, and a site nobody reads — the difference is in the content, and in whether anyone thought through why the site exists. The five decisions that come before the choice of technology, we lay out in our guide to website strategy.

Four questions before you decide

1. How many subpages, and what relationships between them, will we need in two years? This question rules out builders faster than any feature comparison.
2. Who will change the design, and who the content — and how fast does that need to happen? The answer points to a path almost by itself.
3. What exactly would we take with us if we changed our minds in three years? A question to put to your vendor in writing, with file names, not a reassurance.
4. Who maintains this, and what does it cost per month? A budget line to name before choosing a system, not after the first outage.

Where these numbers come from

• Export rules for Wix, Squarespace and Webflow — the vendors' own help documentation, checked at the source on 11 September 2026.
• The page builder's renewal price — our own SaaS pricing survey, price as published by the vendor and captured 26 August 2026.
• The thresholds at which each path stops being enough — our own observation from our implementations, not a measured benchmark; described that way in the text too.
• WordPress.com plan prices and WordPress technical-care rates — deliberately not quoted: our pricing research covers Poland only, in złoty, and converting at an exchange rate would misstate the local price. The mechanism — a low first-year price, a much higher renewal — is stated in general terms instead.
• Polish market medians for a full rebuild — dropped for the same reason; see website cost for bands in a defensible currency, or price your case in our calculator.
• Webflow's May 2026 pricing change — deliberately absent: the help article returns an access error, so we did not read it and are not citing it.