← Back to blog

When headless is the wrong answer

I build headless sites on Next.js + Bitrix. I've migrated a catalog of 28,000 SKUs. I turned down a $40K contract because rewriting a working monolith made no sense. And when a client walks in asking for headless, my first question is always: "Why headless, exactly?"

Most headless content is about what you gain. Speed. Stack flexibility. Almost nobody writes about the two deploy pipelines you have to keep in sync. About the API contract that breaks when a Bitrix developer renames a field without telling the frontend team. About content editors who spend a week confused without WYSIWYG.

What headless actually costs

Headless CMS is the wrong choice when your team lacks dedicated frontend expertise, your maintenance budget didn't grow with the migration, or your content editors depend on WYSIWYG workflows. That covers about 40% of the projects where clients ask me about it.

Headless isn't just "Next.js instead of PHP templates." It means:

  • Two deploy pipelines: backend (PHP/Bitrix) and frontend (Next.js/Vercel or self-hosted)
  • An API contract between teams — a living document that needs to stay current
  • Edge caching with invalidation: ISR, revalidate tags, or webhooks on every content change
  • A new workflow for editors: they no longer click "Save and Publish," they post to a headless CMS and wait for a rebuild

In my experience: that's 3 to 6 extra hours per week of maintenance in the first six months. Not counting onboarding the team.

If the project revenue justifies those hours, the conversation makes sense. If it doesn't, read on.

5 situations where headless will hurt you

Sign 1: a team without a dedicated frontend developer

Headless needs two people with different skills, or one genuinely full-stack engineer. If your team is two PHP developers and one of them "knows some React," that's not the same thing. TypeScript, SSR, hydration, edge caching, CI/CD across two repos — each takes real practice. What you actually get: Next.js templates written by a PHP developer who Googles every third line. And then takes two weeks off.

Sign 2: budget for migration, none for maintenance

Funding the migration without planning for ongoing maintenance is the most common headless mistake. The client funds the migration project but doesn't plan for supporting two systems afterward. Six months later, the question comes: "Why do we now have two servers, two CI/CD pipelines, and two developers instead of one?" Because headless. If the maintenance budget didn't grow, the migration didn't pay off.

Sign 3: editors live in WYSIWYG

Bitrix, WordPress, 1C content — these have editors who built their whole workflow around a visual editor. A headless CMS moves them into structured content: fields, blocks, preview through an API. Some people adapt within a couple of weeks. For others, it's a productivity disaster. Talk to your editors before changing the stack.

Sign 4: SEO is "nice to have," not a real KPI

The main headless argument for SEO is control over LCP, CLS, and rendering. It works. But only if SEO is actively measured, optimized, and owned by someone. If SEO is "yeah, it matters" — a well-cached monolith will get you there. Headless without SEO discipline is expensive with the same result.

Sign 5: small catalog, no personalization, no SSR requirements

Headless has the biggest impact on large catalogs with dynamic content, A/B tests, and personalization. If you have 300 products, a static structure, and no CDN edge requirements — PHP with proper caching is enough. I've seen Bitrix stores on 400 SKUs hitting LCP 1.4s. No Next.js required.

How to know if headless will actually pay off

Headless makes sense when you can answer yes to all three of these. Any "not sure" means stop.

  1. Is there a dedicated frontend developer with SSR/Next.js experience on the team (or in the budget)?
  2. Will both deploy pipelines be maintained a year from now — with documentation, ownership, and someone on call?
  3. Is there a measurable business KPI that headless will move: LCP under 2s, conversion rate, indexability?

One honest conversation before kickoff costs less than a pivot six months in.

What to do instead

Optimize the monolith

Composite page caching in Bitrix, moving static assets to CDN, proper database indexes — this typically yields 60–80% performance improvement. More detail: how Bitrix doesn't slow down.

Partial headless

Move only the catalog to Next.js, keep everything else in the monolith. One API endpoint, one pipeline. That's what I proposed instead of the full $40K rewrite. Full breakdown here. If the argument for going headless is deploy independence specifically, there's a separate piece on that.

SSI and edge caching

If performance is the problem, sometimes all you need is to move heavy blocks to the edge with Server-Side Includes. Not headless, but not a bare monolith without CDN either.

Wrapping up

Headless is a good tool. I still use it.

But only when the team, budget, and KPIs actually support it. Otherwise it's complexity you pay for twice.

When someone on your team says "we need to go headless" — run through the five signs first. One honest conversation before kickoff is cheaper than a rewrite you have to undo.