Modern web stack is reshaping how we work. Headless composable matters because the terminology around modern web architecture has, somewhere along the way, become a shield rather than a tool. Headless. Composable. Jamstack. Microfrontends. MACH. Edge-rendered. Each term has technical merit; each is also wielded as a status signal by vendors and agencies whose primary interest is justifying complexity.
Stripping the jargon back, the underlying ideas are simpler than they sound and the choices between them are more pragmatic than they’re often presented. Here is the honest version, with a view to helping non-technical decision-makers ask the right questions of whoever is proposing an architecture.
What the modern web stack actually means
A traditional content management system – WordPress in its default configuration, for instance – is “coupled.” The same software that stores and manages content also renders the website you see. The content management interface and the public-facing website are two faces of the same system.
A “headless” CMS separates these. Content is stored and managed in one system (the “body”) and rendered to the user by a separate system (the “head”). They communicate through an API. The same content can power multiple heads – a website, a mobile app, a digital signage screen, an AI assistant – without duplication.
The advantages: flexibility, performance, the ability to use the best tool for each job. The disadvantages: more moving parts, more integration complexity, more decisions to make and maintain.
the honest test for whether headless is right: are you publishing content to multiple destinations, or do you have specialised performance or design requirements that a coupled CMS can’t meet? If yes, headless. If no, the additional complexity rarely pays back.
What “composable” actually means
Composable architecture takes the headless idea further. Instead of one CMS, one frontend, one e-commerce platform, the system is built from many specialised services, each chosen for its strength, integrated through APIs.
A composable e-commerce site might combine: a headless CMS for content, a specialist e-commerce platform for cart and checkout, a search service, a personalisation engine, an analytics platform, a customer data platform. Each can be swapped out independently as the business evolves.
The advantage: best-of-breed at every layer, no platform lock-in, the ability to evolve incrementally rather than re-platforming wholesale. The disadvantage: significant integration complexity, ongoing operational overhead and the need for engineering capability to manage the moving parts.
The honest test: does your business have specialised requirements at multiple layers that no single platform serves well? Are you large enough to absorb the integration complexity? If yes to both, composable. If no, a well-chosen integrated platform will serve you better.
What “modular” actually means
Modular architecture is the discipline of building any system – coupled, headless or composable – out of independent, well-defined components that can be developed, tested and replaced independently.
this is less a choice between architectures and more a quality of how any architecture is implemented. A modular monolith can be excellent. A non-modular composable system can be a nightmare. The discipline of modularity is what allows software to evolve gracefully over years rather than calcifying into something nobody dares change.
This isn’t optional in serious work. Every project we ship is modular by construction, regardless of which higher-level architectural pattern it sits within.
The frameworks that matter in 2026
A short, honest survey of the frameworks worth considering for a new web project:
Next.js (React-based). The dominant choice for serious web applications and content-rich sites alike. Excellent server-rendering, mature ecosystem, strong AI tooling integration. Our default for most projects unless there’s a specific reason to choose otherwise.
Remix (now part of React Router). Strong on data loading and forms. Particularly good for applications with complex form workflows. The mental model is cleaner than Next.js for some teams.
Astro. Excellent for content-heavy sites where minimal client-side JavaScript is desired. Outstanding performance characteristics. Less suited to highly interactive applications.
SvelteKit. Smaller community than React-based options but produces dramatically smaller bundles and faster runtime performance. Worth considering for performance-critical projects.
WordPress. Yes, still. For content-heavy marketing sites with mature editorial workflows, modern WordPress (especially headless or with a sophisticated custom theme) remains a defensible choice. The case is weaker for applications, but the platform’s strengths in content management are real.
The framework choice matters less than the discipline of how the framework is used. We’ve seen exceptional sites built on every option above and disasters built on each one too.
The CMS landscape
For content management specifically, the practical choices have narrowed to a handful of strong options:
WordPress. The dominant CMS by market share. Used well – with custom fields, performance optimisation and a modern theme – it remains capable. Used badly, it’s the source of most of the slow, bloated websites on the open web.
Sanity, Contentful, Storyblok. The headless CMS leaders. Strong APIs, good editorial experiences, mature. Sanity is our usual recommendation for ambitious headless projects; the others are excellent depending on team preferences and existing tooling.
Payload CMS. A newer entrant, self-hosted, code-first. Strong choice for teams that want CMS capabilities tightly integrated with custom application logic.
Webflow. Excellent for marketing sites where a designer needs control without engineering involvement. Less suited where significant developer customisation needs.
The right choice depends on three factors: who will manage the content (technical or non-technical), how much custom application logic surrounds the content and what other systems need access to it.
The pragmatic decision framework
when we recommend an architecture for a client, the conversation runs through five questions:
- What is the content shape? Marketing pages, blog posts, product catalogues, knowledge base, all of the above? The answer drives CMS choice.
- What is the application shape? Pure content site, content + commerce, content + custom application, custom application with some content? This drives the framework choice.
- Who manages content day to day? A non-technical marketing team? Developers? Editors with specific workflow needs? The answer drives the editorial experience requirements.
- What are the integration requirements? Which systems need to read or write content, in which direction, with what frequency?
- What is the team’s appetite for ongoing complexity? A composable architecture with five integrated systems demands more operational maturity than a coupled WordPress site. Honest assessment of the team’s capability matters.
The best architecture is the simplest one that meets the actual requirements. Reaching for headless or composable when a coupled solution would serve is a common and expensive mistake.
The strategic point
Modern web architecture is genuinely more capable than it was five years ago and the right choices unlock real performance, flexibility and longevity benefits. The wrong choices – usually driven by chasing buzzwords or vendor incentives – produce expensive, fragile systems that nobody can maintain.
The discipline is to start from the actual requirements and work outwards, not to start from a fashionable architecture and find a project to fit it.
Wondering what architecture is actually right for your next build? We make these recommendations based on your requirements, not on what we want to sell. Get in touch and we’ll help you decide.