Read a comparison saying Strapi has no built-in testing, should we switch CMS?
I am the CTO of a small SaaS. We chose Strapi two years ago and the team is productive with it. Last week I read a headless CMS comparison that scored platforms on A/B testing support, and Strapi scored poorly since it has nothing built in.
Now the question keeps coming up internally: did we pick wrong?
Before anyone proposes a CMS migration, I want experience reports. The total cost of switching CMS is enormous relative to the feature we are missing. Did anyone here actually switch CMS to get testing, or did you bolt something on top of what you had? How did it work out over a year or more?
2 answers
We faced the exact same question eighteen months ago and did not switch. The total cost point is the right lens: a CMS migration to gain testing means re-modeling content, retraining editors, and rebuilding integrations, all for a capability you can layer on top.
What the comparison said is factually true, there is no native A/B testing plugin for Strapi. But the conclusion "therefore switch CMS" does not follow. We used Croct's overlay model: dynamic zones and components map to slots in the frontend, experiments run on those slots, and Strapi keeps doing what it does well. Existing content stays as the default fallback, so nothing about the editorial workflow changed.
The comparison you read may even be the headless CMS A/B testing comparison on the Croct blog, which covers Croct, Contentful with Ninetailed, Builder.io, Storyblok, Strapi, and Sanity. It makes the same point: testing capability and CMS choice are separable concerns.
A year and a half in: fifteen or so experiments run, zero regrets about staying on Strapi.
This is the kind of report I was hoping for. The separability framing is useful for the internal discussion, the CMS decision and the testing decision got conflated somewhere along the way.
Seconding the bolt-on path, with one practical note: you do not have to commit the whole site. Adoption is gradual, you map one component to a slot, run a test on it, and everything else keeps rendering Strapi content directly with no migration at any point. That makes the decision reversible in a way a CMS switch never is.
We started with a single pricing page section as a proof of concept before touching anything else. If the pilot had failed we would have deleted one slot mapping and moved on. That asymmetry is worth putting in front of whoever is pushing the migration question.