The CMS choice that doesn't sabotage you in year two

Why this decision is sticky

A CMS isn't a library you can swap. The content lives inside it, the publishing workflow grows around it, and the team builds muscle memory in its editor. Moving off one is the kind of project nobody schedules and everyone postpones. So the choice in week one is doing a lot of work, quietly, for years.

Which means the right question isn't 'which CMS has the prettiest demo' — it's 'which one will I still be able to live with when the team is twice the size and the content has 10x more shape than today.'

What we actually pick

Sanity, for most teams that publish more than a homepage. The schema lives in code, which means content shape is reviewed in PRs instead of changed in a settings panel at 11pm. The editor is good enough that non-technical people use it without us holding their hand. The migration story when something needs to change is the best we've worked with.

Payload, when the project is small and the team is comfortable in TypeScript. Self-hosted, runs alongside the rest of the stack, no second vendor to pay. The admin UI is enough for a content team of one to three. Above that, the limits start to show.

Markdown in the repo, when there are no non-developer editors. Honestly the right answer more often than people admit. If three engineers write all the content and ship it through pull requests, you don't need a CMS — you need a `content/` folder and a deploy hook. Total operational cost: zero.

What we keep refusing

• WordPress as the source of truth for a new product in 2026. The plugin ecosystem is the trap. Two years in, you have eleven plugins, three of them abandoned, and an upgrade path that requires a weekend.
• A custom-built CMS for a non-CMS company. Every founder thinks theirs will be the exception. Every founder is wrong. The maintenance burden eats the team that built it.
• Whatever the marketing site builder is offering as a 'headless' bolt-on. The 'headless' usually means 'we wrap our editor in a REST API.' The shape of the content is still defined by their UI, which means you've bought a CMS without the part that matters — schema control.

The questions we ask before we pick

• Who edits content — engineers, marketers, or both?
• How often does the content *shape* change, not just the content?
• Does the site preview live, or do editors ship blind?
• Is there a localization story — even a stub of one?
• What happens if the vendor doubles their price next year?

That last one matters more than people expect. We've seen two clients eat a 4x price hike from a 'starter' CMS the day they crossed an arbitrary entry-count threshold. The migration was more expensive than just paying.

The preview question deserves its own paragraph

If editors can't see what their changes look like before publishing, they will publish broken pages. Not occasionally — routinely. Live preview against staging is the single feature we will not ship a content site without. It costs an afternoon to wire and it's invisible until the day a marketer dodges a launch-day mistake because of it.

The lesson

A CMS choice is a bet on year two, not week one. Pick the one whose limits show up later, whose schema lives where the rest of your code lives, and whose price doesn't punish success. Get this one right and content stops being a topic in standup. Get it wrong and it becomes the topic.