WordPress vs Webflow vs Shopify vs static: choosing by what it costs you in year three

Platform comparisons are usually written as feature lists, which is why they don't help. Every platform on this list can produce a good-looking website. The differences that matter show up later — in who can change it, what it costs to run, what breaks, and what it costs to leave.

We've built and maintained sites on all four. This is how we choose, and where each one stops being the right answer.

Answer the binding question first

Most platform debates are decided by one constraint that outranks everything else. Find yours and the argument is over.

That's the whole framework. If you sell physical products, the store platform wins and everything else is a workaround you'll maintain forever. If you publish constantly, the editorial platform wins. If a non-technical team needs to move layouts around rather than just edit words, the visual builder wins. If it's marketing pages that must be fast and cheap to run, static wins.

The mistake is starting from "which is best" instead of "which constraint actually binds us."

How they compare where it counts

Read that grid by row rather than by column. No platform wins everywhere and none is close to worst everywhere, which is why the feature-list comparisons feel unsatisfying — they're all true and none is decisive.

Two rows deserve attention because nobody weighs them at the start.

Ongoing maintenance load. WordPress is self-hosted software with a plugin ecosystem, which means somebody has to apply updates, watch for vulnerabilities, and occasionally fix what an update broke. That's a real, recurring cost in money or attention. The hosted platforms and a static build shift that burden elsewhere — to the vendor, or to nowhere, because there's nothing running to exploit.

Cost to leave. Scored the right way round in the grid: strong means easy to leave. WordPress content is portable and the export is genuinely useful. A static site is just files you already own. Webflow and Shopify export something, but the design system, the CMS structure, the apps and the integrations are platform-specific, and rebuilding them elsewhere is a project rather than an import. That's not a criticism — it's the trade you make for the convenience — but it should be a conscious trade.

The four, honestly

WordPress

Right when: you publish a lot, you have hundreds of pages, you need editorial workflow, or you want maximum portability. Still the strongest choice for content-heavy sites.

Wrong when: nobody will own maintenance. An unmaintained WordPress site is not a static site that quietly keeps working; it's an unpatched server with a public login page.

What people underestimate: plugin sprawl. Every plugin is code from a stranger with permission to run anything, and the twelfth one is where sites get slow, fragile and insecure. The best WordPress builds we've seen have fewer than ten and a reason for each.

What people overestimate: the difficulty. Modern WordPress with a well-built theme is pleasant for editors, and the block editor closed most of the gap that made agencies flee to other platforms.

Webflow

Right when: a marketing team needs to build and change pages themselves, with real design control, without touching code — and you're willing to be a tenant.

Wrong when: you need complex commerce, very large content sets, or unusual back-end logic. Also wrong if you're allergic to per-seat pricing that scales with your team.

What people underestimate: how good the handover is. This is Webflow's real product — a marketing person genuinely can rebuild a section on a Tuesday without a ticket, which changes how much a company gets out of its website.

What people overestimate: the ceiling. It's higher than developers assume and lower than salespeople imply. When a project needs something Webflow won't do, the workarounds get expensive quickly.

Shopify

Right when: you sell physical products. Nearly full stop. Payments, tax, inventory, shipping, fraud, returns and checkout are solved by people who do nothing else, and checkout in particular is not something a custom build should be attempting.

Wrong when: commerce is a small side of a content business. Running your whole site on a store platform because you sell three things is the tail wagging the dog.

What people underestimate: app creep. Each app is a subscription and a performance cost, and a store with fifteen of them is both expensive and slow. The tidiest stores we work on solve things in the theme rather than by installing another app.

What people overestimate: theme limits. A well-built custom theme does far more than merchants expect — we built a scroll-driven 3D product view for a jewellery client inside a normal Shopify theme, at 95-plus Lighthouse.

Static (Astro, Eleventy, or a hand-built site)

Right when: the site is mostly marketing pages, speed and reliability matter, and content changes are occasional or can be handled through a headless CMS.

