Composable Regret: Why Most Sites Don't Need a Headless CMS (And What to Build Instead)

"Regrets, I've had a few," sang Frank Sinatra in My Way. Umbraco's CTO Filip Bech-Larsen used that exact line to open his CMS Critic piece on composable regret — and it wasn't an empty metaphor.

In June 2026, a LinkedIn analysis captured the industry sentiment with a phrase that stuck with us: "The CMS decision used to be 'which platform?' In 2026, it's 'which architecture?' — and the marketing around headless and composable has gotten loud enough that buyers routinely over-buy."

We've seen it firsthand. Over the last two years, three projects that came to Mintec asking for "headless" ended up with a much simpler solution — and the teams were happier than if they'd forced an architecture they didn't need.

The Promise vs. The Reality

The case for headless CMS is seductive: separate content from presentation, use the most modern frontend tools, distribute to any channel, and get world-class performance.

The reality, as Bech-Larsen documented in CMS Critic: "when going fully headless, many organizations have been forced to build a custom integration layer for their composable best-of-breed architecture, which has eaten into project time, budget, and developer resources." Instead of the promised agility, engineering backlogs multiplied and marketing teams waited weeks for simple changes.

The problem isn't headless. The problem is applying headless where it's not needed.

Three Signs You're Over-Engineering Your CMS

We've identified three recurring patterns in projects where headless would have been counterproductive:

1. Your editorial team is larger than your dev team. If you have five editors and one developer, handing them a Sanity or Contentful interface with live preview isn't the same as handing them WordPress. WordPress's visual editor, in 2026, is still more intuitive for non-technical teams than any headless CMS on the market. The improvements headless CMS platforms have made to editor experience are real, but they haven't closed that gap.

2. You have a single content channel. Headless shines when you're simultaneously feeding a website, mobile app, digital kiosk, and voice assistant. If your reality is a website and a blog, the architectural benefits of headless don't justify the operational overhead of maintaining a separate frontend, API, and build pipeline.

3. Your content changes fast in unpredictable formats. Headless CMS platforms love structured content. The reality is that content is often messy. If your editorial team needs to launch a landing page with a new layout every week, a traditional CMS with page builders or flexible blocks wins every time.

The Decision Framework We Use at Mintec

When a client asks us whether to go headless, we don't start with platforms. We start with a two-axis grid:

The key is being honest about where you are today, not where you hope to be in three years. We've seen too many projects buy architecture for their "future self" and end up paying support costs for complexity they never needed.

Practical Alternatives That Work

WordPress isn't dead. In 2026, WordPress powers over 43% of the web. With modern hosting (Kinsta, Rocket.net, WP Engine), a lightweight theme, and a well-configured caching plugin, a WordPress site loads in under 2 seconds and passes Core Web Vitals. Most users won't notice the difference between an optimized WordPress site and a headless one. What they will notice is when content is stale because the publication process is too cumbersome.

Astro + Markdoc (like this blog). It's our favorite setup for content sites where the team is technical or willing to adopt a Git-based workflow. No database, no API to maintain, no SaaS costs. Content lives as Markdoc files in the repository and compiles to static HTML at build time. The developer experience is impeccable. The trade-off: non-technical editors need a PR workflow or an additional visual layer like Decap CMS or TinaCMS.

Astro + Strapi. For when you need an admin interface but don't want Sanity or Contentful pricing. Strapi 5, released in late 2025, significantly improved the admin panel and added native TypeScript support. It's self-hosted, which means full data control and no API costs — but requires DevOps capacity.

The Lesson These Projects Taught Us

In one of our most revealing projects, a client came asking for a "headless migration" because their WordPress was slow. Before proposing a solution, we audited the real problem: it wasn't WordPress. It was an overloaded theme, misconfigured plugins, unoptimized images, and shared hosting. We cleaned up the WordPress instead of replacing it. The site went from Lighthouse 45 to 92. The client saved $40,000 in the first year compared to the headless migration budget another agency had quoted.

Not every project needs a new architecture. Many need a cleanup. And that's exactly the point: the right tool isn't the most modern one — it's the one that solves the actual problem without creating a dozen new ones.

At Mintec, we build web architectures for clients who need content that works across channels — websites, apps, email, and beyond. But we also help clients not migrate when the migration wouldn't add value. Sometimes the best service is saying "you don't need this."

For more on web architecture decisions:

• Headless CMS: Why Modern Web Development Is Going Architecture-First
• Composable Web Architecture: Headless CMS, SSGs, and the End of Monolithic Sites
• Server Islands vs Partial Prerendering: Choosing Your Content Architecture
• Why High-Growth Brands Are Abandoning Standard Themes for Headless Commerce

Sources

• CMS Critic, "Combatting Composable Regret in 2026" — Filip Bech-Larsen, CTO of Umbraco (https://cmscritic.com/combatting-composable-regret-in-2026)
• LinkedIn, "Headless, Composable, or Traditional CMS in 2026: Which Should You Choose?" — Divya (https://www.linkedin.com/pulse/headless-composable-traditional-cms-2026-which-should-divya-27tdc)
• Mintec internal project data from migration and optimization engagements 2024-2026