Headless websites and the cost of engineering vanity

11th April, 2026

Every headless project begins with the same handful of promises. Flexibility. Performance. Security. Future-proofing. Separation of concerns. Content that can go anywhere. It all sounds sensible, modern, inevitable. And, on paper at least, much of it is true.

That is part of what makes the pattern so persistent. Headless is rarely sold as a reckless gamble. It is presented as a more mature way to build. A cleaner architecture. A more strategic foundation. A way to escape the constraints of legacy platforms and monolithic CMSs, and to give teams the freedom to build exactly what they need.

For engineers, that is intoxicating. Of course it is. The chance to pick the stack, define the rendering model, shape the data structures, own the deployment pipeline, and decouple the front end from the back end feels like progress. It feels like control. It feels like replacing compromise with possibility.

But most websites do not fail because they lacked architectural purity. They fail because they are hard to update, slow to evolve, politically constrained, badly governed, and disconnected from the people trying to use them to do actual marketing. Headless does not solve those problems by default. Quite often, it makes them worse.

That’s because the benefits are framed at the wrong level of abstraction. Flexibility for the system is not the same as flexibility for the business. Performance in a greenfield demo is not the same as performance in a real production environment, maintained by a real team, six months after launch. Security through decoupling is not much comfort if the result is a sprawling mess of services, dependencies, build processes, and integration points that nobody fully understands.

And then there is the quiet sleight of hand at the heart of the pitch. The argument is usually not just that headless can deliver these benefits, but that it is the best, or only, serious way to achieve them. That is where the logic falls apart. You do not need a headless architecture to build a fast website. You do not need one to build a secure platform. You do not need one to create flexible templates, structured content, or sane workflows. Those are all achievable within far simpler systems, with far fewer moving parts, and far less opportunity for a team to disappear into a months-long exercise in bespoke platform engineering.

That last part matters, because headless is often justified in the language of capability. We can build anything. We can model content properly. We can create reusable components. We can serve every channel. We can tailor the stack to our exact needs. Maybe. But the ability to build anything is not the same as the need to build everything. And it certainly is not the same as building the right thing.

Most of the time, what is being pitched as strategic flexibility is really just optionality for engineers. The freedom to compose a system from first principles. The freedom to avoid the compromises of an off-the-shelf platform. The freedom to treat the website as a technical product in its own right. There are contexts where that makes sense. Most marketing websites are not one of them — and the pattern your site actually fits is worth understanding before you commit to the architecture.

Because for most organisations, the website is not a software engineering challenge. It is a publishing, positioning, and conversion tool. Its value lies in how quickly it can change, how effectively it can communicate, and how easily the right people can use it. If your architecture improves life for developers while making all of that harder, then it is not more advanced. It is simply less fit for purpose.

That is the trap. Headless sounds like a route to freedom, but too often it just swaps one set of constraints for another, heavier one. The old limitations were visible and unfashionable. The new ones arrive disguised as sophistication.

A marketing website is not an engineering playground

For most businesses, the website is not the product. It is the thing that explains the product, sells the product, supports the product, and helps people discover it. It is where campaigns land, where stories get told, where trust gets built, and where demand gets captured. It is a marketing asset. That should be an obvious statement, but a surprising number of architectural decisions seem designed to forget it.

When teams choose to go headless, they often talk as though they are making a neutral technical improvement. A cleaner stack. Better separation of concerns. More flexibility for the future. But none of those decisions are neutral. They reshape who the website is for, who gets to change it, and how quickly it can respond to the needs of the business.

That matters because marketing websites do not derive their value from architectural elegance. They derive their value from usefulness. Can the team publish quickly? Can they create landing pages without filing tickets? Can they test ideas, adapt messaging, respond to events, launch campaigns, tweak templates, fix mistakes, update metadata, change internal links, and iterate without waiting for a sprint cycle? Can they actually do marketing?

This is where so many headless projects start to drift. The conversation begins with technical principles and ends with a system that works beautifully for the people who built it, but awkwardly for everybody else. Marketers get a component library instead of a website. Editors get a content model instead of a publishing workflow. The business gets a platform that is theoretically more flexible, but practically more rigid.

