Development
Your CMS Is a Staffing Decision
The launch team won't edit it.
The people in the room when the CMS is chosen — the developer, the project manager, the consultant with the vendor preference — are the exact people who will not be editing the site in year three. They will have moved on. The editor in year three is someone who has not been hired yet: maybe a communications coordinator, maybe a department assistant, maybe a director who types fast but does not know what a block editor is.
A CMS feature comparison tells you what the system can do when a developer is driving. It tells you nothing about what a coordinator can do alone on a Tuesday when the developer is unavailable and the homepage needs to change before the board meeting. The launch team optimizes for build speed. The year-three editor optimizes for not calling IT. Those are different requirements, and only one of them matters after go-live.
The launch team optimizes for build speed. The year-three editor optimizes for not calling IT. Those are different requirements, and only one of them matters after go-live.
The question is who, not what.
Most CMS evaluations end up as feature grids: custom post types, multisite support, REST API access. These are legitimate technical questions, and they belong to the developer. The editor in year three is asking different ones: whether she can add a staff member without breaking the layout, change a phone number without touching code, publish an event and have it land in the right place. A system built to answer the developer's list and not the editor's has failed at its primary job.
After twenty-one years of institutional sites, the pattern is consistent: organizations that frame the CMS decision around their editors make fewer mid-cycle replacements. The conversation that needs to happen is not about which platform has more plugins. It is about whether the person who will own the content in year three can use the tool you are about to choose for her.
Governance is the real deliverable.
The CMS decision is a governance decision. It determines whether the organization owns its site or merely rents access through a developer relationship. When the system matches the editor, content gets updated. When it does not, the site drifts: the events page goes stale, the staff directory runs a season behind, the homepage still promotes something that ended in March. Drift is not a content problem. It is a tooling problem that presents as one.
A well-matched CMS with a structure built to hold after the launch team leaves means a site that stays current without a ticket queue. A mismatched one means a developer relationship that never ends, billed by the hour, for work that should not require a developer. The decision is made once. The cost or the confidence is paid every week for as long as the site runs.
Before comparing features, write down the name of the role that will edit the site in year three. Not the person: the role. If that role is communications coordinator, program manager, or executive assistant, the CMS needs to work for that person without training wheels or a developer on call. That is the conversation to have before the demo. The feature grid comes after. The staffing picture comes first, because the staffing picture is the one that will still be true when everyone else has moved on.