Adding a multi-language field to the backend takes an afternoon. The part that takes months sits in …
Saleor Storefront: Where the Visual Editor Ends
Saleor's backend is one of the strongest arguments in open source commerce: a GraphQL-first API, a modern Python core, and an architecture that never forces a monolithic storefront on top of it. Teams pick Saleor precisely because the backend does not get in the way. The friction shows up one layer higher, in the official Saleor Storefront itself, which ships as a Next.js template built for engineers to extend, not for a content or marketing team to run day to day.
This piece stays on that specific seam: what the Storefront template actually is, what the Saleor Dashboard actually offers for editing content, and where exactly the gap opens once a non-developer needs to publish a new page. If you are still deciding between the template, a custom build, or a managed storefront for Saleor in the first place, our storefront-options comparison covers that upstream decision. If your priority is avoiding GraphQL complexity on the storefront side altogether, our post on Saleor for retailers without GraphQL overhead covers that angle. This post assumes you already have, or are about to have, a working Saleor Storefront, and asks what happens when someone outside engineering needs to change it.
What the Saleor Storefront template actually is
The official Saleor Storefront repository describes itself as a production-ready template built with React, Next.js App Router, TypeScript, GraphQL, and Tailwind CSS, licensed under FSL-1.1-ALv2, which converts to Apache 2.0 two years after each release. That is a source-available starting point, not a hosted product. You clone it, wire it to your Saleor GraphQL endpoint, and from there the codebase is yours to maintain, extend, and deploy.
That framing matters because it decides where every future change has to happen. Page layout, section order, and component composition live in the Next.js codebase as React components and routes. There is no database-backed page model driving what a landing page or a campaign page looks like. If a new section needs to appear on the homepage, someone edits a component file, opens a pull request, and deploys it. The template is genuinely good at what it is built for, a fast, typed, GraphQL-native starting point for a development team. It was never built as an authoring surface for people who do not write code.
What the Saleor Dashboard offers for content, and what it does not
Saleor's own admin, the Dashboard, does include a content feature: Pages, for things like an "About us" page or a policy page. Since Saleor 3.0, page content uses Editor.js instead of the older Draft.js, stored as structured JSON that a storefront can render however it wants, including read-only rendering on the frontend.
That is a genuinely useful primitive for static, text-heavy content. It is not a page builder. Editor.js gives you rich text blocks, headings, lists, embeds, the things a long-form editorial page needs. It does not give you a section-based layout system: no hero blocks with configurable columns, no product grids you can drag into place, no way to preview how a change will actually render inside the live storefront before it ships. A marketer editing a Saleor Page is composing structured text, not composing a page layout. The moment a change involves visual structure rather than paragraph content, whether it is a new campaign hero, a reordered product carousel, or a seasonal banner, it stops being a Dashboard task and becomes a Next.js pull request.
Where it breaks in practice
Four points come up consistently once a content or marketing team tries to run day-to-day publishing on top of the stock Storefront template:
- New landing pages need a developer. Because layout is code, not data, a net-new campaign page is a build task, not a content task. There is no self-service path from "we need a Black Friday page" to a published URL without someone opening the repository.
- Section-level changes require a deploy. Reordering a homepage, swapping a hero image for a different aspect ratio, or adding a promotional strip mid-page all touch component code, which means a build, a review, and a deploy pipeline, even for changes that are visually trivial.
- Preview is disconnected from authoring. Editor.js content in the Dashboard has no live binding to how the storefront actually renders it. Editors write structured text on faith that the frontend will style it correctly, rather than seeing the real page update as they work.
- Localization is an API capability, not a workflow. PageTranslatableContent exists so translated fields can be stored and queried, but turning that into a working multi-market publishing workflow, one editor per locale, approvals, staged rollout, still has to be built on top. The API gives you the data shape; it does not give you the editorial process.
None of this is a defect in Saleor. It is the direct, expected consequence of shipping an open source, developer-oriented storefront template instead of a hosted content product. The Storefront repository is explicit about being a starting point meant to be forked and customized, and a forked, customized Next.js codebase is, by construction, something only engineering can safely change.
Why this becomes an organizational bottleneck, not just a technical one
The pattern is familiar from every headless stack that separates a strong API backend from a code-only frontend: the backend decision gets made once, by engineering, and is genuinely good. The frontend then becomes the daily interface for marketing, content, and growth teams, who have no direct way to touch it. Every campaign page, every seasonal layout tweak, every A/B test variant becomes a ticket in the engineering backlog, competing with feature work for the same sprint capacity.
For Saleor specifically, this is a sharper version of the pain because the backend is unusually capable. Teams choose Saleor for its API depth, its multichannel model, its extensibility, precisely the qualities that make a GraphQL-first architecture attractive to an engineering team. That same depth does nothing for the marketer who just needs a new page live before a campaign launches on Monday. The gap is not a missing feature in Saleor. It is a missing layer between the API and the people who need to publish against it without writing code.
What an editor layer on top of Saleor actually changes
This is the point where a Composable Visual Page Builder sits on top of, not instead of, the Saleor GraphQL API. Laioutr connects directly to Saleor's product, category, and checkout data, the same API your Next.js Storefront already calls, and exposes it through a Content Management layer that a marketing team can operate without a deploy. Existing Storefront components do not get thrown away; they get registered as reusable blocks that Studio's editor can place, reorder, and configure with a live preview bound to the actual rendering, closing exactly the authoring-to-render gap that Editor.js leaves open.
The organizational split that results is the one Saleor's own architecture already implies but does not deliver on its own: engineering keeps ownership of data models, integrations, and the underlying component logic, while the content manager and editor roles publish pages, campaigns, and copy changes directly. That is the same decoupling argument that makes Composable Headless Frontend work for any GraphQL-first backend: the API stays the source of truth, and the editor layer is the missing piece that turns API depth into daily publishing speed.
Where the stock template is genuinely enough
To be fair to Saleor: if your storefront needs are simple, a handful of static pages, a product catalog with standard PLP and PDP layouts, and no more than occasional seasonal copy tweaks, the Storefront template plus Dashboard Pages can carry a small team for a long time. The problem is not the template's existence, it is the moment your publishing cadence outgrows what a developer with spare sprint capacity can absorb, which for most growing commerce brands happens faster than the initial build plan assumed.
- New pages per month. Template is enough: 0 to 1. You need an editor layer: Several, on a campaign calendar.
- Who requests changes. Template is enough: Engineering itself. You need an editor layer: Marketing, content, regional teams.
- Layout variability. Template is enough: Low, mostly static pages. You need an editor layer: High, seasonal and campaign-driven.
- Multi-market publishing. Template is enough: Single locale. You need an editor layer: Multiple markets, own editorial cadence each.
- Preview requirement. Template is enough: Staging deploy is acceptable. You need an editor layer: Real-time preview before publish is expected.
Our take
Saleor's backend earns its reputation. The Storefront template earns its reputation too, as a clean, typed, well-documented starting point for a development team, which is exactly what its own repository says it is. The mismatch only appears when a business tries to run marketing operations through a tool that was built and licensed as a developer artifact. That is not a Saleor shortcoming to fix; it is a layer that was never meant to exist inside the template in the first place, and it is the layer worth adding once your publishing needs outgrow what Editor.js and a deploy pipeline can support.
Frequently asked questions
Does Saleor have a visual page builder at all? Not in the sense of drag-and-drop, section-based layout composition. The Dashboard's Pages feature covers structured rich text through Editor.js, which is well suited to static content but not to visual page layout or live preview.
Can we keep our existing Next.js Storefront components if we add an editor layer? Yes. The components that already call Saleor's GraphQL API do not need to be rewritten; they get registered as blocks a visual editor can place and configure, which is the same integration pattern Laioutr uses for any composable frontend.
Is this an argument against Saleor as a backend? No. The argument is specifically about the Storefront template's authoring model, not the commerce API underneath it. Saleor's GraphQL depth is exactly what makes a composed editor layer possible in the first place.
Next steps
If your team is publishing Saleor pages through pull requests more often than through a Dashboard, book a 30-minute demo. We will look at your current Storefront components and show what the same pages look like with a marketing-editable layer on top.
More from the Laioutr platform
About the author: Marcel Thiesies is Co-Founder of Laioutr and works with commerce teams on the frontend layer that sits between a composable backend and the people who need to publish against it every day.