That is because engineering teams tend to think about flexibility in terms of what the system could support. Marketing teams tend to think about flexibility in terms of what they can do today, without ceremony, without risk, and without opening a Jira ticket. Those are not the same thing. A system that can theoretically render any kind of page is not very flexible if producing one requires developer intervention, new schema definitions, changes to the front-end codebase, and a deployment pipeline that nobody outside the engineering team fully understands.

The more bespoke the architecture becomes, the more the website starts to behave like software that needs operating. And once that happens, marketers stop being owners and become requesters. They can no longer shape the site directly. They submit briefs. They wait their turn. They work around limitations they did not choose and do not control. The website still belongs to the business in principle, but in practice it has been handed over to the engineering team.

That might be a reasonable trade if the website really is a software product. Sometimes it is. If you are building a complex web application, or a genuinely multi-channel platform with serious integration requirements, then specialist tooling and tighter engineering control may be justified. But that is not the normal shape of a marketing website. Most do not need a custom rendering layer, a JavaScript-heavy front end, an API orchestration strategy, and a miniature platform team just to publish pages, manage content, and support campaigns.

Yet that is exactly where many teams end up. They start with the idea that a headless architecture will remove constraints, and discover too late that many of the old constraints were useful. They were guardrails. They were defaults. They were the bits that made the system operable by people who are not engineers. Strip those away, and you do not automatically get freedom. More often, you get dependency.

This is the part that gets missed when people talk about modern web architecture in the abstract. A website is not improved simply because it is more composable, more decoupled, or more technically pure. It is improved when it becomes more effective at doing the job the business needs it to do. For a marketing site, that usually means making publishing easier, iteration faster, and change safer. It means empowering the team responsible for messaging, campaigns, structure, and growth. It means reducing friction, not relocating it into a more fashionable layer of the stack.

That is why the headless conversation is so often misframed. It asks, what would we build if we could build anything? It rarely asks, what kind of system would best serve the people actually trying to use this website every day?

Those are very different questions. The first produces an engineering project. The second produces a marketing platform.

If you forget which of those you are supposed to be building, the architecture will reflect it.

Flexibility, performance and security do not require headless

This is where the case for headless usually sounds strongest. The promises are not absurd. Flexibility matters. Performance matters. Security matters. These are all good goals, and any team responsible for a serious website should care about them. But somewhere along the way, people started talking as though headless were the grown-up route to achieving them, and everything else were a compromise. That simply is not true.

Take flexibility. In headless conversations, this usually means freedom from the constraints of a traditional CMS. You are no longer boxed in by a templating system, tied to a specific rendering model, or forced to work within the assumptions of a monolithic platform. You can define your own data structures, build your own front end, stitch together best-of-breed services, and adapt the stack to whatever the future demands.

That all sounds attractive, until you ask who actually benefits. Because flexibility at the architectural level often comes at the cost of flexibility at the operational level. Engineers may gain the freedom to compose the stack however they like, but marketers, editors, and content teams often lose the ability to make changes quickly and safely. The site becomes more custom, more powerful in theory, and less adaptable in practice. It can do anything, eventually, provided the right people are available to build it.

That is not a very useful kind of flexibility for most businesses.

The same thing happens with performance. Headless projects are often justified on the basis that decoupling the front end from the CMS allows for faster experiences, especially when combined with static generation, edge delivery, or modern JavaScript frameworks. Again, this is not entirely wrong. You can build a fast site this way. But you can also build a catastrophically slow one. And you do not need any of this architecture in order to achieve excellent performance.

Fast websites come from making sensible decisions about payloads, rendering, caching, assets, infrastructure, and complexity. They come from respecting the browser, sending less code, and not turning every page view into an obstacle course of hydration, client-side rendering, third-party scripts, and API round trips. A well-built server-rendered site can be blisteringly fast. So can a static one. So can a hybrid. Headless is not a performance strategy. At best, it is one possible implementation detail.

In fact, the irony is that many headless builds end up slower precisely because the team has mistaken architectural modernity for optimisation. They ship a JavaScript-heavy front end, layer in preview tooling, bolt on personalisation, add client-side search, and slowly recreate all the weight and fragility they thought they were escaping. The result is often a site that demos well in a greenfield prototype and degrades rapidly once real-world requirements start piling up.

Security gets treated in much the same way. The argument here is that separating the CMS from the presentation layer reduces attack surface, makes the public-facing site less vulnerable, and limits the risk associated with traditional all-in-one platforms. There is some truth in that. But the leap from that truth to “therefore we should go headless” is doing a lot of work.

