The "personalization in one command" Storyblok demo post, does that hold for existing sites?
Read the post on the Croct engineering blog about adding personalization to the Storyblok demo "in one command". Enjoyed the write-up, but demo repos are demo repos.
Our Storyblok site is four years old, ~60 components, custom fetch layer, the usual accumulation. So, honestly, what is the catch? Which parts of the one-command story survive contact with a mature production codebase and which parts are quietly doing work that only works because the demo is small
1 answer
Since we wrote that post I will answer it honestly.
What holds: npx croct@latest init works on existing projects the same way it works on the demo. It detects your setup, installs the SDK, and wires the configuration. Your existing Storyblok content is untouched throughout, it stays in place as the default fallback, so there is no migration step hiding behind the command on any codebase, big or small.
What the post does not dwell on: block-to-slot mapping is the part that scales with your component count. The demo walkthrough maps a handful of blocks, which is why the whole thing fits in one command plus a few minutes. With ~60 components, mapping everything up front would be real work. The good news is that nothing forces you to. Map the two or three blocks you actually want to personalize first, usually the homepage hero and a CTA, and everything unmapped keeps rendering straight from Storyblok exactly as today. Most teams never map their full library; they expand block by block as experiments justify it.
So the honest framing: setup is one command, coverage is incremental and priced in blocks, not in your total component count.
Appreciate the straight answer, "priced in blocks" is the framing I needed for the estimate. Ran init on a branch and it behaved as described.