Headless is neither a scam nor a savior — it is a cost structure. The three-year arithmetic we walk shop owners through, including the line item every pitch omits, and the boring middle path that usually wins.
“Should we go headless?” is the wrong first question, but it is the one that arrives in our inbox, usually right after a conference talk or a very good agency pitch. The right first question is: what does each path cost over three years, in money and in shipped features? For stores under roughly ten thousand SKUs the arithmetic is surprisingly one-sided — just not in the direction either camp advertises.
Real things, really: total frontend freedom, the performance ceiling of custom server-rendered code, one backend feeding web and apps alike, independence from your platform's template politics. We build this way — our own store runs a custom frontend over plain PostgreSQL — and the craftsmanship argument is genuine. The catch: every benefit is a ceiling, not a floor. Headless lets you build a faster store than any theme; it does not make one happen. We have audited headless builds slower than the platform theme they replaced, because the budget ran out before the optimization began.
The line item every pitch omits. A monolith's ecosystem hands you discount codes, gift cards, tax edge cases, reviews, back-in-stock emails, loyalty points — decades of accumulated retail plumbing, one plugin away. Going headless means an API exists and the interface is your job. Each “small” feature is a week: days to build, forever to maintain. Ten such features is a quarter of engineering spent reaching the baseline your old theme shipped with on day one. Write down every capability your store uses today — the honest list runs 30 to 50 items — and price each at a week. That number, not the agency quote, is the real build cost.
Multiple channels sharing one catalog. Scale where platform fees cross six figures. A product whose experience is the differentiator — configurators, subscription logic no plugin imagines. An in-house engineering team that exists anyway. Notice these are business shapes, not technology preferences. If the growth plan is “sell more of the same catalog on the same site”, you don't have a headless-shaped problem — you have a speed and conversion problem, fixable for a tenth of the price. We wrote a whole piece about when not to rebuild; it applies double here.
The stack should be the least interesting thing about your store. No customer has ever asked what ours runs on; they notice that pages arrive instantly and paying is painless. Spend accordingly.