Headless or Built-In? Choose the Storefront You Can Operate

A retailer has one website and 3,000 products. At Monday’s planning meeting, someone asks for an app like a competitor’s. An agency proposes a new headless website. Before choosing a framework, the operations manager asks: do we need a different website, a new app, or a better shopping journey on the one we already have?

This is a teaching scene, not an observed customer outcome. Headless can be the right choice for a single website; several channels do not automatically make it profitable. The decision rests on a valuable capability, an operable design and an owner who will still support it in year three.

Start with ownership, then define the architecture

A coupled or built-in storefront is supplied and maintained as part of the commerce platform. It can still have APIs, background workers, CDNs and several deployment components. It is not necessarily one process, one server or a closed theme with no customisation.

A headless storefront is a separately operated presentation application that uses commerce interfaces. The engine may still supply a built-in storefront or hosted checkout; “headless” does not prove every required action exists in its API. A hybrid keeps the built-in experience for some journeys while adding a separate app or selected experience over the same core.

Composable commerce means selecting and integrating capabilities; it does not require a different supplier for every feature, nor automatically require microservices or one specific hosting model. Each additional service brings contracts, identity, observability and failure handling to evaluate.

For each option name who owns merchandising, preview, accessibility, translations/RTL, privacy/consent, analytics, SEO, extensions, security patches and out-of-hours incidents. Tools may supply these capabilities in either model; neither “all free in a theme” nor “headless must build everything from scratch” is a fair assumption. An agency can be a responsible long-term owner if the contract, access, exit plan and support capacity are real.

Compare the same work over the same period

The table is an invented annual operating budget in one currency unit, not a vendor quote, salary survey or StoreConsole price. Both options include maintenance and QA/security. Common commerce-engine costs are excluded only on the assumption they are identical; include any differences in your own model. Avoid counting the same staff time twice.

Annual operating line	Built-in	Separate frontend
UI maintenance and support	24,000	54,000
Hosting and CDN allocation	6,000	12,000
QA, accessibility and security	8,000	18,000
Preview, analytics and localisation	4,000	12,000
Total annual operating	42,000	96,000

Assume an additional one-off build/migration cost of 20,000 for the built-in approach and 80,000 for the separate frontend. Annual operation totals 42,000 versus 96,000: an extra 54,000 each year. The three-year undiscounted totals are 20,000+3×42,000=146,000 and 80,000+3×96,000=368,000, a difference of 222,000.

With an illustrative 25% incremental contribution margin, annual additional sales of 54,000÷0.25=216,000 cover only the extra recurring cost. Spreading the additional 60,000 initial cost across three years adds 20,000 yearly: 74,000÷0.25=296,000 annual extra sales to cover that simple three-year comparison. This is not a forecast, cash-payback date or guarantee.

Contribution must deduct all relevant variable costs, including goods, payment, fulfilment and expected returns/support; it is not merely gross margin. Model discounts, demand uncertainty, financing/tax effects and any non-sales benefit separately. Shared API work can be reused, but four channels do not make the total bill one quarter: each still needs design, testing and operations.

Keep commerce authority behind every screen

Audit the actual journey: variants, customer-specific prices, currencies, availability, cart changes, shipping, tax, discounts, payment methods, orders, returns and account access. A catalogue-only API is insufficient for a full shop. Check versioned contracts, rate limits, extension coverage, errors and backward compatibility with the exact enabled modules you need.

The frontend can display a quote and collect intent; the authoritative engine validates permissions, current rules and the approved total. Do not duplicate inventory reservation, tax or discount policy in every app. Cached prices and displayed availability are not final authority to accept an order. When the basket or terms change, obtain the required new confirmation.

OWASP authorization guidance applies at each request and object boundary. Hiding a button, knowing an order ID or being logged in does not grant access to another customer/entity. Keep privileged secrets out of the browser. Separate public caching from account/cart/quote responses and include all relevant market, currency and permission variation in the cache design.

