OPINION
A CMS is only good if the person using it doesn't need a developer
The complaint was specific — uploading galleries and video was too complicated. That is a better brief than most product requirements.
We had a CMS. It worked. Content could be changed.
It just could not be changed by the people who wanted to change it, which is a different thing, and it meant every gallery update queued behind someone technical.
Friction plus low urgency equals never
Nobody refuses to update content. What happens is smaller than that.
Adding a gallery requires asking a developer. Asking is mild friction. Updating the gallery is not urgent — it is a good idea, not a deadline. Mild friction applied to a non-urgent task produces a task that does not happen.
So the site goes stale, for reasons that have nothing to do with anyone's intentions and everything to do with who has to be involved.
Media is where it breaks
The specific complaint was galleries and video, and that is not a coincidence. Text is easy: a field, some formatting, save. Media introduces decisions a non-technical editor should never have to make.
What format. What dimensions. What file size is too large. Why the upload failed. Why the video plays on desktop and not on a phone. Why the image looks different once published.
Every one of those is a place where the editor stops and asks someone. The answer is not to document the decisions — it is to remove them.
Preview accuracy is the entire trust model
This is the one I would emphasise most.
An editor publishes confidently when they believe the preview. The moment preview and published output differ — once — they stop trusting it. And a non-technical editor who does not trust preview will not publish; they will ask a developer to check, which is exactly the situation you were solving.
Preview fidelity is not a nice feature. It is the mechanism by which the whole tool works.
The benchmark is whatever they already use
People compared it to Framer and Wix, and my first instinct was that this was an unfair comparison — those are products with large teams, ours is an internal tool.
That instinct is irrelevant. Users compare you to what they have used. Arguing the comparison is unfair does not change who you are being compared to. The useful response is to work out which specific properties produce that feeling — direct manipulation, immediate feedback, no save-and-check cycle — and target those.
Opinionated beats flexible
Every configuration option added for an edge case makes the common path slightly worse. Ten of them and the tool is technically more capable and practically unusable by the person it was built for.
A CMS for non-developers has to be opinionated. That means saying no to requests that are individually reasonable, which is uncomfortable and correct.
The requirement worth protecting
Not "build a better CMS". A named person needs to add a gallery on a Tuesday without messaging anyone.
Requirements that concrete are rare. They are easy to design against, easy to test, and easy to know when you have met. They are also easy to lose to scope creep, which is why they are worth writing down and defending.