← Back to blog

Five questions I ask before proposing headless to a client

In the past two years I've turned down headless three times. Not because I don't believe in it — I've built it, I know what it delivers. But each time, five questions made the answer obvious before we touched a wireframe. The fourth client got the full Next.js + Bitrix split. It's one of the best ecommerce projects I've worked on.

Here are those questions — in the order I ask them.

"We need headless" is almost never the right starting point

When a client says "we need headless," they usually mean something else:

  • the site is slow and it's embarrassing
  • a competitor relaunched in two weeks while we take two months
  • developers are complaining the CMS is in the way
  • someone read an article about Netflix or Airbnb

None of these get fixed by headless automatically. Slow pages are usually a caching or database problem. Slow releases are a deployment architecture and process problem. Developer complaints might be about headless, might be about technical debt, might be about something else entirely.

Headless is an architectural choice with a real cost: a separate frontend deployment pipeline, an API contract between systems, new failure modes. That cost is worth it — but only when the five answers point in the right direction.

Question 1. How often does the frontend change independently of content?

The core argument for headless is deploy independence: you update the UI without touching the CMS. New design system, updated component library — the frontend ships separately.

That's a real benefit. But only if it actually happens.

If the frontend changes once a quarter and the team still has to coordinate with Bitrix for every release, the separation doesn't help. I've seen teams build headless "for future scale" and then not make a single independent frontend deploy in two years. The API contract broke twice, though.

Honest diagnostic: "Show me your last 10 frontend deployments. How many required a CMS change?" If the answer is "all of them" or "most of them," headless won't change that.

Question 2. Is there a dedicated frontend team — or a plan to hire one?

Headless requires a frontend engineer who knows Next.js well. Not a full-stack developer who "does some React" — someone who understands SSR, ISR, edge caching, and can debug hydration issues.

This isn't gatekeeping. It's the price of the architecture.

On a monolith, one developer can move across the whole project — PHP templates, business logic, content. On headless, you have two separate domains: the backend API and the frontend application. Switching context between them is expensive.

If a client has two developers covering the whole project and no hiring budget, headless doubles their support overhead. The project I turned down for $40K looked exactly like that: two developers who would have owned the API, the frontend, and Bitrix maintenance simultaneously.

Question 3. What's the specific pain — and does headless actually fix it?

The specific CMS pain — and whether headless actually addresses it — matters more than any other factor. It's also the question that gets answered least honestly.

Ask the client to name three specific problems they want to solve. Then go through each one.

Site is slow. Headless might help if the bottleneck is PHP template rendering. But if the bottleneck is database queries or misconfigured caching, headless won't help. You need a profiler, not a new architecture.

UI changes are hard to ship. If the cause is tangled Bitrix markup, headless solves it. If the cause is years of accumulated messy code, headless just moves the pain somewhere else.

Developers want a modern stack. That's not a business argument on its own. Sometimes there's a real problem behind it — hiring difficulties, slow onboarding. Sometimes it's just wanting to use different tools. Worth separating.

The clearest headless signal: "Editors publish content in the CMS, and we want to show it in a mobile app, on the web, and at a kiosk." Headless is about decoupling content from presentation. If that decoupling isn't the actual need, neither is headless.

Question 4. Can the team absorb 3-6 months of slower delivery?

Headless migration means running two systems in parallel. The old site keeps running while the new one gets built. That means part of the team is in "old," part is in "new," and features slow down across the board.

On the 28,000-SKU project, we estimated the catalog and search migration at 6 weeks. But only because we made a decision upfront: checkout and account pages stay on Bitrix templates. A full rewrite would have taken 6 months, minimum.

The question isn't whether the client can afford headless. It's whether they can afford to operate in construction mode for the next several months while competitors aren't.

If there's a busy season in three months, headless is the wrong conversation to be having right now.

Question 5. Who will own the API contract in two years?

The API between Bitrix and Next.js is a living artifact. It changes with every new feature: a new field on the product card, a restructured category tree, a pricing logic change. Someone has to make those changes in sync on both ends.

During the project this sounds like implementation detail. Two years later it's the main source of breakage.

I've seen teams build the API layer, then the original engineers leave. A new team adds fields to Bitrix, not knowing they're used on the frontend. The frontend breaks in production. These incidents take time to fix — and they erode trust in the architecture.

If there's no clear answer to "who owns this contract in two years," there's someone to build headless but no one to maintain it.

When headless is actually the right call

I'm not against headless. I'm against headless by default.

When the five answers line up, headless pays off:

  • The frontend changes independently of content, and that happens regularly
  • There's a dedicated team with genuine Next.js experience
  • The specific pain (render performance, multi-channel delivery, deploy independence) maps directly to what headless fixes
  • The team has runway for a transition period without a hard deadline looming
  • There's a clear owner for the API contract long-term

On the 28,000-SKU project, all five were true. LCP dropped from 4.2s to 1.4s, mobile conversion went up 23%, and in two years no frontend deploy has taken down the backend.

When headless is the wrong answer, I say so. When it's right, I build it.

Five questions. Before Figma.