Images and video belong in your layout, not in a second tool. Starting today, you can upload, place,…
FaaS vs. Headless CMS: Why a CMS Alone Still Isn't a Frontend
FaaS vs. Headless CMS: Why a CMS Alone Still Isn't a Frontend
The team picked a headless CMS. The content model is set, the delivery API returns clean, structured content. Kickoff energy is high. Then comes the question that should have been asked first: who renders this, who operates it, and who keeps the storefront fast and current six months from now? A headless CMS doesn't answer that question, because it was never built to. It's a content backend, not a frontend.
That mix-up isn't a design detail, it's a category mistake. A CMS and a Frontend as a Service (FaaS) solve different problems, even though both show up in the same sentence the moment "composable" enters the conversation. This post draws the line clearly: what a headless CMS actually gives you, what's missing after that, and how to run both together without building either layer twice.
What a headless CMS actually delivers
A headless CMS, whether it's Contentful, Storyblok, Sulu, or Kontent.ai, reliably delivers three things: a content model for structured content, an editing interface for marketing and editorial teams, and a delivery API that content is pulled through. That's the core of the "headless" promise: content is decoupled from the output channel, so the same content model can serve web, app, and other touchpoints.
What's deliberately missing is the "head." No rendering, no component library, no routing, no hosting layer, no performance guarantee. That's not a gap in the product, it's the design decision that makes headless CMS fast and flexible in the first place. It just means the real work starts once the content is modeled, it doesn't end there.
What's missing after that: the storefront operating layer
Between "the content API returns data" and "a customer sees a fast, accessible, on-brand page" sits an entire operating layer that kickoff workshops love to skip over:
- Rendering and components. Who builds the components that display the content, and who maintains them across campaigns, locales, and brands?
- Performance and Core Web Vitals. An API response is not an LCP score. Edge delivery, caching, and image optimization don't happen automatically just because the CMS is headless.
- Accessibility. WCAG and equivalent accessibility standards are frontend properties, not content model properties.
- Live preview in real context. Many CMS editors show a preview of the content, not the actual, rendered storefront page with real layout and real neighboring components.
- Operations. Hosting, CI/CD, monitoring, rollback, everything that turns a one-time build into a running service.
That layer is exactly the job of a Frontend as a Service. We've written separately about what visual editing looks like directly in a live storefront, instead of an isolated CMS preview: Visual Editing in a Live Storefront: Why CMS Preview Isn't a Frontend.
FaaS: the operating layer on top of the CMS
Frontend as a Service is exactly the operating model that closes the gap between the content API and the live storefront, as a service instead of a one-off project. Instead of your team building the rendering, performance, and operations layer once and then keeping it alive on its own, a FaaS runs that layer continuously: component library, live editor, hosting, performance monitoring, multi-locale sync. The CMS stays the source of truth for content, the FaaS becomes the source of truth for the storefront experience.
The difference from a self-built frontend layer isn't that components exist, internal teams build those too. The difference is that the operating layer itself becomes a platform property, instead of pulling engineering capacity back in every time the CMS updates, traffic spikes, or a new locale gets added. We sketched this same principle, complementing a CMS with a visual frontend instead of replacing it, using concrete CMS migration examples here: Headless CMS with a Visual Page Builder: The Missing Frontend Layer.
CMS and FaaS aren't an either-or
The last few weeks brought a whole wave of "frontend options for [CMS]" comparisons, covering Contentful, Storyblok, Sulu, Kontent.ai, and others. The common thread across all of them is the same: the CMS is good at what it was built for, content modeling, editorial workflows, API delivery. None of them were designed to be a storefront frontend, and that's not a knock on the vendors, it's just architecture.
That's why Laioutr doesn't position itself as a CMS replacement, but as the frontend layer that sits on top of an existing headless CMS. Your CMS stays the content backend, Content Management at Laioutr handles composition, in-context editing, and brand consistency across pages, locales, and campaigns. Editorial teams keep working in their CMS, or directly in Studio depending on setup, but the page that actually goes live is an operated storefront, not the raw rendered output of a content API.
How to separate the CMS question from the frontend question in practice
Four questions help keep the two layers straight before a project stumbles over mixing them up:
- Who renders the page the customer actually sees? If the answer is "the CMS handles that somehow," the frontend question is still open.
- Where do performance, accessibility, and SEO live? All three belong to the frontend layer, not the content model.
- Does editorial see a real live preview, or only a content preview? That difference decides whether a campaign page ships in hours or in sprints.
- What happens with a second brand or a second market? A good answer needs its own operating layer, not a second CMS setup.
If you can't clearly answer these four questions for your current setup, you likely have a CMS, but not yet a frontend.
Next steps
Choosing a headless CMS is a good decision. Assuming it automatically solves the frontend question is the mistake that slows projects down right after kickoff. If you want to see what a Frontend as a Service looks like concretely on top of your existing CMS, take a look at Frontend as a Service or book a demo where we walk through it against your actual content model, not a generic example page.
More from the Laioutr platform
About the author: Marcel Thiesies is Co-Founder of Laioutr. He works with mid-market teams across DACH and beyond on keeping CMS decisions and frontend decisions cleanly separated, while running them together operationally.