Choosing the right stack for a headless storefront
Headless buys you freedom on the front end and a bill on the back end. How we decide when it is worth it, and what we reach for when it is.
Going headless means the storefront is yours to build and the commerce engine – products, carts, payments, orders – is someone else's to run, reached through an API. You get a fast, custom front end and complete control over the experience. You also take on the glue: search, cart state, checkout hand-offs, and every integration the platform used to give you for free with a theme.
When it is worth it
When the front end is genuinely part of the product. A catalogue in the thousands, where search and filtering are the shop. B2B pricing, where different customers see different numbers for the same item. Several languages and currencies from one codebase. Content and commerce woven together, so a guide about a problem flows into the product that solves it. Or simply a brand that cannot look like a template and has the traffic to justify caring.
Speed is often cited and is real, but it is the weakest reason on its own. A well-built theme on a modern platform is fast enough for most shops. Headless earns its cost when it unlocks something the platform's own front end cannot do at all.
When it isn't
A small shop that needs to be live next month, with a founder who will be editing the homepage themselves. A catalogue of fifty products. A team with nobody who can read a stack trace. In those cases headless is a way to pay more, wait longer and own a maintenance burden you did not need. We will say so, and we would rather lose the build than ship the wrong one.
The stack we reach for
Deliberately boring. A Next.js front end, because it renders fast, deploys anywhere and has an enormous pool of people who can work on it. A commerce platform with a mature, well-documented API and a real webhook system, because the integration layer lives or dies on those two things. A hosted search index rather than the platform's built-in search, once the catalogue passes a few thousand items. And a thin integration layer we own end to end, so when a supplier changes a feed format the fix is ours to make in an afternoon.
Boring is the feature. A small team has to keep this running for years, through platform upgrades and staff changes, and every clever choice made today is a debt someone pays later.
The part people forget
Operations. Who updates the product copy, and where? Who gets told when a webhook fails silently at two in the morning? What happens to the cart when the payment provider has an outage? A headless build that answers these questions on day one is a platform. One that doesn't is a very handsome demo. Ask them before you sign anything, including with us.