Wrong when: non-technical people need to create new page types on demand and there's no CMS wired in. "Static" without an editing story is a site that ossifies the day the developer leaves.

What people underestimate: the operational calm. There is no server to patch, no plugin to update, no login page to attack. Our own site is static, and the maintenance load is close to zero.

What people overestimate: how hard it is. With a headless CMS attached, editors get a clean interface and the site stays a set of files. The pattern is well-trodden now — you can even keep WordPress as the editor and serve a static front end.

What actually changes at year three

Year one, every platform looks fine. The differences compound later.

The row that surprises people is "who adds a new page type." Everyday publishing is easy everywhere. What differs is who can create something structurally new — a new template, a new content type, a new section pattern. On WordPress and static that's a developer. On Webflow it's often the marketer, and that single difference determines how fast a company can respond to its own market.

Total cost of ownership, without the spreadsheet theatre

Real cost is the licence plus the labour plus the risk, and labour dominates. Some honest guidance:

• Every platform has a recurring cost. Free ones cost developer time instead of subscription fees. There is no zero.
• The expensive line is always people. Whoever updates, fixes, publishes and measures costs more annually than any licence.
• Apps and plugins are the silent multiplier. Fifteen Shopify apps or thirty WordPress plugins can quietly exceed the build cost within two years, and both slow the site.
• Migration is the cost nobody budgets. Assume you'll change platform at some point in a decade. What does that cost from where you're standing?

If you want a real number for a specific scope rather than these generalities, the cost calculator prices it out.

Migration: what moves, and what quietly doesn't

Every platform advertises an importer. What they import is the easy half.

The third column is the project. Nobody quotes the third column when they're selling you a migration, and it is reliably where the time goes.

Three specific migration traps worth knowing about before you commit:

URLs. If the new platform structures URLs differently — and it will — every existing address needs a one-to-one redirect. Miss this and you lose rankings you spent years earning. This is the single most common way a migration destroys value, and it's entirely avoidable with an inventory taken before anything changes.

Tracking. Analytics and conversion tracking almost never survive a platform move intact, because the events were wired into the old templates. Budget for rebuilding and re-verifying them, and check the whole chain afterwards rather than assuming the numbers that appear are real.

Content debt. A migration surfaces every thin, duplicate and outdated page you've been ignoring. This is genuinely an opportunity — it's the cheapest moment you will ever have to delete things — but it's work, and it needs a decision-maker with the authority to say "that page goes."

Plan a migration as three phases: inventory, rebuild, redirect-and-verify. The middle phase is what people imagine a migration is. The first and third are what determine whether it worked.

Where headless fits

"Headless" means separating where content is edited from where it's displayed: the CMS becomes an API, and the front end is built independently.

It's worth it when you're publishing to more than one surface (site plus app plus screens), when your front end needs performance or interactivity a monolithic platform makes hard, or when you want editors to keep a familiar tool while the public site becomes something faster. Keeping WordPress as the editing environment and serving a static front end is a well-established version of this, and it lets a team keep every editorial habit while shedding the runtime.

It isn't worth it when you have one website, a small team, and no unusual performance requirement. Headless splits one system into two, and two systems need more maintenance than one. The preview experience is usually worse, the build pipeline is a new thing that can break, and "who owns the front end" becomes a real staffing question.

The honest test: can you name the second surface? If the answer is "we might have an app someday," you're paying architecture costs now for an option you may never exercise. If the answer is "our sales team's tablets and the in-store screens," headless is doing genuine work.

Deciding as a team without a six-week debate

Platform decisions stall because they get argued on preference. A structure that resolves them quickly:

