Storyblok in practice: What we have learned from our projects

At P·S·P GmbH, the team puts new insurance offers online themselves. Nobody has to call us for this, nobody waits for a developer. This is exactly why we use Storyblok. As a certified Storyblok partner, we have now completed a number of projects with it. Here is what has proven itself and where we advise clients against Storyblok.

What Storyblok does differently

Storyblok is a so-called headless CMS from Linz. “Headless” means that the system only stores the content. How it looks on the website is decided by a separate frontend that we program for you. Content and presentation are therefore separate.

For editors, the Visual Editor is the most important part. You see your real website in a preview, with the fields next to it. You click on a heading in the preview and land directly in the right field. If you previously had to search for the right form in a classic backend, you will notice the difference on the first day.

Storyblok is software that runs as a service on the internet (software as a service). The provider takes care of the servers, updates and security of the system itself. For our projects, we choose the data region in the EU.

Blocks instead of free-form pages

The real value is not created in the CMS but in the structure set up beforehand. For each website, we define a manageable number of blocks: a header, text with image, an image gallery, an FAQ, a contact section. Each block has clearly named fields. Editors build their pages from these blocks themselves.

This is how we worked on Schloss Drosendorf in 2025. The website runs on Nuxt and Storyblok, in German and English. In addition to the standard blocks, there are dedicated ones for events, for products and for embedded content. Header and footer are separate content items in Storyblok. If a menu item changes, the team updates it in one place. It then applies on all pages.

We learned three things along the way:

• Spacing belongs in the block. We no longer build a separate “spacer” that you push between two sections. It leads to every page looking slightly different. Every block brings its own spacing.

• Enter once, use many times. A reference or an article is created once. The overview on the home page takes the title, image and short text from there. If you change the title, it changes everywhere.

• Fewer options are better. Every additional “choose colour” field is a chance to break the design by accident. We only offer choices that mean something for the content.

Draft and publication

In Storyblok, every piece of content has two versions: a draft and a published version. Whatever you save goes into the draft first. You see it in the preview, your visitors do not see it yet. Only when you click “Publish” does the change go live.

That sounds obvious, but it changes the way you work. We prepare larger changes entirely as drafts, have the client check them in the preview and only publish once everything is right. Before we change content by script, we back up the previous version.

There is one pitfall: if a change affects several content items, such as a new page and its menu item, both have to be published. Otherwise the menu points to a page that does not yet exist publicly. We explain this during the training as well.

Where Storyblok plays to its strengths

Storyblok is most useful for websites that change often and that several people work on. P·S·P GmbH is a good example. Insurance topics are complex and the offers change. The team adds new services themselves without the structure of the site suffering.

Other cases in which we recommend Storyblok:

• Websites in several languages where the translations are maintained side by side

• Content that appears in several places, such as references, events or products

• Teams who want to build new pages themselves without the design fraying

• Projects where the same content is later meant to flow into an app or another system

When it is too much

For a small website that changes twice a year, you do not need Storyblok. A trade business with five pages hardly uses the strengths of the system. On top of that come a separate contract with Storyblok, a separate frontend and more development effort. A lean system or a simple WordPress site is often the more sensible choice here. We say so in the initial consultation too.

A second point is the dependence on a service. Your content is stored at Storyblok, not on your own server. For most of our clients, this is an advantage because they do not have to take care of anything. If you absolutely want your data in house, a self-hosted system is the better fit.

Our conclusion

Storyblok is not an end in itself. It is worthwhile where people maintain content regularly and should not break anything in the process. What matters is a well thought-out set of blocks that suits the website. A look at the P·S·P GmbH website shows what this looks like day to day.

If you would like to know whether Storyblok suits your project, take a look at Web Design & Development, where we explain how we approach projects like this.