Every CMS Demo Looks Great. Here Is the 5-Minute Test That Reveals the Truth.

In the first post in this series, I wrote about the editorial pain of CMS migrations. The response surprised me. Not from developers or CTOs, but from agency people and content leads who have been through this exact situation.

One comment stuck with me. A friend at a Swedish web agency said their clients' editors are so used to being excluded from CMS decisions that they are "genuinely surprised when someone asks what they think." That is not a process problem. That is a culture problem. And it shows up most clearly in one specific moment: the CMS demo.

The demo problem

I have sat through dozens of CMS demos. They all look incredible. Smooth page transitions. AI content generation. Composable architecture diagrams that would make any CTO nod along. The sales engineer builds a page from scratch in four minutes and the room applauds.

Then your content team starts using the platform and everything falls apart.

The demo was optimized for first impressions. Your editors need something optimized for the 50th time they do the same task on a Tuesday afternoon.

The five questions

1. Can I fix a live typo without a developer?

This sounds trivial. It is not. In many modern CMS platforms, correcting a typo on a published page means editing content in a form, saving, triggering a build pipeline, waiting for deployment, and then checking if the change actually went through.

Your editors fix typos dozens of times a week. If the CMS makes this feel like filing a support ticket, it has already failed the people who use it most.

2. Does the preview match what gets published?

Ask the demo presenter to show you the preview. Then ask to see the published output. Compare them side by side. In a surprising number of headless platforms, the preview is either missing entirely, requires custom development, or looks nothing like the final page.

3. Can I rearrange content without understanding the data model?

Watch what happens when you ask to move a section on a page. Does the editor drag and drop? Or do they need to understand content types, references, and component hierarchies?

4. Can you hire someone who knows this stack in two years?

A developer at a Swedish agency told me they are down to two people who understand old .NET Framework. Every new hire knows Node and React. He called it enormous technical debt.

This is not just about your current migration. It is about what happens after. Ask the vendor: what does your developer community look like? How many agencies in our market work with this platform? Can we find a freelancer on short notice if our lead developer leaves?

Better yet, ask whether the platform itself depends on a framework with its own deprecation timeline. A CMS built on web standards does not inherit someone else's EOL cycle. That matters when you are planning for a decade, not a quarter.

5. What does my editor's Tuesday afternoon look like?

Ask the vendor to walk through a typical content update. Not the impressive one from the keynote. The boring one. Update a phone number in a footer. Swap a hero image. Schedule a blog post for Thursday.

If any of those tasks require a developer, a deployment, or more than three clicks, your editors will feel it every single day.

The pattern

These questions are not about architecture, scalability, or API design. Those things matter. But they are already covered in every RFP.

What is almost never evaluated is what it feels like to use the CMS on an ordinary day. Developer experience gets conferences, blog posts, and X (previously Twitter) threads. Editorial experience gets a checkbox.

That imbalance is how teams end up 18 months into a migration and realize they have traded one set of workarounds for another.

What we are building

This is why we built Strife. A headless CMS where the editing experience is not a secondary concern bolted onto a developer platform. It is the starting point.

But headless does not have to mean editorless. That is a design choice, not a technical constraint. I will dig into that idea in the next and final post of this series.

Post 2 of 3. Previously: Your CMS Runtime Just Expired. Next: why headless does not have to mean editorless.