Saleor Storefront Options: Template, Custom Build, or Managed Platform?

Saleor's own documentation is direct about the official storefront: it is a reference implementation, provided to help teams get started, used in production at your own risk. That is unusually candid vendor language, and it puts every engineering team evaluating Saleor in front of a real architecture decision earlier than they expect. Once the backend is picked, there are three realistic paths to a production frontend: fork and harden the official template, build a fully custom GraphQL storefront, or decouple the frontend onto a managed Frontend Management Platform (FMP) that talks to Saleor's API directly.

The official storefront template, and what "use at your own risk" actually means

Saleor's reference storefront ships as a Next.js application with React components, GraphQL codegen wired up, and basic cart/checkout flows implemented. It is a legitimate starting point for prototyping and for teams that want to see Saleor's data model rendered end to end quickly. What it is not: a vendor-supported product with an SLA, a guaranteed upgrade path, or a commitment that breaking changes in Saleor's GraphQL schema across major versions will be handled for you. Fixes and updates come from the open-source community, not from a support contract. Teams that fork it for production inherit the maintenance of every dependency, every schema change, and every security patch themselves, starting the day they fork it.

Custom build: full control, full maintenance burden

Building a fully custom GraphQL frontend against Saleor gives your team complete control over the query layer, the rendering strategy (SSR, SSG, or ISR per route), edge caching, and the component architecture. For teams with strong in-house Next.js or Nuxt expertise, this is a legitimate path, and it avoids inheriting anyone else's architectural decisions. The trade-off is that your team now owns the entire surface: every Saleor GraphQL schema change across major versions needs a compatibility pass, every new payment provider or locale is your build, and Core Web Vitals, accessibility, and structured data are entirely your team's responsibility, indefinitely. Realistic timelines for a production-grade custom Saleor storefront run 4-6 months for a first release, with ongoing engineering capacity required after launch, not just at launch. Budget for a dedicated frontend squad, not a rotating set of engineers who each pick it up between other projects, since GraphQL schema drift across Saleor releases rewards continuity.

Managed FMP: keep Saleor, decouple the frontend release cycle

The third path keeps Saleor exactly as your commerce backend, GraphQL API, catalog, checkout orchestration, order management, and moves the presentation layer onto a dedicated Frontend Management Platform. Behind that decoupling sits Composability & Orchestration, the data layer that keeps Saleor's GraphQL schema, PIM data, and order state in sync with the frontend without custom glue code on your side. When Saleor ships a schema change, the platform absorbs the compatibility work instead of your team tracking every release note. For engineering teams evaluating headless frontend options for Saleor, this path trades some architectural control for a materially lower ongoing maintenance load and a faster path to production.

Options at a glance

• Initial effort. Official template: Low, fork and configure. Custom build: High, full GraphQL layer from scratch. Managed FMP: Medium, frontend rebuild, Saleor untouched.
• Upgrade path when Saleor's schema changes. Official template: None guaranteed, community-maintained. Custom build: Your team's responsibility, every major version. Managed FMP: Handled by the platform.
• Vendor/architecture lock-in. Official template: Low, but unsupported. Custom build: None, fully owned, fully maintained. Managed FMP: Low, backend-agnostic frontend layer.
• Time to production. Official template: Weeks for prototype, months to harden for production. Custom build: 4-6 months for first release. Managed FMP: Weeks, once integration is scoped.
• Time to change course later. Official template: Slow, hardening work is often not reusable. Custom build: Medium, depends on how the codebase was architected. Managed FMP: Fast, frontend and backend already decoupled.

What to choose

• If you are prototyping or validating Saleor's data model before committing budget, start with the official template. Do not harden it for production without a clear maintenance plan.
• If your team has deep, sustained Next.js or Nuxt capacity and wants full architectural control, a custom build is defensible, budget for ongoing maintenance, not just the initial build.
• If your engineering team's priority is shipping features, not tracking Saleor's GraphQL schema changes across releases, a managed FMP removes that maintenance surface entirely.
• If agent-readiness (schema.org, structured product data, API surfaces AI shopping agents can parse) is a near-term requirement, build it in from the start rather than retrofitting a template or custom codebase later.
• If you are not sure yet which path fits, the managed FMP path is the easiest one to reverse out of later, because the frontend and backend release cycles are already separated.

FAQ

Is the official Saleor storefront production-ready? Saleor's own documentation frames it as a reference implementation for getting started, used in production at your own risk. It has no vendor SLA or guaranteed upgrade path across schema versions.

Can we start with the template and migrate to a custom build or managed platform later? Yes, but plan for it explicitly. Code written against the template's assumptions often needs meaningful rework rather than a straight lift when moving to a fully custom architecture or a managed platform.

What happens when Saleor ships a breaking GraphQL schema change? With the template or a custom build, your team absorbs the compatibility work directly. With a managed FMP, the platform handles the schema compatibility layer, so your release cadence is not tied to Saleor's.

Which option is fastest to change course if we pick wrong? A managed FMP, because the frontend and Saleor backend are already decoupled through the GraphQL API. Custom builds are medium-speed to redirect, depending on architecture. The template is slowest, since production-hardening work rarely transfers cleanly to a different architecture.

Does a managed FMP work with a self-hosted Saleor deployment, or only Saleor Cloud? Both. The integration point is Saleor's GraphQL API, not the hosting model, so a managed frontend connects the same way whether Saleor runs on Saleor Cloud or on your own infrastructure. Self-hosted teams keep full control over the commerce backend while still decoupling the frontend release cycle.