apps/web/content/articles/choosing-a-cms.mdx
If you're building a blog, docs, or a knowledge base in 2026, the options are overwhelming.
Sanity or Payload? Nextra or GitBook? Git-based CMS like Keystatic? Or just raw MDX in GitHub with zero CMS at all?
We went through the same decision for Char. This post maps the territory so you don't have to burn as many cycles on it.
I won't tell you "X is the best CMS." Instead, I'll show you what each category is good at, what it quietly locks you into, and when you probably don't need a CMS at all.
This is Part 3 of our publishing series.
Start by answering these questions instead:
Who is writing most of the content?
What are you publishing?
How often does content structure change?
How long should your content survive?
Once you answer these, the CMS choice mostly falls out.
At Char, content lives as .mdx files in the repo. We write in Zed / Cursor / VS Code. GitHub is the CMS. PRs are drafts, merges are publish. CI handles link checking, OG generation, and so on.
Pros:
Cons:
If your team is very technical and you're early-stage, this is almost always the correct default. You can always add a Git-based or headless CMS later without throwing anything away.
Git-based CMS tools give you a visual editor that talks directly to your Git repo. Content stays as Markdown/MDX/JSON/YAML in the repository, but non-technical people get a web UI.
Keystatic makes Markdown, JSON, and YAML content in your codebase editable via a browser UI, and syncs changes directly to GitHub or the local file system without introducing a separate database.
Other players include TinaCMS, Decap, and similar tools.
Pros:
Cons:
Use this when you like the Git + MDX approach but want PMs, designers, or marketing to tweak copy and metadata without opening an IDE.
Headless CMS = content backend with APIs. You define schemas, models, relationships, and the CMS exposes content via REST/GraphQL to web, mobile, native apps, signage, whatever.
Sanity offers a composable "Content Cloud" with an open-source Studio built in React/TypeScript, highly customizable for flexible content modeling. Sanity
Content is stored in their Content Lake as structured JSON, not HTML, so you can reuse it across multiple frontends. It provides real-time collaboration, visual editing, and omnichannel delivery.
Payload is a dev-first, code-first headless CMS built with Node.js, TypeScript, and React, positioning itself as a Next.js-native backend framework. Payload
You configure everything in TypeScript. It's open-source (MIT) and self-hostable. It can function as a headless CMS, app framework, or digital asset management layer. It fits naturally into a modern JS/TS stack with Next.js projects.
Pros of headless CMS:
Cons:
Use this when you're running a content platform with multiple surfaces, locales, and non-technical editors who need structured workflows.
Sometimes you don't need a CMS. You need a docs product.
GitBook positions itself as a documentation + knowledge base platform for technical teams, with a polished block-based editor, site customization options, and Git Sync that lets you connect to GitHub/GitLab for a docs-as-code workflow. GitBook
It works well if you want a hosted, beautiful docs site with search, navigation, versioning, and collaboration. It supports optional Git synchronization for teams that still want Markdown in repos.
Notion, Confluence, and similar tools live in the same category but less focused on developers.
Pros:
Cons:
Use this when you want a docs site ready tomorrow, UX matters more than control, and you don't mind long-term platform dependency.
| Bucket | Best For | Pros | Cons | Examples |
|---|---|---|---|---|
| No CMS (Git + MDX) | Technical teams, engineers writing content | Maximum portability, no vendor lock-in, diffable/reviewable, perfect IDE integration | No visual UI, non-technical users need training | Plain MDX in GitHub |
| Git-Based CMS | Mixed teams needing visual UI while keeping content in Git | Content-as-code benefits + visual editing, portable files, non-engineers can edit | Extra admin app to host, tied to their config models | Keystatic, TinaCMS, Decap |
| Headless CMS | Multi-channel content platforms with complex workflows | Powerful schema modeling, omnichannel delivery, great editorial UX, localization | Infrastructure complexity, proprietary content structure, migration cost | Sanity, Payload |
| Docs Platforms | Teams needing polished docs/KB sites fast | Fastest setup, beautiful out-of-box, low infra cost, non-tech friendly | Limited portability, harder product integration, platform dependency | GitBook, Notion, Confluence |
Tools like Nextra are not CMS platforms but content-focused frameworks built on Next.js that make it easy to build docs and blog sites with Markdown/MDX and opinionated themes. Nextra
Nextra gives you prebuilt docs/blog UI (sidebar, nav, search glue), MDX-first authoring, and works well for developer docs and personal blogs.
You still choose how to manage content: plain files, a Git-based CMS, a headless CMS feeding MDX remotely, etc.
This is the category Char's stack resembles: modern React/MDX frontend with content-first in Git.
| Situation | Likely Best Choice |
|---|---|
| Small, technical team, mostly engineers writing | Git + MDX, no CMS |
| Technical team, but PMs/design/marketing need to edit copy | Git-based CMS (Keystatic/Tina/etc.) |
| Product needs content across web, app, marketing, multiple locales | Headless CMS (Sanity, Payload, etc.) |
| You just need a docs/KB site ASAP | Docs platform (GitBook, maybe Notion early) |
| You want fine control over UI + MDX, but not heavy infra | Nextra or similar framework on top of Git |
If you're not sure, default to Git + MDX now. Add a Git-based or headless CMS later only if reality forces you to.
Most teams overestimate how much CMS infrastructure they need in the first 2–3 years.
Headless CMS and hosted doc platforms feel great in the first year. Export and migration problems show up right when you least want to deal with them: when the product is working and you're stretched thin.
Plain files in Git are boring. Boring is good.
If your team writes in Markdown/MDX in Git, your culture becomes "open a PR," "leave a comment," "fix it in the repo."
If your team writes in a SaaS editor, your culture becomes "who has access?", "which space is that in?", "did the integration break again?"
Neither is inherently right, but they lead to different organizations.
Today your blog might be the founder and engineers. In two years, it might be devrel, marketing, product, and support.
Choosing a stack that evolves from IDE-only → Git-based CMS → headless CMS with minimal rewriting matters.
Git + MDX is a good foundation for that.
For a technical founder starting a new product:
That's basically Char's philosophy: start with the simplest thing that respects developer workflows, portability, and long-term ownership.
The tools will change. Your content shouldn't have to.
This is Part 3 of our publishing series.