You are not picking a framework here, you are picking where a boundary sits. Going headless hands you the storefront, its performance and its design, and hands you the maintenance the platform used to absorb quietly. What follows: what actually moves to your side, what the commerce engine should keep, how to migrate without a big bang, and when the honest answer is to stay on the monolith.
What decoupling actually moves onto your side of the line
Headless means the storefront talks to a commerce engine over an API instead of being rendered by that engine's theme layer. In practice you take ownership of three things the theme used to hold: routing and rendering, cart and session state, and cache correctness. Routing is the easy part. Cart state is where teams get surprised, because the cart lives on the engine: every add, quantity change and discount application is a network round trip, and your UI has to choose between optimistic updates that need reconciling and a button that blocks and feels slow. Cache correctness is what bites in production. A product page cached at the edge is fast until the price changes or the last unit sells, and then you need webhooks from the engine to invalidate exactly the right paths, plus a fallback for the webhook you will eventually miss. The usual compromise is to cache the page shell, copy and imagery aggressively, read price and stock at request time or from a very short lived cache, and accept a little client work on the parts that genuinely change. None of this is exotic. It is code you now own, review and upgrade for as long as the store exists. That is the real trade: the platform stops making decisions for you, in both directions.
Everything the monolith handed you, now priced in engineering time
A theme quietly ships a lot of product. Site search with facets, for one: platform search comes with the plan, while a custom front either leans on the API's limited filtering (fine at a few hundred SKUs, painful past a few thousand) or adds a hosted search service, usually billed per record and per search operation, so it scales with catalogue and traffic. Then there is content preview for whoever runs merchandising, promotion logic with its stacking rules and exclusions, and the long tail of checkout: strong customer authentication in Europe, address validation, destination based tax, fraud rules, gift cards, partial refunds. Finally, the admin screens nobody budgets for: bulk edit, order search, refund UI. The way this stays sane is to keep a real commerce engine as the backend and only replace the front. With Shopify's Storefront API you build the cart in your own UI and then hand off to their hosted checkout, which keeps payments, tax and fraud out of your codebase (deep checkout customisation is an enterprise tier feature at the time of writing, so plan around the hosted flow rather than against it). Commercetools, BigCommerce and Medusa make the same bargain with different edges. Be explicit about which of these you intend to rebuild, because the gap between a custom storefront and a custom commerce platform is about a year of engineering.
Where the speed actually comes from, and what quietly gives it back
On a product page the largest contentful paint is almost always the hero image, not the framework. Headless helps because you control the image pipeline (correct sizes attribute, modern formats, priority hints on the one image that matters, no 2000px JPEG scaled down in CSS), you control how much JavaScript ships, and you can render on the server close to the visitor. What it does not do is protect you from yourself. A decoupled storefront loaded with a tag manager, a consent banner, a chat widget, a reviews embed and two analytics scripts is not faster than a well built theme, it is a well built theme with extra steps and a bigger bill. Interaction latency is the other trap: cart state held client side, re-rendered on every keystroke in a quantity field, will regress your interaction metrics no matter how clean the initial load looked. Two habits keep projects honest. Measure with field data from real visitors rather than a lab score on an empty cart, and put a size budget on third-party scripts, because it is the lever with the best return for the effort. Be sceptical of anyone selling speed as a ranking trick. The defensible case is that a fast, stable storefront removes friction from the buying path and makes large catalogues cheaper to crawl.
Migrating route by route, with checkout left alone until last
The big bang rewrite is how these projects die. The workable pattern is a proxy in front of the domain that routes path groups to either the old storefront or the new one, so migration becomes a sequence of reversible steps. Order it by risk: content routes first (home, category listings, editorial, landing pages), then product pages, then cart, and leave checkout on the platform, possibly forever. The URL inventory decides whether this succeeds. Export every indexed URL from Search Console, every URL in the sitemaps and every URL with inbound links, map each one to a destination, and treat an unmapped URL as a defect rather than a rounding error. What actually breaks is mundane: redirect chains three hops deep, trailing slash rules that changed, canonical tags pointing at the old host, faceted parameters that used to be handled and now are not. Structured data needs re-emitting server side, since Product and Offer markup vanishes with the theme that generated it and nobody notices for weeks. Keep both fronts live through the cutover with a per-route switch, so a bad deploy is a proxy flip rather than an outage. Keep the same analytics identifiers and consent behaviour too, or you lose the baseline exactly when you need it to prove the migration worked.
When headless is expensive theatre, and when we are the wrong team
If your catalogue runs to a few hundred SKUs, your traffic is moderate, and your store is slow because of a dozen apps and unoptimised images, headless is theatre. Strip the scripts, fix the images, update the theme, keep the money. If your marketing team publishes landing pages themselves in a visual builder, a custom front takes that away unless you also fund a CMS with proper editing, and the hidden cost is the queue that forms in front of your one developer. If you depend on a shelf of platform apps for subscriptions, loyalty, upsells or reviews, know that most of them work by injecting themselves into the theme and simply do not exist on a custom storefront: you rebuild them, replace them with an API-first equivalent, or drop them. If the real bottleneck is operational (stock accuracy, fulfilment delays, an ERP that answers in twelve seconds), a faster front end changes nothing you care about. And about us, plainly: we are two people in Dijon, Robin Monteiro building, Florian Loppion on the marketing side. If you need round-the-clock incident cover under a contractual response time, four workstreams running in parallel, or somebody physically in your office, hire a larger firm. We will tell you so rather than take the project. We fit when one focused pair can own the storefront end to end and answer for it.
How a two-person French team works with a store in London or Austin
Everything happens in writing, by email. No calls, no video, no scheduled slots, and not as a concession: it is the method. For an international client it removes the constraint that makes remote work miserable. A founder in California never takes a 3am call and never waits for Dijon to wake up, because the answer is already written. We reply within 24 business hours. What you get from that is an archive: every decision, every trade-off, every option we rejected and why, sitting in a thread you can search a year later when a new developer asks why the cart is server-authoritative. There is a real cost on your side, so here it is. Write the brief instead of talking it through. Batch questions into one message rather than sending six across a morning. Nominate one person who owns decisions, because asynchronous work falls apart with a committee. Give access rather than permission (repository, commerce engine, DNS, analytics) so nothing stalls waiting on a credential. Reviews happen on a staging URL, numbered comments against numbered items. You own the code, the accounts and the domain from the first day, there is no compulsory subscription, and pricing is on request, quoted per project. Past work includes Chouchou Ribeyre, Au Petit Detail, LB Athletic, Mediavocats and Vectosolve, all French SMEs.