Most of the practical security gains available to a typical organisation have very little to do with whether the site is headless. They come from good patching practices, strong access control, sane hosting, careful plugin and dependency management, managed services, proper governance, and not running neglected or overcomplicated systems. A tightly managed conventional stack can be extremely secure. A badly governed headless stack can be a sprawling mess of APIs, tokens, services, deployments, and third-party dependencies with no clear ownership and plenty of places for things to go wrong.

And then there is scalability, future-proofing, omnichannel delivery, all the other familiar companions in the sales deck. Again, these are not meaningless concepts. Some organisations genuinely do need centralised structured content delivered across multiple products, surfaces, and interfaces. Some do need highly bespoke rendering logic or application-like experiences. Some do need architectural separation because their requirements are genuinely unusual.

But most marketing websites are not in that category. Most are not trying to syndicate content into fridges, watches, digital kiosks and voice assistants. Most are trying to publish pages, tell a story, capture demand, support campaigns, and evolve quickly without breaking everything. The abstract possibility of future reuse is not a sufficient justification for introducing present-day complexity.

That is the quiet trick in so much headless thinking. It takes goals that are reasonable and widely desirable, then smuggles in the assumption that only a more complex, more decoupled, more bespoke architecture can deliver them. But the relationship does not hold. Flexibility, performance and security are outcomes. They are not inherent properties of a fashionable stack. You do not get them by buying into a paradigm. You get them by making disciplined decisions, understanding trade-offs, and choosing an architecture that matches the actual job the site needs to do.

And that is where so many teams go wrong. They do not start with the job to be done. They start with the architecture they would like to have, then work backwards to justify it. The language is strategic, but the logic is often aesthetic. The site should be headless because that feels modern. Because it feels robust. Because it feels like what serious teams build.

But serious teams do not choose complexity to signal seriousness. They choose the simplest architecture that satisfies the real requirements. And for a great many marketing websites, headless fails that test before the project has even begun.

Rebuilding the web platform, badly

One of the least examined costs of going headless is that you stop inheriting a huge amount of capability from the web itself. Browsers are not just dumb containers for your front end. HTML is not just a delivery format. The platform already solves an extraordinary number of problems, quietly, predictably, and at enormous scale. When you move away from that model, you do not eliminate complexity. You volunteer to reimplement it.

That is a bigger commitment than most teams seem to realise.

A conventional website gets a great deal for free. Links behave like links. Forms behave like forms. Pages can be requested, rendered, cached, indexed, navigated, bookmarked, refreshed, opened in a new tab, and consumed by assistive technologies without anybody having to invent bespoke abstractions to make that happen. The browser understands the document. Search engines understand the document. Screen readers understand the document. The whole system is built on decades of interoperable assumptions.

Headless architectures tend to treat much of that as incidental, or at least replaceable. The browser becomes a runtime for an application shell. Rendering becomes a matter of orchestration. Navigation becomes state management. Markup becomes the output of a component system rather than the primary thing being authored and delivered. At that point, the team is no longer just building a website. It is rebuilding large parts of the contract between server, browser, crawler, and user.

Sometimes that is necessary. Most of the time, it is just expensive.

Because once you take responsibility for all of that, you also take responsibility for all the failure modes. Not just whether the page loads, but whether it loads in the right order, with the right semantics, with meaningful source HTML, with accessible interaction patterns, with sane fallback behaviour, with crawlable links, with coherent metadata, with sensible caching, and with something approximating resilience when JavaScript misfires, a network request fails, or some shiny new dependency decides to update itself into chaos.

This is where the theory of headless starts to collide with the reality of implementation. In principle, you can absolutely build a headless site that preserves all the useful characteristics of the web. You can render clean HTML on the server. You can progressively enhance. You can model content sensibly. You can preserve semantics, accessibility, and crawlability. You can design for resilience. You can recreate previews, workflows, redirects, metadata management, and all the fiddly little editorial features people took for granted before the rebuild.

But now read that list again and imagine the average delivery team actually doing all of it, consistently, under time pressure, across months of iteration, changing requirements, staff turnover, and the usual steady drift from clean architecture into practical compromise.

That is the problem. Headless does not just remove constraints. It removes defaults. And good defaults are one of the most undervalued features of the traditional web stack.

