Storyblok CMS consultancy
The Visual Editor shows a different layout from the deployed page. Components collect fields they no longer need. A field rename breaks the frontend. I review how the Storyblok space and the site work together.
Send the component library, preview issue, integration, localisation decision or migration. I write down which components to change, how to fix preview and how to sequence a migration.
100 USDexcl. VAT
- A schema-as-code plan: component definitions in version control, synced to the space, specified for your team to wire.
- A component-library, Visual Editor and frontend-integration review for your Next.js or Astro site.
- A localisation decision, or a migration plan sequenced around the API's rate limits.
In practice
What happens when a Storyblok field is renamed
A field rename shows whether the schema and the frontend can change together.
The field changes in a pull request
The component definition is a file, so a rename is a diff, and the frontend component reading the field changes in the same commit.
- { "name": "headline", "type": "text" } + { "name": "title", "type": "text" }Someone reviews it against the code that reads it
Storyblok's approval workflows attach to stories, not to component schemas, so this review is the one the UI cannot give you.
The sync pushes it to the space
One command updates the Storyblok space from the files in the repository.
storyblok push-components --space <space-id>
The editor opens the page and sees the new field
The bridge resolves the draft against a frontend that now expects
title, and the preview matches what will deploy.
FAQ
Scope
Why should the component schema live in code?
So a schema change gets reviewed before it goes live. Storyblok's approval workflows apply to stories and do not cover component schemas (Storyblok docs, Workflows), so a renamed field goes live the moment it is saved. In version control, the rename and the component that reads it land in the same pull request.
When is schema-as-code not worth it?
When one team maintains a stable space and field changes do not break the frontend. Then the CLI's pull-components and push-components commands can copy schemas between spaces without a custom pipeline (Storyblok FAQ).
What does this cover?
The component library: what splits, what merges, nesting depth and whitelists. Multisite, multi-brand and multilingual architecture: shared components, local ownership and publishing rules. The Visual Editor and the frontend behind it: the bridge, preview, fetching and generated types on Next.js or Astro. Migrations into, out of, or between spaces, sequenced against the management API's rate limit (Storyblok management API docs).
Do you set the sync up, or only recommend it?
I only recommend it. I write the specification and your team sets it up.
How is the time scoped?
I read the space first, then reply with a fixed number of hours at 100 USD an hour excl. VAT, with a 300 USD minimum. A single component or bridge question is usually a few hours, moving a space's schema into code or a migration plan a day or two. Nothing starts before you agree the hours.
Something else on your mind? The chatbot answers questions about my work from this site. Ask in English, Polish or your own language.
Ask the agentRelated reviews
I check why preview differs from the site
Preview can differ when the frontend resolves a draft incorrectly. I check the Next.js or Astro integration and also review Sanity projects.
In practice
How a Storyblok review runs
Send the space and the question
Read access to the space and the frontend repository, and a sentence on what is at stake.
I read the space first
The component groups, whitelist rules, localisation setup and frontend wiring your question touches, then a fixed number of hours at 100 USD an hour excl. VAT, with a 300 USD minimum.
You get a change list
Which components to split or merge, what the bridge is doing on preview, how to sequence a migration.
Storyblok CMS consultancy
100 USDexcl. VAT
- A multisite, multi-brand or multilingual architecture for the space, component library and content ownership.
- A schema-as-code plan: how component definitions move into version control and sync to the space, specified for your team to wire.
- A component-library review, or a restructuring plan for one that outgrew itself.
- A Visual Editor and frontend-integration review for your Next.js or Astro site.
- A localisation decision for your space, against how your team translates.
- A migration plan sequenced around the management API's rate limits.
Get in touch
Send the question
Send read access to the space and the frontend repository, plus a sentence on what is at stake - the Visual Editor that drifts, the component nobody wants to split, or the migration you have to sequence.
Working with an AI agent?