This decision is usually presented as a technology comparison, which is why it is usually made badly. Agencies recommend what they build in, platform vendors recommend themselves, and the person who has to live with the result for five years is given a feature matrix.
The useful framing is total cost of ownership. Not the build price – the build price is the smallest number in the decision. What matters is what the choice costs you per year afterwards, in licensing, hosting, maintenance, hiring, and in the work you cannot do because the platform will not let you.
The four questions that decide it
Before comparing platforms, answer these. In most cases the answers make the decision, and the platform comparison is just confirmation.
- Who publishes, how often, and how technical are they? A team publishing weekly needs a genuinely good editing experience far more than it needs architectural elegance. A site that changes four times a year does not.
- What does it have to integrate with? CRM, ERP, booking, payments, stock, a customer database. Integration requirements narrow the field faster than anything else, and they are the requirement most often discovered late.
- Who will maintain it in three years? In-house team, this agency, an unknown future supplier? A mainstream stack you can hire for is worth a lot, and it is worth more the less certain you are about the answer.
- Is the website a channel or is it the product? A brochure site and a site that is the primary sales mechanism justify very different investment. Be honest about which you have.
WordPress
Still the default for content-led sites, and still frequently the right answer. What it genuinely gives you is a large hiring pool, an editorial interface non-technical people already know, and an enormous ecosystem for anything standard.
Choose it when editorial volume is high, the team already knows it, hiring needs to be easy, and the requirements sit inside what it does well.
Be careful when the plugin count starts growing. WordPress projects almost never fail because of WordPress; they fail because a marketplace theme was extended with twenty-five plugins, three of which overlap, and updating any of them now carries risk. The difference between a WordPress site that ages well and one that does not is almost entirely whether it was built as a custom theme with structured content models, or assembled from a builder.
The real cost is maintenance discipline: hosting configured properly, updates applied on a schedule and tested, and a plugin policy that someone enforces. Budget for it, or the security and performance decline is not a possibility but a schedule.
Webflow
Strongest where a marketing team needs visual control without a development cycle. The editorial and design autonomy it gives a small team is genuine, and for the right site it removes an entire category of dependency.
Choose it when the site is presentational rather than transactional, the marketing team wants to build pages themselves, and the requirements fit comfortably inside the platform.
Be careful when requirements approach the platform ceiling. Complex data relationships, heavy integrations, custom application logic and large content volumes are where Webflow projects turn into workarounds. The ceiling is real, and hitting it means replatforming, not extending.
The real cost is platform lock-in and per-site fees. Exporting is possible but you do not export the CMS, so a move later is closer to a rebuild than a migration. That is an acceptable trade for the right site and an expensive surprise for the wrong one.
Headless CMS with a custom front end
A content API plus a separately built front end. Genuinely valuable in specific situations, and frequently chosen for the wrong reasons.
Choose it when the same content genuinely feeds more than one destination – a website, an app, in-store screens, a partner API – or when the front end has performance requirements a traditional CMS cannot meet, or when editorial and presentation teams need to release independently.
Be careful when the reason is that it is modern. Headless splits one system into two, adds a build and deployment pipeline, and usually gives editors a worse preview experience than a coupled CMS. Those costs are worth paying for a real reason and not otherwise.
The real cost is operational complexity and a smaller hiring pool. You now maintain a CMS, a front end and the pipeline between them.
Fully custom
Building the application rather than configuring a platform. Higher initial cost, no licence fees, no ceiling.
Choose it when the site is a core commercial asset rather than a channel; when performance or accessibility requirements are strict enough that platform overhead is a problem; when the interaction design is genuinely bespoke; or when the site is really an application that happens to have public pages.
Be careful when the requirement is actually a content site with an unusual layout. That is a design problem, not a platform problem, and building custom to solve it means you have also taken on writing an editing interface – which is a much larger job than it looks, and one that platforms have spent fifteen years refining.
The real cost is that you own everything, including the parts a platform would have given you: the editorial interface, the media handling, the role management, the upgrade path. Custom is right often enough to be a serious option and less often than agencies that prefer building custom will suggest.
Commerce is a different decision
If you are selling, the platform question is dominated by the checkout and the operations behind it, not by the content management.
Hosted commerce platforms are the default for good reasons: the checkout is maintained, tested and compliant by someone else, payment integrations are ready, and the operational tooling for orders and fulfilment exists. The trade-offs are platform fees, limits on checkout customisation below the top tiers, and app sprawl if nobody governs it.
Self-hosted commerce makes sense where the store lives inside a content-heavy site, or where control over data and hosting is a genuine requirement. It is not lower-effort – the effort moves from platform fees to hosting, caching and maintenance.
Custom or headless commerce becomes right when the selling model does not fit a platform: complex B2B pricing hierarchies, configurable products, unusual fulfilment. It is the correct answer less often than it is proposed.
How to actually run the decision
A short, boring process that produces defensible answers.
- Write the requirements as outcomes, not features. "Marketing can publish a case study without a developer" rather than "custom post types".
- Separate must-have from would-like, honestly. Most feature matrices are won on requirements nobody would actually pay for.
- Model five-year cost, not build cost: licences, hosting, maintenance, and the internal time the editorial workflow will consume.
- Ask what a migration away would cost. You are choosing how expensive it will be to change your mind.
- Ask who you can hire. A platform your future team cannot staff is a strategic risk regardless of its merits today.
- Then, and only then, compare platforms against that.
The honest summary
For most business websites – content-led, integrating with two or three systems, published by a marketing team – a well-built CMS site is the right answer, and the quality of the build matters far more than which CMS it is. A carefully structured WordPress site with a custom theme and clean content models will outperform an indifferent custom build on every dimension that matters, including performance and maintainability.
Custom becomes right when the site is a product rather than a publication. Headless becomes right when content genuinely serves multiple destinations. Webflow becomes right when editorial autonomy is worth more than the ceiling costs you.
What should never decide it is which technology the supplier prefers to work in. If a recommendation does not come with the reasoning, the alternatives that were considered, and what the choice will cost you in year three, it is not a recommendation.