A return from the payment screen is not proof of payment. Stripe’s fulfilment guide illustrates server-side confirmation and duplicate-safe handling; the provider’s actual payment state and asynchronous methods still matter. Preserve operation identity, query an unknown result before repeating collection, and recover transient failures with bounded backoff plus an owned exception. Falling back to another frontend must not create a second order or charge.

Measure the experience instead of assuming a speed label

Good Core Web Vitals targets are LCP≤2.5 s, INP≤200 ms and CLS≤0.1 at the 75 th percentile, assessed separately for mobile and desktop. A lab Lighthouse score is not the same as these field measurements. No architecture label proves either will pass.

Server rendering and static generation can reduce browser work, but slow origin responses, images, fonts, hydration and third-party code still matter. INP includes input delay, event processing and presentation work, not only framework JavaScript. Edge caching can shield public reads in either model; checkout writes and private state still need capacity and correctness.

Google’s JavaScript SEO guidance explains crawling and rendering. Provide useful content, crawlable links, appropriate status codes and consistent metadata; inspect rendered product data, canonicals, translated routes and structured data. Rendering HTML on a server is not an indexing or ranking guarantee.

Budget real hosting and release work. For example, Next.js self-hosting documentation covers coordinated multi-instance caches/builds and version skew. A separate frontend requires compatible API/UI changes, invalidation, monitoring and recovery ownership; built-in storefronts also need disciplined releases and testing. Marketing preview and component extensions should be demonstrated by the people who will use them.

Choose from evidence, not a frontend count

The decision table names experiments rather than declaring a universal winner. A specialised configurator can justify a separate single website; a mobile app can coexist with the built-in web shop. Traffic peaks alone do not decide, because cache misses, writes and shared dependencies remain.

Need	Useful comparison/test
Standard shopping journey	Improve current storefront versus alternatives
An app or partner channel	Hybrid over shared engine versus replacing the website
Distinctive single-site experience	Prototype the missing capability; assess API/lifecycle cost
Frequent marketing changes	Let editors demonstrate preview and publishing
Large traffic peaks	Measure cold-cache and write-path/failure capacity
Limited delivery capacity	Require credible maintenance/support ownership in every model

Compare a repaired current storefront, a focused hybrid and a separate frontend against the same business outcome. If image weight or an upstream stock error is the actual problem, identify that repair directly. It may be cheaper to fix, but do not invent a guaranteed conversion improvement or a fixed number of weeks.

A useful supplier review starts with the module and capability map and ends with a working acceptance journey. Ask for feature coverage, maintainers, support and an exit/export plan. A claim of “one backend” does not by itself prove both storefronts behave alike.

Migrate with a compatible return path

Record a baseline and an acceptance goal before building. Test product and account journeys, keyboard/accessibility behaviour, translations/RTL, mobile performance, tax/price display and analytics with consent. Keep the authoritative commerce engine shared; avoid two live write paths with competing rules.

An isolated read-only page can be a sensible pilot, but page-by-page is not always the safest boundary. Cart identity, cookies, authentication, redirects and payment callbacks cross pages and domains. Choose a coherent journey and stable traffic cohorts, with monitored stop conditions; a random percentage is not a safety guarantee.

Preserve useful URLs where possible. When URLs change, follow Google’s site-move guidance for mappings, permanent redirects and monitoring. Keep redirects at least a year where applicable, preferably longer for users, and do not send unrelated old pages to one generic destination. Validate metadata/sitemaps and crawl behaviour before and after the move.

Exercise rollback with existing carts, order references, active sessions, deployed schema/API versions and in-progress payments. Returning to the old UI is only safe while those contracts remain compatible. It cannot undo a payment already taken or erase a new order. Reconcile outcomes and unfinished obligations rather than blindly replaying them.

Retire the old route after evidence covers representative trading conditions and recovery, not simply because launch day looked good. Keep a named support owner and the accepted cost model. At Monday’s meeting the useful answer is a demonstrated journey with a sustainable operating plan—not a framework name or a promise that every sales problem disappears.

Reviewed 6 November 2026. Anichur Rahaman, creator of StoreConsole. Costs and break-even arithmetic are illustrative, not prices, observed outcomes or financial forecasts.