About4 min read
Headless CMS Or Headless Commerce? You Probably Need Both
They get talked about as competing choices and they are not. One rule about where each kind of data lives prevents almost every expensive version of this mistake.
By Juan Molina
On this page
A headless CMS and a headless commerce backend get talked about as if they are competing choices. They are not. They solve different problems, most serious stores end up with both, and confusing them produces a specific kind of expensive mistake.
What each one is actually for
A headless CMS manages content: pages, articles, landing pages, banners, brand storytelling, whatever a marketing team writes. It gives non-technical people an editing interface and delivers the result over an API.
A headless commerce backend manages transactions: catalog, stock, carts, checkout, orders, customers, refunds.
The distinction is not content versus commerce, because a product description is content. The useful line is different: does being wrong cost money immediately?
A typo in a blog post is embarrassing. A price that is wrong, a stock number that is stale, an order that exists in one system and not another: those are money, and they belong in the system that owns the transaction.
The mistake in each direction
Putting commerce data in the CMS. Somebody decides products should live in the CMS because marketing wants to edit descriptions. Now price and stock exist in two places, a sync runs between them, and the storefront sometimes shows a price the checkout disagrees with. Customers notice that immediately and it is the worst kind of bug, because it is visible and it is about money.
Putting content in the commerce backend. Less catastrophic and still a mistake. Commerce backends have thin content models, usually a description field and maybe a rich text editor. A marketing team trying to build a campaign landing page in that will produce something bad and will not be able to preview it, schedule it, or roll it back.
How they actually fit together
The pattern that works is a clean ownership split, and a storefront that queries both.
Commerce owns: SKU, price, stock, variants, physical attributes, orders, customers, everything transactional.
CMS owns: editorial copy, imagery for campaigns, landing pages, articles, navigation and merchandising decisions, anything with an approval workflow.
The join: content references products by identifier, never by copying their data. A CMS entry for a campaign page holds a list of SKUs. The storefront asks the commerce API for the current price and stock of those SKUs at render time.
That one rule prevents almost every version of the problem. Content points at products. Content never contains products.
The product description itself is the genuine grey area, and either answer works as long as it is one answer. Descriptions in the CMS if a content team owns them and wants workflow; descriptions in the commerce backend if they are closer to specifications and change with the product. What does not work is both.
Do you need a CMS at all?
Honestly, plenty of stores do not, and adding one is a real cost: another subscription, another system in the render path, another place things can be out of date.
You need one when non-technical people need to publish without a developer, when content needs review and scheduling before it goes live, when you are running campaigns with their own pages regularly, or when you publish in several languages.
You do not need one when a developer edits content anyway, when your content is a handful of static pages, or when your product pages are the only pages that matter. Files in your repository are a perfectly respectable content system for a store whose content does not change weekly.
The practical questions when choosing one
Can it model a reference to an external product, so content can point at a SKU? Does it give editors a preview of the real storefront rather than a generic one? Can it schedule and roll back? How does it deliver images, because product and campaign imagery is most of your page weight? And what does the API cost at your traffic, since some charge per request in a way that surprises people at scale.
Where we fit, and where we do not
dashfordevs is the commerce half. Catalog, carts, checkout, orders and customers behind an API, with no opinion about your storefront, which means it sits beside a CMS rather than competing with one. Your storefront queries both and joins them at render.
There is a content layer in the platform, and it is honestly scoped: enough for pages, posts and merchandising blocks attached to commerce data. If you have a content team that needs workflow, approvals, localisation and a proper editorial experience, a dedicated CMS is better at that and we are not pretending otherwise.
Where we are the wrong answer: if content is your product and commerce is a small attachment, start from the CMS side and add commerce. If you want one system for everything with an interface for both, a hosted platform bundles them and that is a legitimate reason to pick one.
The short version
Commerce owns anything where being wrong costs money. The CMS owns anything with an editorial workflow. Content references products by identifier and never copies their data.
Get that boundary right and both systems are easy. Get it wrong and you will spend years reconciling two copies of your catalog.