When a team says, “we can build that ourselves”, what they often mean is that they can build a version of it. A routing layer that mostly works. A preview workflow that sort of works. A component library with enough flexibility to satisfy immediate requirements. A metadata system. A form solution. A search integration. Some rules for redirects. Some accessibility patterns. Some analytics hooks. Some personalisation logic. Some build process. Some cache invalidation. Some editorial governance. Some answer to what happens when content changes and the whole thing needs to update everywhere.

Each of those things is solvable in isolation. The trouble is that they all interact. And every custom layer introduces new assumptions, new coupling, and new opportunities for the team to break things that used to be boringly reliable.

That is how you end up with sites that look polished on the surface but are quietly falling apart underneath. Internal links that are technically clickable but not properly crawlable. Page transitions that feel slick until the back button behaves oddly. Content previews that are good enough for simple pages but useless for real campaigns. Component systems that make common changes easy and important changes impossible. Accessibility that works in the obvious cases and collapses in edge conditions. Performance that looks excellent in a benchmark and deteriorates once real tracking, consent, search, forms, experimentation, and business logic arrive.

And all of that happens while the team tells itself that it is modernising.

The real issue is not that browsers are magical, or that older CMS-driven architectures are automatically better. It’s that the web platform has accumulated a huge body of conventions, behaviours, and constraints which make ordinary websites work rather well. Many of those constraints are helpful. They are the product of hard-won lessons about interoperability, resilience, discoverability, and usability. Teams that throw them away in pursuit of greater freedom often discover, too late, that they were not escaping limitations. They were discarding infrastructure.

This is one of the reasons headless projects so often compromise SEO, performance, and accessibility without meaning to. Not because anybody set out to make those things worse, but because once the system stops being a document-first website and starts being a custom-rendered product, all the easy assumptions disappear. Every detail has to be chosen deliberately. Every capability has to be protected on purpose. Every omission becomes technical debt.

Most teams are simply not equipped to do that thoroughly. Not because they are lazy or foolish, but because the scope is far broader than they admit at the outset. They are not just building pages. They are reconstructing the behaviour of the web in software, one missing feature at a time.

That is an extraordinary amount of work to take on merely because somebody wanted more flexibility.

Most engineering teams are not good enough to pull this off

To build a headless marketing website well, you do not just need a capable front-end team. You need a team that understands rendering strategies, caching, content modelling, preview workflows, analytics, accessibility, semantic HTML, structured data, metadata, search behaviour, design systems, publishing ergonomics, deployment pipelines, consent tooling, redirects, performance budgets, component governance, and all the quiet operational detail that sits between a page template and a functioning website. You need people who understand not just how to build interfaces, but how the web works.

Very few teams have that breadth, or depth.

Plenty of teams have confidence, though. Enough to believe they can stitch together a modern stack, recreate the missing parts, and iron out the rough edges later. Enough to assume that any problem they have not solved yet is just another ticket, another sprint, another component, another layer of abstraction. That optimism is understandable. It is also how you end up shipping a website that looks impressive in code review and underperforms in every way that matters once real users, real content, and real commercial pressure arrive.

Because headless raises the standard of competence required for basic success. A traditional stack can survive a lot of imperfect decisions because the defaults are doing so much of the work. The CMS handles routing. The templates output pages. The server sends HTML. The browser does browser things. The system may not be elegant, but it is forgiving. Headless is much less forgiving. Once you take ownership of the full experience, every blind spot becomes architectural. Semantic structure is usually the first casualty.

If the team does not deeply understand SEO, they will create crawlability problems they do not notice until visibility starts slipping. If they do not understand accessibility, they will recreate interactions that work for a mouse and fail for everybody else. If they do not understand performance beyond a Lighthouse score, they will optimise the demo and then drown the live site in JavaScript, third-party scripts, hydration overhead, and badly managed assets. If they do not understand editorial workflows, they will build a system that technically publishes content while making day-to-day marketing slower, harder, and more fragile.

And that is before you account for time.

Even very good teams struggle here, because they are rarely given the luxury of rebuilding the web carefully. Projects have deadlines. Stakeholders want features. The content model is unfinished. The component library is incomplete. Someone decides personalisation is in scope. Search needs replacing. Forms need integrating. Analytics is late. Preview does not quite work. Redirect logic gets pushed back. Structured data is “phase two”. Accessibility gets pencilled in for QA. The launch date does not move.

