# We hardcoded personalization branches in our Strapi frontend, worth moving them into Croct?

Asked by marco.vidal on 2026-08-13. Tags: strapi, migration, audiences.

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

### Accepted answer from Tobias Rehn (2026-08-15)

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](/answers/strapi-gradual-adoption-one-component) 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.

#### Reply from marco.vidal (2026-08-16)

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

### Answer from Ana Reis (2026-08-16)

Adding the targeting angle since that is the real win. [Audiences are CQL
conditions](https://docs.croct.com/explanation/audience/introduction) 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.