Headless or monolith for a large catalog? How to decide

If your catalog is large enough that product data already lives outside the platform, go headless: own the storefront and the index, and keep the platform for cart, checkout, and orders. If your catalog fits comfortably in the platform admin and your team is small, stay on the monolith. The deciding factor is not traffic, brand, or budget. It is where the truth about your products lives.

The question people ask, and the one that matters

The headless conversation usually starts with the storefront: performance, design freedom, a framework the team prefers. Those are real, but they are not the reason a large catalog goes headless. The reason is that the platform’s product model is already a lossy copy of the catalog, and building the storefront on that copy means building on the weakest data you have.

So the question is not “do we want a custom storefront”. It is “what should the storefront read from”. Once the answer is “an index we own, fed from the ERP and the PIM”, headless follows, because the platform is no longer in the read path.

Stay on the monolith if

• Products are edited in the platform admin and that is the truth
• Attributes fit the native model without more than a couple of extensions
• Native search or a hosted plugin is good enough for the catalog
• One channel, or feeds that work from the platform’s own export
• No developers on staff and no agency you trust with a codebase

There is no prize for going headless when the monolith fits. It costs more to run and it moves work onto your team.

Go headless if

• Product data is authored in an ERP, a PIM, or supplier feeds, and the platform is synced from them
• You have already replaced native search, or you are about to
• Fitment, compatibility, units, or account-specific pricing are part of the catalog
• More than one channel needs enriched attributes the platform does not hold
• You expect to change platforms within five years and want the catalog to survive the move

What headless means for a large catalog

It does not mean “the same platform, with a React front end”. For a large catalog it means the storefront reads product, category, search, pricing, and availability from the index, and reads nothing product-shaped from the platform at all. The platform’s product API becomes a sync target that receives the checkout-shaped slice, and the platform’s job narrows to what it does well: cart, payment, tax, fraud, and orders.

That narrowing is the point. Headless is turning platforms into checkout companies, and for a catalog-heavy merchant that is the right outcome.

The trap: headless inside the platform’s own ecosystem

Every major platform now offers its own headless framework and hosting, and presents it as the safe way to go headless. It keeps the storefront tied to the platform’s product model and the platform’s API limits. You take on the cost of a custom storefront and keep the constraint that made you want one. If the platform is not the system of record for your products, its headless framework should not be the foundation of your storefront.

What it costs

Less than it did five years ago, by a lot. Storefront frameworks are mature, and AI-assisted development has turned a working storefront against an index into weeks of work rather than months. The expensive part of a large-catalog build was never the storefront; it is the product data, and that cost is the same whether you go headless or not. The breakdown is in what drives the cost of a large-catalog build.

A decision checklist

1. Where is product data authored today? If not the platform, headless.
2. Do you already run a separate search index? If yes, the storefront should read from it.
3. Are there attributes the platform cannot model? Each one is a vote for owning the index.
4. How many channels read the catalog? More than two, the index pays for itself.
5. Who will run it? No engineering capacity at all is the one hard reason to stay.

The rest of the series is at ecommerce for large catalogs.