1. Write down who touches the site. Not roles — names. Who publishes a blog post, who adds a landing page, who changes a price, who fixes it at 11pm. The right platform is largely determined by that list.
2. Write down what has to be true in three years. Selling online? Publishing weekly? Ten languages? A platform that can't reach that is disqualified regardless of how nice it is today.
3. Set the maintenance owner before choosing. If nobody will own updates, eliminate anything self-hosted immediately. This one line removes most bad outcomes.
4. Price the exit. For each finalist, ask what leaving costs. Not to plan on leaving — to know what you're accepting.
5. Decide, write down why, and stop. Record the constraint that decided it. In two years somebody will ask, and "we chose Webflow because marketing needs to change layouts without a developer" is a much better answer than a re-litigated debate.

That's usually a single ninety-minute meeting rather than a discovery phase, and it produces a decision the team can actually defend later.

The wrong reasons to choose

We hear these constantly and they're all bad inputs:

• "Our developer prefers it." Relevant only if that developer is committed for years. Otherwise you're optimising for the wrong person's comfort.
• "It's better for SEO." No platform is inherently better for SEO. Content, structure, internal linking and speed decide it, and all four can do those well or badly.
• "It's free." Software licences are the smallest line in the budget.
• "Everyone in our industry uses X." Sometimes a real signal about integrations. Usually just what one local agency sells.
• "We need a rebuild." Often you don't — the test for that is narrower than people assume. "We want to future-proof." Nothing is future-proof. Choose for a realistic horizon and keep your exit cheap.
• "AI can just build it." AI assistance changes how fast you can build on any of these; it doesn't change which one fits your constraint.

Signals it's genuinely time to switch

Switching costs more than people expect and fixes less than they hope, so it's worth being strict about what counts as a reason.

Good reasons to move:

• The platform structurally can't do the thing your business now needs. You've started selling and you're on a platform with no real commerce; you've gone multilingual and there's no sane way to do it. Capability gaps that workarounds can't close are the clearest case.
• The maintenance burden exceeds what you can staff. A self-hosted site nobody patches isn't a platform choice any more, it's an incident waiting for a date.
• The people who need to change it can't. If every copy tweak is a support ticket and a three-day wait, the platform is costing you more than its licence in lost responsiveness.
• Costs have inverted. Fifteen app subscriptions and per-seat fees that now exceed what a custom build would have cost. Run the arithmetic annually; it creeps.

Bad reasons to move, all of which we've been asked to act on:

• The site looks dated. That's a design project. You can redesign on your current platform for a fraction of a migration.
• It's slow. Usually images, scripts and a bloated theme rather than the platform. Diagnose before you emigrate — most speed problems follow you.
• A new developer prefers something else. Sometimes legitimate, often a preference dressed as a requirement. Ask what specifically cannot be done where you are.
• You read that a platform is better for SEO. It isn't. See above.
• Something broke once. Fix the thing. Every platform breaks.

The test we apply: name the specific capability you need that your current platform cannot provide, and confirm the new one provides it. If you can't complete that sentence, you're describing dissatisfaction rather than a requirement — and a migration will convert that dissatisfaction into a large invoice and a new set of frustrations, usually within about a year.

There's a middle path that's frequently the right answer and rarely proposed, because it's less lucrative to sell: keep the platform, rebuild the front end. New design, new content structure, same CMS and same URLs. You get most of the benefit of a rebuild without the migration risk, and the work is measured in weeks rather than quarters.

Our defaults

Since a comparison with no recommendation is a cop-out:

• Selling physical products → Shopify, with a custom theme rather than a pile of apps.
• Content-heavy, publishes often → WordPress, kept lean, with maintenance owned by someone specific.
• Marketing site a non-technical team must own → Webflow.
• Marketing site where speed and calm matter more than in-house layout editing → static, with a headless CMS if anyone but a developer will touch it.
• Genuinely undecided → WordPress or Webflow, chosen on who edits it. Both are recoverable decisions.

That last point is the real advice. Choose the platform whose exit you can afford, because you will be wrong about something, and the cost of being wrong is what you should actually be optimising.

If you're weighing a platform change, tell us what you're on and what's frustrating you — quite often the answer is that the platform is fine and something else is the problem.