The 30-second answer
Go headless when you have a specific problem the native theme can't solve: a real performance gap, a brand experience the templates won't allow, a multi-channel ambition, or a content-commerce integration that demands a unified frontend. Stay traditional when none of those apply — going headless to be modern is the most expensive vanity project in ecommerce.
1. What "headless" actually means
Traditional commerce: storefront and backend ship as one package. Wix, Shopify Liquid, Webflow Ecommerce, WooCommerce — they all render HTML from the same machine that holds your catalog. Change the design, you're inside a theme editor.
Headless commerce: the backend still holds the catalog and processes orders, but the storefront is a separate web application (usually React + Next.js) that talks to the backend over APIs. You can redesign the storefront, deploy it on its own schedule, and host it wherever you like. The backend never changes.
2. Cost comparison
For a representative $250K/year store, year 1:
| Cost | Traditional | Headless |
|---|---|---|
| Platform plan | $30-80/mo | $30-80/mo |
| Hosting | $0 (included) | $20/mo (Vercel) |
| Bridge / SDK | $0 | $0-49/mo (Trama) |
| Setup engineering | ~20 hrs × $100 = $2K | ~80 hrs × $100 = $8K |
| Annual maintenance | $1K | $3K |
| Year 1 total | ~$3.7K | ~$12.6K |
| 3-year total | ~$7.5K | ~$20K |
Going headless costs roughly $12-15K more over three years for a typical store. The question isn't whether that's expensive; it's whether the benefits are worth it.
3. The four cases where it's worth it
Case 1: Performance you can't fix on the native theme
If your store loads in 5+ seconds, has Lighthouse below 50, and you've already tried theme optimization — the bloat is often inherent to the platform's rendering pipeline. A headless Next.js storefront gets you 1s LCP and Lighthouse 95+ without compromise.
Case 2: A brand experience the templates won't allow
Bespoke product configurators, AR try-ons, scrolling editorial pages, unusual interaction patterns — if your design vision fights the platform every step, headless gives you total control. The template restrictions are gone.
Case 3: One catalog, many channels
Selling the same products on web, mobile app, in-store kiosk, branded marketplace, and partner channels? The headless API model lets all five consume the same catalog without redundant data. Traditional commerce makes this painful.
Case 4: Content and commerce in one frontend
A brand built on storytelling — journals, lookbooks, case studies, editorial — that also sells. Traditional platforms have shallow content tools; headless lets you combine a real CMS (Webflow, Contentful, Sanity) with commerce in one frontend experience.
4. The three cases where it isn't worth it
Case A: Sub-$100K/year stores without a specific problem
If the store works, the templates fit, and the volume doesn't demand it — the $10-15K headless setup cost is a tax on vanity. Stay traditional. Revisit the question only when one of the four cases above becomes real.
Case B: Heavy reliance on theme-injected apps
If your store depends on 10+ apps that inject UI (popup builders, page builders, upsell widgets, recommendation engines), most will break headless. Replacing them costs more than the headless project itself.
Case C: No engineering capacity
Going headless without an in-house developer or a long-term agency relationship is a recipe for stagnation. Traditional templates are designed for non-engineering teams; headless is not. If you can't maintain it, don't build it.
5. What breaks when you go headless
- Native theme editor — gone. Changes ship via your codebase.
- Most third-party apps that inject UI — broken. Recommendation widgets, popup builders, upsell tools.
- Native page builders — useless. You'll rebuild marketing pages in the new frontend.
- Theme-level SEO — rebuild meta tags, sitemaps, structured data, redirects.
- Checkout customization — depends on platform. Wix and standard Shopify lock the checkout; Shopify Plus allows it.
- Account pages — rebuild from scratch on most platforms.
- Email templates — Wix/Shopify still send their default order emails; replacing them needs more work.
Plan for 2-3 months of rebuilding peripheral systems, not just the storefront. Teams that underestimate this stage are the ones that regret going headless.
6. How to decide
- Identify the specific problem. Vague "we want a better site" is not a reason to go headless.
- Estimate the true cost. Setup + 3 years of hosting + bridge + maintenance + peripheral rebuilds.
- Check feasibility. Which apps break? Can your platform's checkout be customized? Who maintains it long-term?
- Run a 4-week pilot. Build the PDP on a headless frontend. Measure performance and validate the cost estimate before committing.
If the pilot answers all four questions positively, build it. If it surfaces unknowns you weren't expecting, that's the answer — going headless would have surfaced them later for 10× the cost.
7. Frequently asked questions
What is headless commerce in plain English?
Traditional commerce ties the storefront (what shoppers see) to the backend (catalog, cart, checkout) — change one, you touch both. Headless decouples them: the backend still manages products and payments, but the storefront is a separate frontend (usually React) that talks to the backend over APIs. You can redesign the store without touching commerce logic.
Is headless commerce worth it for a small store?
Usually not. If your store is under $100K/year, native themes work fine and going headless adds engineering cost without proportional gain. The exception: you already have a design or performance problem the native theme can't fix. Then headless is the answer to a specific problem, not a checkbox.
How much does it cost to go headless?
For a typical $250K/year store: $8-12K engineering setup + ~$50-100/mo recurring (hosting + bridge layer) + ~$3K/year maintenance. Compare to ~$50/mo for a traditional store. The 3-year cost difference is roughly $15-25K — meaningful for small stores, trivial for stores doing >$1M/year.
What are the real benefits of going headless?
Three concrete benefits: (1) Real performance — Lighthouse 90+, 1s LCP, no theme bloat. (2) Total design control — no template constraints, custom interactions, unique brand experience. (3) Future-proofing — frontend and backend evolve independently, redesigns don't require migration. Plus optional fourth: multi-channel from one catalog (web + mobile app + kiosk).
What breaks when you go headless?
Native theme editor — gone. Most third-party apps that inject UI — broken. Native page builders — useless. SEO and redirects — you rebuild them. Checkout customization — depends on platform (Shopify Plus only). Email templates, blog system, account pages — often need rebuilding. Plan for 2-3 months of rebuilding these, not just the storefront.
Can I go headless without losing my checkout?
Yes — the standard pattern is "headless storefront, hosted checkout". Your custom React storefront drives discovery and cart; at checkout you redirect to the platform's native checkout URL (Wix, Shopify, etc.). This avoids PCI scope, keeps fraud detection working, and is required by some platforms' terms of service. Trama uses this pattern by default.
Is composable commerce the same as headless?
No, but related. Headless = decoupled frontend + backend. Composable commerce = the backend itself is decoupled too: separate vendors for catalog, search, payment, fulfillment, etc., stitched via APIs. Composable is the natural extension of headless for enterprise scale. Most teams should not start composable — start headless, decompose later only if needed.
Pilot it in five seconds.
Paste your store URL on the homepage and Trama renders your products through a Next.js frontend. The fastest way to validate whether headless is worth it — before writing a single line of code.