Every commerce platform vendor now markets a "headless" option, and every agency pitch deck has a slide about composable architecture. The pitch is compelling: decouple the frontend from the backend, ship experiences faster, and stop being limited by a monolithic platform's templating engine. What the pitch decks leave out is that headless commerce trades one set of problems for a different, more engineering-intensive set — and it's the wrong choice for a meaningful share of the businesses being sold on it.
This is the framework we use with clients deciding between a traditional platform (Shopify, WooCommerce) and a headless build.
What "headless" actually means
In a traditional commerce platform, the backend (product catalog, cart, checkout, inventory) and the frontend (the storefront a customer sees) are tightly coupled — the platform renders the pages using its own templating system. Headless commerce separates these: the backend exposes data through an API, and you build the frontend independently, typically with a framework like Next.js, and connect to the commerce backend purely through API calls.
This separation is genuinely powerful for the right use case. It's also genuinely more work to build and maintain than most vendor pitches admit.
The real benefits — and where they actually apply
Performance headroom. A custom Next.js frontend using server-side rendering, static generation for stable pages (category and product pages that don't change every minute), and edge caching can dramatically outperform a templated storefront — often cutting LCP in half. This benefit is real, but it only shows up if the team building the frontend actually implements caching and rendering strategy correctly. A poorly built headless frontend can be slower than a well-optimized traditional storefront.
Omnichannel flexibility. If you need the same product catalog and inventory to power a website, a native mobile app, an in-store kiosk, and a marketplace integration, a headless API-first backend avoids duplicating commerce logic across each surface. This is the strongest, least debatable argument for headless — but it only matters if you actually have (or are building) more than one channel.
Design freedom. Traditional platform themes constrain layout to what the templating system supports. A custom frontend has none of those constraints — genuinely custom product page layouts, checkout flows, and interactive merchandising become possible. This matters most for brands where the storefront experience itself is a differentiator (fashion, D2C brands with strong visual identity), and matters much less for commodity or B2B catalog sites where customers care about price and availability, not layout polish.
The costs vendors don't put on the slide
You inherit the checkout problem. Building and maintaining a PCI-compliant, conversion-optimized checkout flow from scratch is a nontrivial engineering investment. Most headless setups solve this by keeping checkout on the commerce platform's hosted solution (Shopify Checkout, for example) and only decoupling the browsing and cart experience — which is a smart middle ground, but it means you're not fully "headless" in practice, and you should budget accordingly rather than pretend otherwise.
Preview and content workflows get harder. Marketing teams used to a WYSIWYG theme editor lose that convenience with a custom frontend unless you invest separately in a headless CMS layer with live preview — which is another system to integrate, license, and maintain.
Total cost of ownership goes up, not down. A headless build requires ongoing frontend engineering resources that a templated store doesn't. If the business doesn't have (or budget for) continued frontend development capacity post-launch, a headless storefront degrades faster than a maintained platform theme, because there's no vendor pushing updates for you.
More moving parts, more failure points. API integration between the frontend, the commerce backend, a CMS, a search provider, and possibly a separate checkout means more systems that can go down independently, and more surface area for edge cases (stale cache showing sold-out products as available, for example).
A decision framework, not a default
We walk every client through three questions before recommending headless:
- Do you have more than one real channel today, or a committed roadmap to build one within 12 months? If the answer is just "a website," headless's biggest structural advantage doesn't apply yet.
- Is the storefront experience itself a competitive differentiator for this brand, or is the business winning on price, catalog breadth, or logistics? Custom design freedom matters far more in the first case.
- Does the business have (or is it budgeting for) ongoing frontend engineering capacity after launch — not just for the initial build, but for maintenance, feature additions, and dependency upgrades?
If the answers lean toward multi-channel, design-differentiated, and resourced for ongoing engineering, headless is very likely worth it — the performance and flexibility gains compound over years. If the answers lean toward single-channel, catalog-driven, and lean on ongoing dev resources, a well-optimized traditional platform (Shopify with a customized theme, for instance) will outperform a headless build on total cost and speed to market, and it isn't a lesser choice — it's the correct engineering call for that business.
What a pragmatic headless build actually looks like
For clients who do fit the profile, our build pattern typically looks like:
- Next.js frontend with static generation for catalog and category pages, incremental revalidation for pricing/inventory freshness, and server components for anything non-interactive.
- Commerce backend (Shopify's Storefront API, or a dedicated headless commerce platform) handling product data, cart state, and — critically — checkout, rather than reinventing PCI-compliant payment flows from scratch.
- A headless CMS for marketing-controlled content (landing pages, promotional banners, blog) with live preview so non-technical teams retain editorial independence.
- Search and merchandising via a dedicated provider (Algolia or similar) rather than relying on the commerce backend's native search, which is usually the weakest part of most platforms.
Bottom line
Headless commerce is a genuine architectural upgrade for the right business — not a universal best practice. The businesses that benefit most are multi-channel, design-differentiated, and resourced to maintain custom frontend code long after launch. Everyone else is usually better served by a well-executed traditional platform build, and a good engineering partner should tell you that plainly instead of selling the more expensive architecture by default.
If you're evaluating a rebuild and aren't sure which side of that line your business falls on, that's exactly the conversation our website & e-commerce team has with every new client before recommending an architecture.