So compromises pile up. Not because the team is reckless, but because rebuilding all this properly is far more demanding than the early architecture diagrams suggest. The result is not usually catastrophic failure. It is something more common and more insidious. A slow accumulation of little shortcomings. Missing semantics. Fragile templates. Editorial friction. Incomplete parity with the old platform. Workarounds everywhere. A growing sense that ordinary tasks have become oddly difficult.

And through all of this, the project still gets described as more advanced. More modern. More scalable. More future-proof. That is one of the more dangerous features of engineering-led rebuilds. The language of sophistication makes it harder to admit that the system is, in many practical respects, simply worse.

This is also why so many headless projects end up depending on a handful of key people. Once the architecture becomes bespoke, institutional knowledge gets trapped inside the team that built it. Marketers do not understand how it works. New developers take time to get productive. Agencies leave behind undocumented patterns. The whole platform becomes harder to reason about, harder to govern, and harder to change safely. The site may have been sold as more flexible, but in practice it has become more dependent on specialist knowledge.

That dependency is usually the tell. Good platforms reduce the amount of expertise required to do ordinary work. Bad ones increase it. Headless often does the latter while pretending to do the former.

None of this means that good headless implementations do not exist. They do. But they tend to come from organisations with unusually strong engineering discipline, mature governance, deep cross-functional collaboration, and a very clear reason for accepting the trade-offs. They are the exception which gets used to justify the rule.

Most teams do not have that level of capability. More importantly, most teams do not need to. A marketing website should not require extraordinary talent just to achieve baseline competence. It should not depend on a rare combination of engineering maturity, editorial foresight, and operational rigour in order to publish a page cleanly, quickly, and safely. If that is the threshold for success, then the architecture is wrong.

And that is the part engineering teams often miss. The question is not whether they can build something impressive. The question is whether they should be spending their time and energy rebuilding solved problems, when the actual job of the website is much simpler, much more immediate, and much more commercial.

“We can build anything” is not the same as “we should build this”

This is the line that sits underneath almost every headless project. Not always stated outright, but always there in the background. We can model this properly. We can design a better front end. We can create reusable components. We can orchestrate content across systems. We can customise the editing experience. We can build exactly what we need, without being constrained by the assumptions of somebody else’s platform.

And perhaps that is true. But capability is not strategy. The fact that a team can build something does not mean that building it is a good use of time, money, attention, or organisational energy.

That sounds obvious, yet it is remarkable how often architecture decisions get made as though implementation cost were the only meaningful variable. Can we do it. Will it scale. Is it modern. Does it give us flexibility. All perfectly normal questions. But they tend to crowd out the more uncomfortable ones. What are we no longer doing if we choose this path. What gets delayed. What gets harder. Who becomes dependent on whom. What complexity are we introducing simply to avoid complexity of a different, older, less fashionable kind.

That is the opportunity cost that rarely makes it into the sales deck.

Because when a team decides to go headless, it is not just choosing a different way to render pages. It is choosing to spend time reinventing capabilities that already existed. Routing, templating, previewing, publishing, caching, forms, redirects, metadata management, internal search, editorial governance, content relationships, asset handling, localisation, analytics instrumentation, consent logic, structured data, error states, fallback behaviour. None of these are impossible problems. Most are solved problems. But once you decide the existing solutions are beneath you, they all become your responsibility again.

Every hour spent rebuilding those things is an hour not spent improving the actual effectiveness of the website.

That is the bit teams consistently underplay. The real cost of headless is not only in infrastructure or maintenance. It is in distraction. Attention gets pulled into platform concerns. Roadmaps fill up with engineering work whose main purpose is to achieve parity with what a more conventional system would have provided from the outset. Delivery slows. Marketing waits. Campaigns get shaped around system constraints. Small changes start needing estimation. Easy wins disappear into backlog grooming. The website becomes a programme of work rather than a tool for getting work done.

All of this gets rationalised, of course. It is an investment. A foundation. A strategic platform play. Once it is in place, everything will move faster. And sometimes, in some organisations, that eventually becomes true. But in many others, the promised future agility never really arrives. The team stays trapped in the gap between what the platform could become and what the business needs right now.

