Choosing Your Composable Commerce Frontend: Hosted Frontends, Custom React, and Headless CMS Compared
The first big decision in a composable commerce build is the platform — Elastic Path, commercetools, BigCommerce, or one of the other established options. The second decision, made immediately afterward, is what builds the storefront. The platform supplies catalogue, pricing, customer, and order capabilities through APIs.
The storefront is a separate engineering investment that turns those APIs into a buyer experience. By the start of 2026 there are three serious approaches: a vendor-hosted frontend such as Elastic Path’s hosted PXM Storefront, a fully custom build in React or Next.js or Remix, and a headless CMS-anchored frontend that puts content management at the centre.
This article addresses the composable commerce frontend options compared question directly. It covers what each approach actually is, the decision factors that matter, the realistic time-to-market and total-cost-of-ownership profiles, and the archetypes where each approach is the right choice. It is the architectural decision guide we walk clients through inside McKenna engagements.
The Three Approaches in One Paragraph Each
Hosted vendor frontends. Elastic Path PXM Storefront and the hosted experience products from other composable platforms. Vendor-built, vendor-operated, configurable rather than custom-coded for the most part. Theme and component customisation is supported, but the underlying frontend is a managed product owned by the platform vendor.
Custom React, Next.js, or Remix builds. A storefront engineered specifically for the customer’s brand, calling the composable platform’s APIs directly. Maximum design and behaviour flexibility; maximum engineering investment. Hosted on the customer’s preferred infrastructure (Vercel, Netlify, AWS, Azure), with the customer’s preferred CI/CD, observability, and security posture.
Headless CMS-anchored frontends. A storefront where the content management system (Contentful, Storyblok, Sanity, Strapi, Prismic) is the orchestration layer. Commerce data flows from the composable platform; content (marketing, editorial, brand assets) flows from the CMS; the frontend renders both. Often built in Next.js or similar but with the CMS rather than the commerce platform as the primary content authority.
The three approaches sit on a continuum rather than as discrete points, and many real implementations blend them. The decision factors below help locate the right point for any specific situation.
Decision Factor 1: Time-to-Market
Hosted vendor frontends. Fastest. A configured hosted frontend can be live in weeks, not months. Catalogue setup is typically the critical path; the frontend itself is largely a configuration exercise. For organisations that need to be in market quickly — replatforming under deadline pressure, launching a new business unit, validating a market hypothesis — hosted frontends deliver.
Custom builds. Slowest. A custom React or Next.js build takes months from start to MVP, longer to production-ready quality. The time is spent on design, development, testing, performance optimisation, and the long tail of edge cases that only emerge in production. The time investment buys flexibility, but for organisations whose competitive advantage is something other than the storefront, the time is often poorly spent.
Headless CMS-anchored frontends. Middle. The CMS provides starter templates and component patterns that accelerate the work, but a substantial frontend build is still required. Typically two-thirds of the time of a fully custom build for equivalent quality.
For organisations replatforming from a monolithic platform under deadline pressure, hosted frontends or accelerated headless CMS builds are typically the only viable choices. Custom builds for replatforming are common but routinely run late.
Decision Factor 2: Design Flexibility
Hosted vendor frontends. Constrained. Theming, component swapping, and configurable layouts cover most retail-style storefronts well. Highly bespoke design — unusual interaction patterns, branded content treatments that fall outside the supported template variations, custom animation and visual storytelling — is harder. The hosted frontend is opinionated about the shape of an ecommerce page, and that opinion limits the design surface.
Custom builds. Maximum. Every pixel is in the customer’s control. The design language can be anything the brand requires. Interaction patterns can be tailored to the specific buyer journey. The trade-off is that all of the work to make the design exist is engineering work the customer is paying for.
Headless CMS-anchored frontends. High. Strong design flexibility because the rendering layer is custom; strong content flexibility because the CMS supports rich content modelling. The trade-off is that some of the design choices are constrained by the CMS’s rendering model — but the constraints are looser than a hosted frontend.
For DTC brands and luxury retailers where the storefront is the brand experience, custom builds dominate. For B2B distributors and industrial commerce where the storefront is more functional than expressive, hosted frontends are increasingly the right choice.
Decision Factor 3: Content Workflow Ownership
This is the decision factor most often overlooked at architectural review and most often complained about six months later.
Hosted vendor frontends. Content workflows are owned by the commerce vendor’s authoring surface. Marketing teams interact with the same authoring tools as catalogue managers. For organisations where commerce and content are tightly aligned and the same team owns both, this is a non-issue. For organisations where marketing and commerce are different functions with different tools — which is the more common pattern — the hosted authoring surface is a friction point.
Custom builds. Content workflow is whatever the customer builds it to be. In practice, a custom build without a CMS pushes content management into developer tooling, which marketing teams cannot use directly. Custom builds without a CMS therefore typically end up adding a CMS later, often in pain.
Headless CMS-anchored frontends. Content workflows live in the CMS. Marketing teams use authoring tools designed for marketing teams (Contentful, Storyblok, Sanity have well-designed editorial interfaces). Commerce teams use the commerce platform for catalogue and pricing. The two streams flow into the storefront separately and integrate at the page level. For organisations with separate marketing and commerce functions, this is the most natural model.
The unspoken truth: most B2B and B2C composable commerce builds eventually develop a CMS layer. Building one in from the start is cheaper than retrofitting it later.
Decision Factor 4: SEO and Performance
Hosted vendor frontends. Built with SEO and performance baked in. Page speed metrics are typically excellent (server-side rendering, edge caching, optimised image handling are all standard). SEO best practices are followed by default — semantic markup, proper canonicalisation, structured data. The work the customer would otherwise have to do themselves is done by the vendor.
Custom builds. SEO and performance are entirely the customer’s responsibility. With Next.js, Remix, or similar modern frameworks, the building blocks are excellent — server-side rendering, incremental static regeneration, edge caching, automatic image optimisation. The frameworks make it possible to build extremely fast storefronts, but it is possible only with disciplined engineering. Custom builds with insufficient SEO and performance investment routinely score worse than hosted frontends.
Headless CMS-anchored frontends. Similar to custom builds — capable of excellent SEO and performance, but only with disciplined engineering. The CMS adds an additional content fetching layer that can become a performance bottleneck if not carefully managed.
For SEO-critical storefronts where organic traffic is the primary commercial driver, the hosted frontend’s “good by default” posture is often better than a custom build’s “great if engineered well, mediocre if not.”
Decision Factor 5: Total Cost of Ownership
The full TCO picture spans initial build, ongoing development, hosting, and the long tail of operational maintenance.
Hosted vendor frontends. Lowest initial build cost. Modest ongoing licence fees. Vendor handles hosting, performance optimisation, and many infrastructure concerns. Primary ongoing cost is the configuration and theming work as the storefront evolves.
Custom builds. Highest initial build cost. Modest infrastructure costs (Vercel, Netlify, or similar starts cheap and scales linearly). Substantial ongoing development cost as the storefront evolves — every change is engineering work. Long-tail maintenance cost as frameworks evolve and dependencies need updating.
Headless CMS-anchored frontends. Middle initial build cost. Adds CMS licence cost (Contentful, Storyblok, Sanity all have meaningful per-environment pricing at enterprise scale). Lower ongoing development cost than custom because content changes flow through the CMS without engineering involvement.
A common architectural mistake is comparing initial build cost in isolation. The custom build that costs three times as much initially but produces equivalent buyer experience can be cheaper over five years if the content team can self-serve through a CMS rather than queuing tickets with engineering for every page change.
Decision Factor 6: Vendor Lock-In and Replaceability
Hosted vendor frontends. Highest lock-in. The frontend is not portable; replacing it means rebuilding. The vendor’s roadmap controls feature availability, and migration paths to other vendors are typically painful.
Custom builds. Lowest lock-in. The code is yours. Replacing the composable commerce platform requires rebuilding the integration layer but the frontend itself is portable.
Headless CMS-anchored frontends. Middle. The frontend code is portable; the CMS-specific content modelling carries some lock-in but CMS migration is generally tractable.
For organisations where the strategic risk of platform lock-in is significant — long-term commerce strategies, regulated industries with multi-decade architectural horizons — custom or CMS-anchored builds are usually the right choice.
Decision Factor 7: International and Multi-Storefront Complexity
Composable commerce often serves multiple storefronts: per market, per brand, per business unit, per channel.
Hosted vendor frontends. Multi-storefront support varies by vendor. Strong support for multi-locale and multi-currency configurations of a single brand. Weaker support for genuinely distinct brands operating against the same backend — though this is changing rapidly as composable platforms invest in multi-storefront capabilities.
Custom builds. Maximum flexibility. Each storefront can be its own application or a monorepo of related applications. Engineering effort scales with the number of storefronts.
Headless CMS-anchored frontends. Strong. Modern headless CMSs are explicitly designed for multi-brand, multi-locale content delivery. The same CMS can serve multiple storefronts with localised content streams, and the frontend code can be shared with brand-specific themes.
For organisations operating ten regional storefronts on shared backend infrastructure, the headless CMS approach typically scales most cleanly.
Three Worked Archetypes
The decision factors above are most useful when applied to specific situations. Three common archetypes:
Archetype 1: B2B Industrial Distributor
A B2B distributor with thousands of products, contract pricing per customer, bulk-order workflows, and a primarily functional storefront. The buyer experience is about getting the right product to the right account at the right price, not visual storytelling.
Recommendation: hosted vendor frontend, with selective custom development. Time-to-market matters; the design surface is largely functional rather than expressive; the catalogue management workflow is tightly integrated with the commerce data; SEO is moderately important but not the primary commercial driver. Hosted frontends with custom development for the bespoke B2B workflows (account hierarchy navigation, contract-aware pricing display, quote workflows) deliver the right balance.
Archetype 2: DTC Premium Brand
A direct-to-consumer brand selling premium products in a category where the storefront experience is materially the brand experience. Visual storytelling, bespoke product pages, content-rich brand journeys, and seasonal campaign capabilities are all primary capabilities.
Recommendation: headless CMS-anchored frontend, custom-built. Design flexibility is non-negotiable; content workflow ownership matters because marketing is the primary content driver; SEO and performance are commercially critical; the brand will not accept the design constraints of a hosted frontend. The CMS provides the marketing team’s authoring environment; the custom frontend provides the brand expression; the composable commerce platform supplies the catalogue, pricing, and order data.
Archetype 3: Multi-Region Enterprise B2B Manufacturer
An industrial manufacturer with ten regional storefronts, three brands, multiple currencies, complex catalogues, and a parent organisation that operates them as a portfolio. Each storefront has localised content but shares the underlying catalogue and order infrastructure.
Recommendation: headless CMS-anchored frontend, with shared frontend code and brand-specific themes. Multi-storefront complexity is the binding constraint; CMS-driven content management scales across markets; shared frontend code amortises engineering cost across the portfolio; commerce data lives once in the platform and is consumed by every storefront. The hosted vendor frontend approach struggles with multi-brand multi-region; custom-per-storefront produces a maintenance burden the organisation cannot afford long-term.
Decision Heuristics
A few heuristics that compress the decision framework:
- If time-to-market is the binding constraint, choose the hosted frontend. Even if it is not the long-term right answer, it is often the right first answer with a planned evolution to a more flexible model.
- If content workflow ownership separates marketing and commerce functions, plan for a CMS from the start. Retrofitting a CMS is more expensive than designing one in.
- If the storefront is the brand experience, custom or CMS-anchored frontends are the only credible choices. Hosted frontends do not produce premium-brand experiences in 2026.
- If you operate multiple storefronts on shared backend infrastructure, lean toward CMS-anchored builds. Multi-storefront management is where headless CMS shines.
- If your engineering capacity is constrained, lean toward hosted frontends. Custom builds consume engineering capacity continuously, and capacity-constrained teams produce sub-optimal results.
How McKenna Approaches the Decision
McKenna Consultants advises and builds across all three approaches. Our advisory engagements work the decision factors above through to a documented recommendation; our delivery engagements implement the recommendation. Specific delivery patterns:
Hosted frontend builds. Configuration, theming, and selective custom development on Elastic Path’s PXM Storefront and equivalent hosted experiences. Output: a launched storefront with documented configuration and operational handover.
Custom Next.js or Remix builds. Full custom frontends integrated with Elastic Path through the API surface, hosted on Vercel, Netlify, or customer-preferred infrastructure. Output: a launched storefront with shared component library, performance instrumentation, and SEO baseline.
Headless CMS-anchored builds. Storefront builds with Contentful, Storyblok, or Strapi as the content layer, integrated with Elastic Path commerce data. Output: a launched storefront with content authoring workflows established for the customer’s marketing function.
Frontend strategy advisory. Where the customer is choosing between approaches, we provide structured advisory leading to a documented decision, before delivery starts. Typical engagement length: three to five weeks.
If your organisation is choosing a composable commerce frontend approach, or rebuilding an existing storefront because the original choice has produced friction, contact us to discuss the decision and the engagement.
