Headless commerce has become one of the most consistently over-recommended architectural patterns in the Adobe Commerce ecosystem. The pitch is compelling — best-in-class performance, design flexibility, future-ready architecture — and the case studies are real. But the case studies are also unrepresentative of where most mid-market Adobe Commerce retailers actually are, and the headless recommendation is increasingly being made by partners with a commercial interest in the larger, more complex implementation rather than by partners with the retailer’s interest in mind.
This article makes the case for why most mid-market Adobe Commerce retailers should not go headless. It is written from the perspective of Bemeir’s Adobe Commerce architecture practice, which has both built headless implementations for retailers where the math justified it and explicitly advised against headless for retailers where it didn’t. The recommendation in the second category is consistently the harder conversation to have, because it is the one where the pitch from a different partner sounds louder than the honest analysis.
The five scenarios where headless is the wrong call
1. The pain you are trying to solve is performance on Luma. This is the most common misdiagnosis. The retailer’s current Adobe Commerce platform is on Luma, the mobile experience is slow, the Core Web Vitals are poor, and someone has suggested that headless is the solution. The honest answer is that Hyvä will solve this problem at a fraction of the cost. Hyvä migrations for mid-market retailers typically run $120,000-$200,000 and deliver mobile LCP under 2 seconds. The equivalent headless implementation runs $250,000-$500,000 and delivers mobile LCP under 1.2 seconds. The incremental performance gain from headless over Hyvä is real but small, and the cost increment is large. For most mid-market retailers, the performance ROI of Hyvä is dramatically better than the performance ROI of headless.
2. The internal team does not have React expertise. Headless Adobe Commerce on Next.js requires the internal team to be comfortable with React, TypeScript, Next.js’s rendering model, and modern frontend tooling. Most mid-market Adobe Commerce retailers do not have this depth in-house, and acquiring it requires hiring or extensive training. Retailers who go headless without this capability end up entirely dependent on their agency for any frontend change, which is not a sustainable operating model. The retailers who succeed with headless are the ones with either existing React capability or a clear plan to build it.
3. The roadmap does not include experiences beyond the web storefront. One of the strongest cases for headless is the ability to share frontend components across web, mobile app, kiosk, and embedded surfaces. For retailers whose three-year roadmap actually includes these multi-experience initiatives, headless is the right architecture. For retailers whose roadmap is “make the web storefront better” — which is the vast majority of mid-market retailers — the multi-experience benefit is theoretical, and the headless architecture is paying for capability that will not be used.
4. The operational team cannot absorb the additional complexity. Headless platforms have meaningfully more operational surface area than themed platforms: separate frontend deployment pipeline, separate monitoring, separate scaling considerations, multiple caching layers, more nuanced incident response. Retailers without strong DevOps capability or an agency partner that takes operational responsibility tend to find that the operational tax exceeds the technical benefit.
5. The headless recommendation is coming from a partner with a commercial bias. This is the hardest scenario to recognize because the partner is usually skilled and well-spoken, and the case they make for headless is technically valid. But agencies that primarily build headless implementations have a structural incentive to recommend headless, because the build is more lucrative. A second opinion from a partner with the option to recommend either headless or themed often produces a different answer. Bemeir’s Adobe Commerce practice builds both, and we recommend each in the scenarios where each fits — which means we recommend Hyvä for the majority of mid-market retailers and headless only for the specific cases where it’s right.
| Pain or driver | Right architecture | Why not headless |
|---|---|---|
| Slow Luma performance, weak Core Web Vitals | Hyvä migration | Hyvä captures 80%+ of the gain at 40% of the cost |
| Frontend feature work is slow | Hyvä if team is PHP-strong; headless if team is React-strong | Tool choice should match team capability |
| Want best-in-class mobile experience | Hyvä for most; headless for highest-tier brand requirements | Diminishing returns after Hyvä for most use cases |
| Multi-store with shared catalog | Adobe Commerce multi-store, Hyvä-themed | Headless adds operational complexity to multi-store |
| Multi-experience roadmap (web + app + kiosk) | Headless | This is the right scenario for headless |
| Need design flexibility beyond Hyvä’s limits | Headless | Genuinely the right scenario; Hyvä caps below this |
| Team is React-native and frontend-first | Headless | Tool choice matches team capability |
The cost reality vs the marketing reality
The marketing case for headless tends to emphasize the upside: better performance, faster iteration, future-readiness. The honest cost case is harder to find in vendor marketing materials. Three cost categories consistently get underestimated:
Build cost. Headless Adobe Commerce implementations on Next.js typically run 2.0-2.5x the cost of equivalent Hyvä implementations. For a mid-market retailer, that’s the difference between $150,000 and $350,000 for the initial build. The increment has to be justified by capability the retailer will actually use.
Operational cost. Headless platforms typically require 30-50% more steady-state operational investment than themed platforms. The team has to deploy, monitor, and maintain multiple systems. The increased operational cost is permanent, not just a one-time build cost.
Agency dependency. Most mid-market retailers without strong in-house React capability end up more dependent on their agency for headless platforms than they would be on themed platforms. Frontend changes that an experienced merchandiser could ship on Hyvä now require a developer change. The total cost of ownership includes more agency hours per change.
According to Forrester’s research on headless commerce TCO, the median three-year cost differential between headless and themed implementations for mid-market retailers is roughly 60-80% higher for headless. The performance and flexibility benefits can justify this differential, but only for retailers who actually need and use them.
What headless actually delivers that Hyvä can’t
For the avoidance of doubt, headless is not a bad architecture. It is the right architecture for specific scenarios. Honest accounting of what headless delivers above Hyvä:
Sub-1-second mobile LCP at scale. Hyvä-themed Adobe Commerce typically achieves 1.5-2.0 second LCP on mobile. Well-implemented headless Next.js typically achieves 0.7-1.2 second LCP through static and incremental rendering. For brands competing on best-in-class mobile experience — premium DTC, fashion, beauty — this differential is real and quantifiable.
Frontend iteration velocity for React-native teams. Internal teams with strong React capability can iterate on a Next.js frontend dramatically faster than on a Hyvä theme. For retailers with internal frontend teams of three or more engineers and a roadmap that values frontend velocity, this is real productivity.
Multi-experience extensibility. A Next.js component library can be shared across the web storefront, the React Native mobile app, the in-store kiosk experience, and embedded commerce surfaces. For retailers with a real multi-experience roadmap, this architectural unification is genuinely valuable.
Sophisticated frontend interactivity. Complex interactive experiences — configurators, AR product previews, personalization engines with frontend ML — are easier to build on Next.js than on Hyvä. For retailers with frontend-heavy product strategies, this matters.
The right decision sequence
The retailers who get this decision right follow a specific sequence:
- Be honest about the actual pain. Is it performance on Luma? It’s a Hyvä migration. Is it slow frontend iteration with a Magento-skilled team? It’s a Hyvä migration or a team change. Is it a roadmap requirement that genuinely exceeds Hyvä’s capabilities? It might be a headless decision.
- Evaluate Hyvä against the actual roadmap. Bemeir’s Hyvä migration practice typically runs a paid evaluation engagement that documents whether Hyvä can meet the retailer’s three-year requirements. The evaluation is bounded in cost; the clarity is enormous.
- If Hyvä is insufficient, evaluate headless specifically. Document what Hyvä cannot deliver that headless can. If the documented gap is material to the business case, the headless decision is defensible.
- Stress-test the team and operating model. Does the team have React capability? Will it acquire it? Is the agency partner committed to taking operational responsibility? Is the steady-state cost sustainable? If any of these answers is unclear, the headless decision is premature.
- Make the call against documented criteria, not against vendor positioning. The decision should be defensible by the criteria documented in step 2 and 3. Decisions made under vendor pressure tend to be regretted.
The pattern across honest practitioners
Practitioners who have built both Hyvä and headless implementations and who care about retailer outcomes tend to converge on similar recommendations: Hyvä for the majority of mid-market retailers, headless for the specific subset where the case is real, and a strong default toward Hyvä when the decision is unclear. The reason is that Hyvä has eliminated most of the historical case for headless on Adobe Commerce while preserving the operational simplicity that makes the platform sustainable.
This is not a recommendation against innovation or against modern architecture. It is a recommendation toward the architecture that matches the business reality. The retailers who get this right end up with platforms that match what they actually do, instead of platforms that match what someone said they should do. That alignment is what produces the platforms that compound value over five years — not the platforms with the most impressive architecture diagrams in the partner’s sales deck.
