Commerce as another consumer of your ledger
The storefront is a channel. The stock position, the order record and the money all live in the operational systems.
Catalogue
One product record with channel-specific attributes, pricing and media, published outward rather than maintained twice.
Checkout
Cart, tax, shipping and payment, with stock reserved at the moment of order rather than at the next export.
Marketplaces
Listing, availability and order synchronisation with the marketplaces you already sell on, as events not files.
Money
Orders, refunds, fees and settlements matched per day, with unmatched items as a work queue instead of a variance.
When you should not go headless
Headless is a means, not a goal. Three situations where a hosted platform is the better answer.
A standard catalogue and one channel
If a hosted platform fits your product model and you sell through one storefront, headless adds cost and no capability.
No engineering capacity
Headless means owning a codebase. Without someone to maintain it, a hosted platform serves you better.
Speed to launch matters most
If the priority is trading next month, launch hosted and revisit the architecture once the operation is known.
The real problem is upstream
If stock accuracy is the issue, a new storefront will not fix it. The warehouse comes first.
Headless commerce, asked on most first calls
Because the data model is open and extensible, so the storefront can read your real stock position rather than a synchronised copy. If you do not need that, you probably do not need Medusa.
Yes. The integration layer is built as its own component, so the commerce side does not care which ERP sits behind it.
Either your team or ours. Headless means the storefront is a separate application, which is exactly why the seam between it and the operation matters more than the framework.
As channels with their own listing and availability rules, reading the same stock position, with orders arriving as events on the same order record.
We usually build the reconciliation report before the storefront integration, because it is the only thing that proves the integration is correct.
This page names a platform because that is what people search for. The capability page describes the work platform-independently.
ERP implementation checklist
The decisions that determine whether a rollout lands, most of which come before anyone configures anything. Readable in full, no email required.
