What drives the cost of a large-catalog ecommerce build

The storefront is not what drives the cost of a large-catalog ecommerce build. Product data is: getting it out of the systems that hold it, making it consistent, enriching it, and keeping it that way as sources change. For catalogs of tens of thousands of SKUs, storefront and checkout are a minority of the budget and shrinking. Data integration, search, and pricing are the majority and growing. A quote dominated by front-end hours means nobody has looked at your catalog yet.

Where the money goes, in order

1. Product data integration. Every source is a project: the ERP, the PIM, each supplier feed, the spreadsheet with the fitment data. Each has its own shape, its own refresh cadence, and its own failure modes.
2. Attribute normalisation and enrichment. The same attribute has three names across four systems. Units differ. Fitment is trapped in PDFs. Making this consistent is the single largest line item in most builds, and the one most often left out of the quote.
3. Search and retrieval. Modelling the index against the real catalog, relevance tuning, synonyms, part-number handling, faceting that performs at scale.
4. Pricing and availability. Contract pricing, tiers, and multi-warehouse stock, either synced from the ERP or fetched at request time. Simple for a DTC brand, a project of its own for B2B.
5. Storefront. Category, product, search, and account pages. Real work, but the most commoditised part of the build and the part AI-assisted development has compressed most.
6. Checkout and payments. Mostly bought, not built. Payments, tax, fraud, and wallets from a platform or a checkout provider.

What makes it more expensive

• Number of sources. Three ERPs from acquisitions cost more than one, and not linearly.
• Attribute inconsistency. Every field that means something different in two systems is a decision someone has to make.
• Fitment or compatibility. A relationship between products, or between a product and something the customer owns, is a data model of its own.
• Account-specific catalogs and pricing. Each rule the sales team has negotiated has to be expressible.
• Number of channels. Each one wants a different shape of the same catalog.

What makes it cheaper

• Integrate once, read many. An index that every surface reads from means each source is integrated one time, not once per channel and once per tool.
• Buy checkout. There is no reason to build payments, tax, or fraud. That is the layer platforms do well.
• Let the storefront be cheap. With a good index underneath it, a storefront is a well-understood problem, and a developer working with a coding agent can stand one up in weeks.
• Do not re-platform the catalog. Migrating product data into a new platform’s model, then extending that model, then syncing it, is the most expensive path and the one most agencies will quote by default.

The cost that is not in the quote

Every sync job is a recurring cost. Every extension has an upgrade path someone will pay for. Metered search bills grow with traffic and with catalog size, and the meters bite in year two rather than in the proof of concept. And a catalog that lives inside a platform’s model is a catalog you will pay to migrate again at the next replatform. The build quote is the smaller number. The five-year number is the one to ask for.

How to get a real number

Count your sources, your SKUs, your channels, and the attributes the platform cannot hold today. Those four numbers predict the cost of a large-catalog build better than any feature list. Send them to us through the contact page and we will tell you what an index-first build would cost, including when the honest answer is that your current platform is fine.

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