That is why the “we can build anything” mindset is so dangerous. It treats the absence of constraints as inherently valuable, when in practice most useful systems depend on exactly the right constraints. Guardrails are not the enemy. Mature templates are not the enemy. Opinionated workflows are not the enemy. Sometimes the most valuable thing a platform can do is make the common case simple, safe, and fast. The pursuit of infinite flexibility often destroys that in exchange for a long tail of theoretical possibilities nobody ever uses.

And then there is the institutional cost. Once the site becomes bespoke, it starts to accumulate all the usual liabilities of bespoke systems. Specialist ownership. patchy documentation. Tribal knowledge. Fragile assumptions hidden inside build steps and deployment rules. Every custom layer increases the surface area which only the engineering team can understand, maintain, and safely change. That may feel empowering to the people building it. To the rest of the organisation, it is often just dependency with better branding.

This is where the vanity comes in, and why the term is justified. Not because engineers are foolish for wanting control, or because bespoke systems are always indulgent, but because the desire to build the ideal architecture can become disconnected from the mundane reality of what the website is for. A marketing site does not become more valuable because it is technically impressive. It becomes more valuable when it helps the business communicate better, publish faster, and adapt more easily. If the chosen architecture consumes months of attention to produce a platform which is harder to operate and slower to evolve, then the achievement is mostly aesthetic.

The web industry has a long history of mistaking difficulty for sophistication. We assume that the custom solution must be the serious one, that the composable one must be the strategic one, that the thing which requires more moving parts must be the thing grown-up teams choose. But often the opposite is true. The more disciplined decision is to resist the temptation to rebuild, accept the useful constraints of the platform, and spend your finite time solving the problems that are actually unique to your business.

That is the test headless so often fails. It offers engineers the freedom to build anything, then quietly asks the organisation to absorb the cost of proving that point.

Why marketers always pay the price

The deepest irony in most headless projects is that the people who bear the consequences are rarely the ones who chose the architecture.

A marketing website is supposed to be operated by marketers. That does not mean engineers are unimportant, or that governance does not matter, or that every stakeholder should have unlimited freedom to do whatever they like. It means that the system should be shaped around the day-to-day needs of the people responsible for campaigns, messaging, structure, experimentation, and growth. They are the ones who need to move quickly. They are the ones who need to respond to market conditions, adjust positioning, launch landing pages, update calls to action, test ideas, and keep the site aligned with the business.

Headless often makes all of that harder.

Not always immediately. In the early days, there is usually a polished demo, a shiny component library, and a sense that everything is now more structured and scalable. But once the site is live, the friction starts to appear. A page cannot be launched without development support because the right component does not exist yet. A layout cannot be changed because the content model assumes a different structure. A preview is unreliable, so nobody feels confident publishing. Redirects live somewhere obscure. Metadata editing is either hidden, incomplete, or treated as a specialist concern. Internal linking is awkward. Campaign pages need estimating. What used to be a quick change in a CMS becomes a request, a dependency, a process.

That is the pattern. The architecture is sold as flexibility, but the lived experience is often reduced agency.

This is partly because headless systems tend to encode decisions more rigidly than teams expect. In order to make a decoupled platform manageable, you end up defining components, schemas, rules, and editorial boundaries with increasing precision. Again, none of that is inherently bad. Some structure is healthy. But the more the system depends on custom logic and developer-owned abstractions, the more ordinary marketing activity gets funnelled through the assumptions of the people who built it. The result is a website that is technically modular but operationally inflexible.

And marketers notice. They may not describe the problem in terms of rendering models or content architecture, but they feel it in all the ways that matter. They feel it when a campaign slips because a page template needs engineering work. They feel it when testing a new idea requires changes to a component definition. They feel it when analytics do not quite line up, or when editorial workflows become too brittle to support the pace of the business. They feel it when simple changes become expensive, when momentum gets lost, and when the website starts behaving less like a tool and more like a queue.

That loss of momentum is easy to underestimate, because it does not always show up as a dramatic failure. More often it shows up as hesitation. Fewer experiments. Fewer new pages. Safer ideas. Workarounds. Campaigns shaped to fit the platform rather than the platform adapting to the campaign. Teams stop asking for things because they already know the answer will be slow, costly, or complicated. The website becomes less dynamic, less responsive, less useful. Standing still was never the safe option — but neither is a platform that makes moving harder. Not because anybody intended that outcome, but because the cost of change has crept upward.

