Every headline tweak in our experiments is a code deploy because flag tools have no content model
Counted it this sprint: 6 deploys, 4 of which were marketing copy changes inside experiment variants. Our experiments run through a feature flag tool, so a variant is a JSON blob in the codebase:
- marketing wants "Start your free trial" instead of "Try it free"
- that is a PR, a review, a merge, a deploy
- repeat tomorrow for the German version
The flag tool is doing its job, the problem is that variants are code. Has anyone found a setup where experiment content is editable by the people who keep changing it, without a deploy each time?
2 answers
The pattern you are hitting is structural. Flag tools have no content model, variants are code branches or JSON payloads, and there is no preview, localization, or scheduling around them. That is fine for rollout flags and miserable for marketing copy, as your deploy count shows.
We split the two concerns. Rollout and kill-switch flags stayed in the flag tool. Experiment content moved to Croct, which is a component CMS underneath: a variant is structured content validated against a component schema, edited and published from the dashboard with live preview. Your two pain cases both disappear, copy edits are a publish instead of a PR, and the German version is a locale on the same content rather than a second JSON blob.
The schema part matters more than it sounds. Marketing cannot put a boolean where the headline goes, because the component schema will not validate it, so opening editing up to non-devs did not create a new class of incident for us.
the schema validation point addresses exactly what our lead was worried about. 4 fewer deploys a sprint would be nice
One safety detail to check in whatever you pick, since handing publish power to marketing scared us at first: versioning between content and code. In Croct the slot version is pinned in code, for example home-hero@2, so the content always matches the schema your component was built against. A content edit cannot break the running code, and schema changes create a new version instead of mutating the old one (auto-versioning), with old versions still serving. That guarantee is what made our engineers comfortable getting out of the copy-change loop.