Headless or Not: The Real Question for a Catalogue That Changes Every Day

Your catalogue manager changes a price before lunch. By the afternoon, the product page shows the new amount, the search result shows the old one and the checkout shows something else. The architecture discussion suddenly becomes practical: which system owns that price, and how does an edit reach every place a buyer sees it?

A frequently changing catalogue does not automatically require headless commerce. Nor does an integrated platform guarantee consistency. The decision should follow the publishing workflow, the places data is cached and the team's ability to operate the proposed system after launch.

Start with a real update, not a technology preference

Choose an ordinary product change and follow it from the person making the edit to a completed customer order. Include product details, variants, prices, stock, search listings and any connected sales channels. The slowest or least reliable step is the problem to solve.

Ask the catalogue team to demonstrate its current process. They may reveal that the delay comes from supplier spreadsheets, missing approvals or duplicate data entry rather than the website itself. Replacing the storefront cannot repair an unresolved source-of-truth problem upstream.

Capture how often each field changes. Stock may change continuously while specifications change a few times a year. Treating every field as equally urgent can create unnecessary operational cost; treating every field as static can leave buyers looking at obsolete information.

Understand the separation you are buying

In a headless arrangement, the customer-facing storefront is built separately from the commerce backend and communicates through supported interfaces. Shopify describes headless options that use its commerce services with a custom frontend. That describes an architectural boundary, not a guarantee of speed, lower cost or easier content operations. Shopify headless documentation.

An integrated storefront keeps more of the presentation and commerce workflow together. It may offer a simpler editing and preview experience for the team, although the result depends on the platform and extensions. Compare actual workflows instead of assuming either label settles the question.

The commercial tradeoff is responsibility. With a separate frontend, ask who maintains it, updates its dependencies and investigates failures between systems. If the answer is an unnamed future developer, the proposal has transferred work without explaining how the business will handle it.

Check whether a price change requires a deployment

A headless store does not inherently need a full rebuild whenever a price changes. Different implementations fetch or refresh data in different ways. Require the supplier to show the chosen behaviour rather than arguing from a generic diagram or framework description.

Time an edit through the proposed prototype. Check the product page, category grid, search results, promotional panel and basket. Use a fresh browser as well as one that visited before the change. Ask what causes each view to refresh and what happens if that signal is missed.

Set an agreed freshness requirement for each field. A marketing description may tolerate a short delay; an order total must be checked against the authoritative current rules before payment. State those requirements in the brief so the design can be judged against business needs.

Illustrative concept.

Separate stock availability from merchandising copy

Catalogue publishing and inventory control are related but different jobs. A revised photograph should not be allowed to overwrite stock data. Similarly, a stock feed should not erase carefully edited descriptions because the integration sends an incomplete product record.

Define ownership at field level. Name the system that supplies stock, the person approving technical specifications and the tool used for promotional copy. Where two sources can write the same field, decide which wins and how a conflicting update becomes visible.

Test an unavailable item while someone has it in their basket. The store should explain the changed availability before attempting an order under obsolete assumptions. The exact reservation policy belongs to the business and platform configuration; it should be demonstrated rather than left implicit.

Ask the editor to use the preview

A fast technical demonstration can hide an awkward publishing experience. Ask the actual editor to change a product image, review a mobile page and schedule a promotion using the proposed tools. Observe where they need developer help or copy information between systems.

Preview should make its limits clear. A product page preview may not represent search results, recommendation cards or a market-specific checkout. List the surfaces that require separate checks, particularly where different systems compose what appears to be one coherent storefront.

Check unpublished information as well. Draft prices, embargoed products and private supplier documents should not become public simply because a preview URL exists. Agree access controls for the staging environment and review the permissions of integrations that can retrieve draft content.

Test failure, not only successful synchronisation

Imagine the catalogue update succeeds but the search index refresh fails. Can the team see that discrepancy? Who receives the alert, and how do they retry safely? A queue that silently accumulates failed updates leaves a polished storefront with increasingly unreliable information.

Ask for a failed update to be demonstrated in a safe test environment. The team should be able to identify the affected products and the last successful update. A single green integration status is not enough if individual records can be rejected without explanation.

Then test recovery. Replaying an update should not create duplicate products or overwrite a later correction. Ask the developer to explain the ordering and duplicate-handling rules in terms an operations manager can use during an incident, without requiring them to read source code.

Price the operating model as well as the build

Compare proposals over the same period and scope. Include frontend hosting, commerce subscriptions, search services, content tools, monitoring, support and routine maintenance where relevant. Do not assume that an omitted line is free; ask whether it is included, optional or owned elsewhere.

Request a responsibility list for common incidents. Examples include a stale price, a broken product page after an API change and an editor unable to preview tomorrow's launch. The useful comparison is who can restore the workflow and what support arrangement covers that work.

Consider the team's staffing reality. A store with one part-time catalogue editor may value a single administration interface more than extensive frontend freedom. A business publishing across several distinct channels may have a stronger reason to separate presentation, provided it can maintain the integration.

Run a small catalogue trial before committing

Use a representative sample rather than the easiest five products. Include variants, unavailable items, a product with long specifications, a promotion and an item sold in more than one market. These reveal editing and consistency issues that a single-product demo can conceal.

For a hypothetical spare-parts supplier, the decisive trial might be a morning availability update across hundreds of variants. Compare how many manual steps remain, which errors are visible and whether checkout uses the correct available item. Do not confuse a faster homepage with a successful catalogue workflow.

Record the trial's constraints. A small sample can demonstrate behaviour, but it does not establish performance at the full catalogue size. If scale is material, include an appropriately sized test and describe the limits of the environment used to run it.

Make the architecture decision from the evidence

Choose the simpler arrangement that satisfies the proven requirements. A separate frontend can be justified by distinctive customer experiences or multiple channels, but daily editing alone is not sufficient evidence. The integrated option deserves the same practical trial instead of dismissal as less modern.

Bring the traced update and trial results to an ecommerce development discussion. Ask the proposal to connect each architectural choice to a specific publishing or buying requirement. The deliverable is a store the team can keep accurate, including the days when an update fails.