This is where the business damage really happens. Not in some abstract debate about stack choices, but in the cumulative effect of reduced agility. Marketing works best when it can iterate. When it can publish quickly, test cheaply, learn fast, and change direction without ceremony. Systems which interrupt that rhythm do not just frustrate teams. They reduce the effectiveness of the organisation.

And the damage is asymmetric. Engineers may experience the headless architecture as clean, modern, and empowering. They have more control, more expressive tools, more room to design elegant systems. Marketers experience the same architecture as distance. More steps between intent and execution. More opacity. More dependency. More waiting. The same decision that gives one team autonomy often takes it away from another.

That trade-off might still be acceptable if the outcome were dramatically better. But it often is not. The site is not always faster. It is not always easier to maintain. It is not always more secure in any meaningful day-to-day sense. What is consistently true is that it is more complex, and complexity almost always punishes the people furthest from implementation first.

This is why so many headless websites end up failing the most basic test. They are impressive systems which make it harder to do marketing.

That should be a disqualifying flaw. If the platform responsible for your publishing, positioning, and conversion activity cannot be comfortably operated by the teams responsible for those outcomes, then something has gone badly wrong. It does not matter how elegant the architecture is. It does not matter how modern the stack looks on a conference slide. It does not matter how much optionality it promises in theory. A marketing website which disempowers marketers is not advanced. It is misdesigned.

That is usually the moment when people realise, too late, that what they built was not really a better website. It was a more interesting engineering project.

When headless is actually justified

None of this means that headless is always wrong.

There are organisations for whom it is a sensible choice. There are teams with the engineering depth, editorial discipline, governance maturity, and operational patience to make it work. There are products and publishing models whose needs genuinely extend beyond what a more conventional website stack can comfortably support. The problem is not that headless never makes sense. The problem is that it is treated as an aspirational default when it should be a narrow exception.

A good rule of thumb is this. Headless is justified when the complexity is already inherent in the business, not when the architecture introduces complexity in the hope that the business might benefit from it later.

That distinction matters. Some organisations really do have unusually demanding requirements. They may need to publish structured content across multiple products, interfaces, regions, devices, and customer touchpoints, each with different presentation logic and operational constraints. They may be running a platform where the website is only one of many outputs, and where centralising content and decoupling delivery creates real leverage. They may need application-like experiences, bespoke workflows, or deeply integrated systems that make a traditional page-driven model genuinely limiting.

In those cases, headless can be the right answer. But notice what makes it right. Not fashion. Not developer preference. Not the vague promise of future-proofing. A concrete operational need, substantial enough to justify the cost of solving it properly.

Because even when the use case is valid, the success criteria are brutally high. The team needs to understand not just how to build a decoupled front end, but how to preserve all the things ordinary websites rely on. SEO, accessibility, previewing, metadata, redirects, localisation, analytics, publishing workflows, resilience, performance under real-world conditions, and all the other details that get taken for granted until they go missing. It also needs the organisational maturity to maintain those systems over time, document them well, onboard new people into them, and keep the experience operable for non-engineering teams.

That is a very different proposition from simply deciding that the site should be built with modern tooling.

And it is worth being honest about how rare those conditions are. Most companies do not have meaningful omnichannel content requirements. Most are not running a dozen distinct front ends from one canonical source of truth. Most do not need to publish to apps, devices, kiosks, partner ecosystems, and bespoke interfaces from the same content model. Most are not trying to make the website behave like a software product in its own right. Most are trying to run a good website.

That’s why the strongest justification for headless is not theoretical flexibility. It is specificity. A real need. A clear use case. An unavoidable level of complexity that already exists and has to be handled somewhere.

Even then, the burden of proof should be high. “It might be useful later” is not enough. “Our developers prefer it” is not enough. “This is the direction the industry seems to be moving” is definitely not enough. If the architecture makes the system harder to operate, more dependent on specialist knowledge, and less usable for the teams who actually run the site, then the business case needs to be overwhelming.

That is why headless should be treated the way we treat other specialist architectural patterns. As something you adopt because the shape of the problem demands it, not because it looks like the mature option from a distance. Nobody sensible argues that every organisation should run a microservices architecture, build a custom operating system, or maintain its own database engine just to prove that it can. We understand that those decisions only make sense under specific conditions, and that complexity is a cost to be justified, not a badge of ambition.

