Why and when we choose Payload or Storyblok.

A CMS shapes how content teams work, how developers build, how much you'll pay years from now, and how easy it will be to change course when a product outgrows its original assumptions. It's one of the most consequential architectural decisions in a web product, and it tends to get made too quickly.

Over the years, we've built on most of the available options, but we keep coming back to two: Payload and Storyblok. They're not interchangeable, and picking the right one requires understanding what each one offers. In broad terms, we reach for Payload when ownership and technical complexity matter most, and for Storyblok when editorial speed and publishing independence take priority. The full answer depends on the project, which is what this article is about.

What is a CMS?

A Content Management System sits between your content team and your website or application. It is the middle layer that determines how content is structured, who can edit it, how it reaches the front-end, and how often a developer needs to get involved in everyday tasks (which is where most pain points reside and where costs might creep in). Think of it this way: a CMS is where your product photos, descriptions, blog articles and all kinds of user-facing information about your business gets updated and managed.

Currently, the market offers four broad CMS categories, each with meaningfully different implications for your team and your product's future.

Category	Products	What it means in practice
Self-hosted open-source	Strapi, Payload	Runs on your infrastructure. Full ownership, full flexibility, no vendor involved.
Headless cloud	Storyblok, Contentful, Sanity, DatoCMS	Content-as-a-service: your front-end and CMS are separate. Strong editorial UX, vendor dependency as the trade-off.
Traditional	WordPress, Drupal	Mature ecosystems with plugin-heavy architectures. High flexibility, high maintenance overhead.
Visual website builders	Webflow, Framer	Design and publish in one tool. Fast to launch, constrained as requirements grow.

Why we use Payload.

Payload is an open-source, TypeScript-native headless CMS with one defining characteristic: it lives inside your application codebase rather than alongside it. In most headless CMSs, the CMS is a separate system you connect to, which means a separate deployment to manage, a separate service that can drift from what your application actually expects, and a vendor sitting between you and your own content. Payload removes all of that by being installed directly into your codebase, where the schema is TypeScript, the admin UI is React, and the API is generated automatically. Content types, access control, validation logic, custom fields: all of it is code, reviewed and deployed the same way as everything else in the project.

That architecture has real consequences for ownership. Your data lives in your own database, on your own infrastructure, with no per-seat fees, no record limits, and no pricing surprises as your content operation grows. If Payload were acquired tomorrow and shut down, your product would continue running unchanged. That’s a real risk, and one that tends to surface at the worst possible moment with SaaS alternatives.

Payload also scales into territory most CMSs don't attempt to cover. Authentication, access control, file management, multi-tenancy: it handles all of it out of the box, which means fewer additional services to stitch together as your product grows more complex. It does require a development team to set up, launch, and maintain, and that's the honest trade-off. For projects with non-trivial data models, custom front-ends, and clients who want to own what they build for the long term, it's almost never the objection that rules it out.

We love open-source!

More than a set of tools, it’s a whole philosophy of communal transparency.

Learn more

Why we use Storyblok

E-commerce editorial teams have a different problem from product development teams. They're managing product pages, promotional campaigns, and seasonal updates on a continuous basis, and they need to publish independently, quickly, and with enough confidence that what they're editing is what will actually appear on the page. A schema in code doesn't help them with any of that, which is why for e-commerce work the calculus shifts, and Storyblok earns its place.

Storyblok is a headless cloud CMS built around a visual editing experience, which sounds like a minor nicety until you've watched a marketing team lose half a day waiting for a developer to update a banner. Its visual editor shows the real page rendered in the browser, with editable components overlaid directly on it, so the gap between editing and publishing closes considerably. Changes that would previously have required developer time can be handled by marketing teams on their own schedule, and that shift in autonomy has a real and measurable effect on how quickly content moves through an organisation.

Its component model reinforces this. Storyblok organises content around reusable blocks such as hero sections, product feature areas, promotional banners, testimonials, which are defined once and composable across pages without duplication. This gives editors the flexibility to build and adapt pages without touching the underlying structure developers rely on. That consistency holds up as campaigns multiply and product catalogues grow, and for brands operating across multiple markets, multi-language content is handled natively rather than something that needs to be architected from scratch.

The trade-off is the one inherent to any SaaS product: your content lives on Storyblok's infrastructure, pricing scales with usage, and you're dependent on their continued operation. For most e-commerce contexts that's a reasonable exchange, because what you get in return is no DevOps overhead, no server maintenance, and a considerably shorter path from project start to live site. For clients working to seasonal deadlines or aggressive launch targets, that last point alone tends to settle the argument.

Storyblok & Shopify

Headless architecture gives your business the advantage it needs to thrive.

Learn more

Decisions, decisions!

We recommend Payload for most product work we take on, and Storyblok for most e-commerce projects, but the right answer always depends on where the real friction lives for your specific team and your specific product, and that's worth figuring out before any decision gets made by default.

If you need a simple marketing site live quickly with no budget for infrastructure setup, Webflow or Framer will get you there faster. If your team is non-technical and needs a fully managed product with no DevOps overhead, Storyblok is a strong choice even outside e-commerce. If you have an existing WordPress installation with years of content and a functioning editorial team, the disruption of moving will usually outweigh the gain.

The reason we keep coming back to Payload and Storyblok is straightforward: after working with most of the available options, these are the ones that have consistently done what we needed them to do. A CMS that slows your editorial team down every single day has a real cost, even if it doesn't show up in the initial build estimate, and a vendor dependency that creates pricing risk or data residency complications down the line is not something to park for later.

Tried and tested.

Hey Harper and mishmash give a clearer picture of what these decisions look like once a project goes live. When we rebuilt mishmash on Storyblok and Shopify, their editorial team gained the independence to move at commercial speed, and the results followed: sales up 212%, orders up 61%, and return on investment within four months of launch. Hey Harper tells a similar story: a platform that had outgrown its original Shopify template setup, rebuilt with Storyblok handling the front-end content layer, with ROI reached within the first month, conversion rate up 17%, and average order value up 18%.