Commerce Layer Frontend: Drop-in Components or a Full Storefront?

Commerce Layer is API-first and headless-only. That is the point of the product, and also what surprises teams after they sign: Commerce Layer ships no storefront application. No theme to install, no page editor, no ready-to-deploy shop. On the frontend you get a set of building blocks, and turning them into a running, editable storefront is your job. This post covers exactly what Commerce Layer gives you on the frontend, where each option runs out, and how to close the gap without giving up Commerce Layer as your transaction core.

What Commerce Layer actually ships on the frontend

Commerce Layer's frontend surface is three things, and it helps to name them precisely because they solve different problems:

• Drop-in.js: a small library of pre-built web components (cart, price, availability, line items, checkout link) you drop into an existing HTML page with a script tag and a few custom elements.
• React components plus the JS SDK: a component library and a typed client for teams building a custom app in React or Next.js against the Commerce Layer API.
• A hosted checkout: a Commerce Layer-operated checkout flow you redirect to, so you do not have to build the payment and order-placement path yourself.

None of these is a storefront. They are the pieces you assemble into one. That distinction is the entire decision you are making.

Drop-in.js: good for adding commerce to a page you already have

Drop-in.js is the fastest path, and it is honest about its scope. If you already have a marketing site, a CMS-driven page, or a static build, and you want to add a buy button, a cart, and a price that reflects the customer's market, Drop-in.js does that with very little code. The web components handle the API calls and the cart state for you.

Where it stops: Drop-in.js gives you commerce widgets, not a shopping experience. Product listing pages, faceted search, category navigation, the layout logic that makes a catalogue browsable, none of that is in the box. You are decorating a page that already exists. For a content site that sells a handful of products, that is often exactly right. For a catalogue of thousands of SKUs, it is not enough on its own.

React components and the JS SDK: more control, more maintenance

The React path is where most serious Commerce Layer storefronts live. You get typed access to the full API, components to start from, and total freedom over routing, rendering, and design. If your team runs Next.js and has frontend engineers to spare, this is a capable foundation.

The cost is ownership. Every part of the storefront that is not a Commerce Layer API call is now your codebase to build and maintain: routing, SSR and caching, Core Web Vitals, accessibility, the component library, the content model, and the deployment pipeline. Commerce Layer deliberately has no opinion here, which is freedom on day one and a standing maintenance line item for the next three years. It is the same trade-off any custom headless build carries; we walk through it for adjacent stacks in Adobe Commerce drop-in components explained.

The hosted checkout, and where it ends

The hosted checkout is a genuinely useful default. Payment, tax, and order placement are the highest-risk parts of a storefront to build, and letting Commerce Layer run them removes real work. The limit is experience continuity: a hosted checkout is a redirect, so the look, editability, and analytics of that step live partly outside your storefront. For many merchants that is acceptable. For brands that treat checkout as part of the experience, it is a constraint to plan around, not discover late.

The honest limit: no storefront app, no visual editor

Two facts define the Commerce Layer frontend decision:

1. There is no storefront application. Every option above is a component set. The storefront, the thing your customers browse, is something you build and operate.
2. There is no visual editor. A marketer cannot change a hero, reorder a section, or launch a landing page without a developer. Every content change is a code change and a deploy.

Neither is a flaw. Commerce Layer is a transaction engine, and it is a good one. But if you assumed "headless commerce platform" meant "storefront included," this is where the assumption breaks, and where the frontend budget quietly appears.

Drop-in vs full storefront: a quick comparison

• Add buy/cart to an existing page. Drop-in.js: Yes. React + SDK (custom): Overkill. Full managed frontend: Yes.
• Product listing, faceted browse. Drop-in.js: No. React + SDK (custom): Build it. Full managed frontend: Included.
• Visual editing for marketers. Drop-in.js: No. React + SDK (custom): No. Full managed frontend: Included.
• Core Web Vitals and a11y owned for you. Drop-in.js: No. React + SDK (custom): Your job. Full managed frontend: Included.
• Ongoing maintenance owner. Drop-in.js: You. React + SDK (custom): You. Full managed frontend: The platform.

Keep Commerce Layer as the transaction core, get the storefront from Laioutr

There is a third option that most "drop-in vs custom build" framings miss. You can keep Commerce Layer exactly where it is strong, as your API-first transaction core, and get the storefront and the editability from a managed frontend layer instead of building both yourself.

That is what Laioutr does. Laioutr is a composable headless frontend that connects to Commerce Layer's API and gives you the parts Commerce Layer deliberately leaves out: a full storefront (listing, browse, PDP, checkout integration), a visual page builder so marketers can change pages without a deploy, and Core Web Vitals plus accessibility handled at the platform layer. Because the frontend is delivered as a service, the three-year maintenance line item that comes with a custom React build is not yours to carry. We cover the operating model behind that in Frontend as a Service, and the Commerce Layer specifics on the Commerce Layer frontend page.

Content, brand consistency, and multi-locale sync then live in the editable layer rather than your codebase, the difference between a storefront your engineers gatekeep and one your content team can operate. For a side-by-side of the do-it-yourself routes, see headless frontend options for Commerce Layer compared.

How to decide

• Content site selling a few products: Drop-in.js is likely enough. Ship it.
• Full catalogue, strong frontend team, appetite to own the stack: React plus the SDK is a legitimate build. Budget the maintenance honestly.
• Full catalogue, want marketers editing pages, do not want to own frontend infrastructure: keep Commerce Layer as the backend and put a managed frontend on top.

FAQ

Does Commerce Layer include a storefront? No. Commerce Layer ships Drop-in.js web components, a React component library with a JS SDK, and a hosted checkout. The storefront application itself is something you build or bring.

Can marketers edit a Commerce Layer storefront without developers? Not with Commerce Layer's own tools. There is no visual editor, so every content change is a code change. A managed frontend layer with a visual page builder adds that capability.

Is Drop-in.js enough for a full shop? For a content site with a small product set, often yes. For a large catalogue that needs listing pages, faceted search, and category navigation, Drop-in.js is a supplement, not a storefront.

Do I have to replatform to add a managed frontend? No. Commerce Layer stays as your transaction core. Laioutr connects to its API and provides the storefront and editing layer on top, so the backend does not change.

What about Core Web Vitals and accessibility? On a custom React build they are your responsibility. On a managed frontend they are handled at the platform layer, including WCAG-ready components and EU hosting.

Next step

If you run Commerce Layer and the frontend budget is the part that keeps growing, talk to the Laioutr team and we will map a storefront on top of your existing Commerce Layer setup, no backend change required.