Websites deserve the same discipline.

A headless build can be the right answer when the organisation is genuinely unusual, the problem is genuinely complex, and the team is genuinely capable of carrying the burden. Outside those cases, it is usually just an expensive way of making a normal website harder to run.

The better default

For most organisations, the right answer is not a headless website. It is a normal website, built properly.

That sounds almost embarrassingly unfashionable to say out loud, which is probably part of the problem. The web industry has spent years treating the ordinary website as something primitive to be escaped, as though the only serious path forward were greater abstraction, more decoupling, more layers, more machinery. But for a marketing site, the better default is usually much simpler. Server-rendered HTML. Strong templates. Good content modelling. Sensible CMS governance. Progressive enhancement where it adds value. Aggressive caching. A clear publishing workflow. Fewer moving parts. More operability.

In other words, a website.

Not a miniature platform. Not a distributed system. Not an architectural statement. Just a robust, well-designed, high-performing website that the marketing team can actually use.

This is not an argument for nostalgia, and it is not an argument for monoliths in the pejorative sense people like to throw around. It is an argument for respecting the strengths of the web platform instead of treating them as limitations. A document-first model has enormous advantages. It is resilient. It is understandable. It is crawlable, linkable, cacheable, and accessible by default. It makes the common case cheap. It does not require extraordinary effort to preserve the basics. It gives teams a stable foundation on top of which they can still do sophisticated things.

Because that is the other quiet lie underneath so much headless evangelism. The implication that conventional architectures are somehow incapable of being fast, flexible, secure, or modern. They are not. A well-run CMS can support structured content, reusable components, flexible templates, powerful workflows, and strong governance. A server-rendered site can be blisteringly fast. A progressively enhanced front end can feel rich and responsive without forcing the whole experience through a JavaScript application shell. Security can be handled through sane operational practice rather than architectural theatre.

The point is not that every traditional setup is good. Plenty are dreadful. Bloated themes, plugin graveyards, brittle workflows, editor experiences from 2009, sluggish hosting, no governance, no performance discipline. Those systems deserve criticism. But their failures do not magically make headless the answer. They just mean the site was poorly run.

That distinction is important, because many teams end up choosing headless not to solve a truly unique problem, but to escape the consequences of bad decisions elsewhere. A chaotic CMS becomes an excuse to abandon the model entirely. Weak editorial governance becomes an excuse to centralise control inside engineering. Poor front-end discipline becomes an excuse to start over with a fashionable stack. It feels strategic, but often it is just a costly way of avoiding the harder work of running a sensible web platform well.

And that work is not glamorous. It is about choosing good defaults and sticking to them. Designing templates around real content. Maintaining semantic markup. Keeping payloads lean. Managing redirects properly. Giving editors sensible tools and boundaries. Setting performance budgets. Treating accessibility as part of the build, not a QA afterthought. Building systems which make ordinary work fast and safe. This is not the sort of thing that gets architects excited on a whiteboard, but it is how good websites are actually made.

That is why the better default matters so much. Defaults shape behaviour. A good default lowers the cost of doing the right thing. It makes the site easier to operate, easier to govern, easier to extend, and easier to trust. It empowers marketers without abandoning technical standards. It gives engineers useful constraints instead of an open invitation to rebuild the world. It keeps complexity proportional to the actual needs of the business.

And that, really, is the whole case against headless as a default. Not that it cannot work. Not that it never has value. But that most organisations do not need a website architecture built around exceptional requirements, exceptional talent, and exceptional discipline. They need a website that works. One that can publish quickly, evolve safely, perform well, rank well, and support the people responsible for growth.

Headless can do that. Sometimes. With the right team, the right problem, and the right level of commitment. But most of the time, it is an expensive detour into complexity, justified by the language of flexibility and modernity, and paid for in slower delivery, weaker defaults, and lost marketing autonomy.

That is the cost of engineering vanity. Not just that the system becomes more complicated, but that it becomes more complicated in service of the wrong things.The better default is not less ambitious. It is more honest. Build a website like a website. Respect the platform. Keep the stack as simple as the problem allows. Give marketers the power to do marketing. And stop treating architectural overreach as a mark of seriousness.