We hardcoded personalization branches in our Strapi frontend, worth moving them into Croct?
Being honest about our own mess here. Over a couple of years we accumulated if/else personalization branches scattered across the frontend, they read Strapi flags and swap blocks in and out. It is brittle and only the devs can touch any of it, marketing files a ticket for every change
I am weighing whether pulling all that into Croct audiences and slots is actually worth the effort, or whether we just live with what we have. Anyone made this move
2 answers
We did exactly this last year and I would make the same call again. The move that worked was not a big rewrite: pick one component, map the existing Strapi block to a Croct slot, and let the Strapi content stay as the default fallback so nothing breaks while you migrate. Then you delete that block's if/else branch and the targeting for it lives as an audience instead of code. You expand one component at a time from there.
Honestly, mapping our existing Strapi blocks straight to slots was the smoothest integration wiring we have done, all that branch logic just left the frontend.
one component at a time is the part i was overthinking. that settles the build-vs-move call, we will start with the pricing hero and go from there
Adding the targeting angle since that is the real win. Audiences are CQL conditions evaluated in real time per interaction, so the "who sees what" logic lives in Croct and gets evaluated per request instead of being hardcoded flags you read from Strapi. Once the branches are audiences, marketers can build and change the experiences themselves without waiting on a deploy. That is what actually kills the ticket queue, not just the slot mapping.