Choosing a CMS is a vendor decision disguised as a tooling decision. Here are five things no CMS should do: generating code that doesn't follow best practices, allowing unregulated clutter in the dashboard, restricting content portability, prioritizing features over stability, and failing to communicate with users.
For PMs running web or content-heavy projects, that list doubles as a vendor scorecard.
What happened
- Non-standard code output is a maintenance tax.
- Dashboard clutter compounds as plugins accumulate.
- Restricted portability is a lock-in signal.
- Feature velocity without stability is an incident risk.
- Poor vendor communication is a relationship risk.
Why this is a vendor decision, not a tooling decision
Most CMS evaluations run as tooling decisions. The team reviews features, pricing, and a demo. The vendor decision never gets made—until the day pricing changes, a release breaks, or support goes silent. Then the team is locked in and the budget is spent.
Each of these five red flags is a delivery risk in disguise. Non-standard code creates a maintenance burden. Dashboard clutter incurs a usability tax. Restricted portability is a switching cost. Feature-first stability is an incident risk. Poor communication is a relationship risk.
The five red flags in practice
The first red flag is code output that ignores web standards—using tables for layout or HTML font tags for styling instead of semantic markup and CSS. Some proprietary systems still do this, leaving creators with inaccessible, outdated markup.
The second is an unregulated dashboard. As themes and plugins accumulate, dashboards become cluttered with widgets and nagging notifications. WordPress, being open-source, has limited control over notification behavior. Proprietary systems without third-party plugins can maintain cleaner interfaces—but some cross the line into aggressive upsells.
The third is restricted content portability. Proprietary systems often prevent content export entirely. Even staging copies may be impossible. Some functionality—shopping carts, for instance—reasonably resists export. But basic content portability should be standard.
The fourth is prioritizing features over stability. New features matter, but big changes can break specific functionality or entire websites if edge cases aren't accounted for. An app with a reputation for breaking sites won't retain users.
The fifth is failing to communicate. Users need to know about features and changes to use them effectively. Vendors need user feedback to prioritize fixes and development. This requires ongoing effort in documentation, support, and community building. When it breaks down, relationships erode.
Who catches these early, and who pays later
PMs who run a vendor scorecard before the sprint plan catch these early. PMs who ask the portability question during the demo—not after the contract—catch these early.
PMs who treat the CMS as settled once the site launches pay later. PMs who discover dashboard clutter after six months of plugins pay later.
The trade-off: fewer demos focused on features, in exchange for fewer post-launch surprises.
The scorecard habit
Before a demo, write a one-page scorecard. Use the five items as columns, candidates as rows. Weight portability and stability above feature sets. Share it with the team before the demo. One scorecard. One new habit.
What to watch next
Watch for two signals. First, whether your CMS evaluation included the portability question. Second, whether your vendor communicated breaking changes before or after they hit production. The first reveals whether the team owns vendor risk. The second reveals whether the vendor owns the relationship.
Key takeaways
- CMS choice is a vendor decision, not a tooling decision.
- Portability and stability outweigh feature velocity.
- Dashboard clutter is a usability tax that compounds over time.
- A red-flag scorecard beats a feature checklist.
- Run the scorecard before the demo, not after.
Frequently asked questions
What's the most expensive CMS red flag?
Restricted content portability is among the most expensive, because switching platforms becomes nearly impossible and forces reliance on third-party tools or manual migration.
Why is dashboard clutter a red flag?
Dashboards should be minimal and customizable. Clutter from plugins and notifications reduces usability and concentration over time, creating a compounding usability tax.
Are feature updates always good?
No. Prioritizing features over stability can break websites when edge cases aren't accounted for. Stability and backward compatibility should come first.
What should PMs ask CMS vendors before signing?
At minimum: how is content exported, what is the stability track record, and how are breaking changes communicated to users.