There's a recurring mistake I see early teams make: they pick a CMS way too early.
They adopt one because it feels official, not because they need it or because their content is genuinely complicated. It's the same instinct that leads to setting up Jira before you have 5 engineers, or building a microservice before you have users. The structure feels mature and professional.
But it's unnecessary work that slows you down.
This post is Part 4 of our publishing series, and it's probably the most direct one: don't use a CMS until you actually need one. Most teams don't, and you probably don't either.
1. CMS Complexity Creeps Up Slowly and Quietly
The trajectory looks like this:
- Day 1: "Let's use Sanity/Payload/GitBook, it looks nice."
- Month 3: "Our schema is getting a little complicated…"
- Month 9: "Why can't we just add this tiny field without breaking the entire model?"
- Month 12: "Migration failed. Again."
- Month 24: "Wait… can we ever leave this platform?"
The CMS stops being a tool and becomes another product you have to maintain.
2. CMS Systems Are Designed for Companies That Already Have a "Content Department"
Look at any enterprise CMS marketing page and you'll see: roles, permissions, workflows, approvals, locales, rich schemas, omnichannel delivery, asset pipelines, collaborators, audit logs.
That's not for a team of three founders and one designer. That's for companies that already have a PM writing specs, a marketing team writing pages, a content manager building assets, an editor reviewing drafts, and a legal team reviewing everything again.
If you don't have that structure yet, you're building overhead before you have the team to justify it.
3. Most Early-Stage Content Lives in Three Places: Your IDE, Your Head, or Your Repo
When you're small, content comes from whoever feels like writing that week: founders, engineers, product people, support. You're building a product, not running a newsroom. So why use a tool designed for newsrooms?
4. Writing Should Be Fast, Not "Structured"
Early-stage content has one job: communicate clearly, ship quickly, correct later, and move on.
A CMS inverts this. You spend time defining models, configuring schemas, deciding fields, arranging layouts, creating environments, and publishing through abstraction layers. You end up spending more time setting up the publishing pipeline than actually writing.
The best writing stacks make writing feel like thinking. A CMS makes it feel like filing a ticket.
5. CMS Lock-In Hurts Exactly When You Don't Have Time
You don't feel lock-in in Month 1. You feel it in Year 2 when you want to redesign the site, migrate to a new framework, or reduce technical debt—and you discover exports with weird block formats, "portable text" that isn't portable, HTML blobs with inline attributes, API rate limits, broken image references, and schema migrations that silently fail.
That's when your CMS quietly tells you: "By the way, you can't leave."
6. Every CMS Introduces a Second Reality
A CMS creates two worlds: the content world (editor UI, schema models, drafts) and the code world (MDX, components, styling, deployment). You maintain a mental bridge between both, and every change travels across two systems.
Early teams can't absorb that cognitive cost. You need one world, not two.
7. Git + MDX + IDE Will Take You Much Further Than You Think
File-based stacks scale well:
- a repo
- MDX files
- an IDE
- a few components
- a preview environment
- GitHub PR flow
You can build blogs, docs, changelogs, guides, handbooks, landing pages, tutorials, API examples, even product marketing pages. Companies like Vercel, Supabase, PlanetScale, PostHog, and Expo still run on file-based stacks at world-class scale.
8. There Will Be a Time to Add a CMS — But Let That Moment Arrive Naturally
You'll know you need one when non-engineers need to ship content independently, you publish across multiple frontends, you need localization or scheduling, your content model is richer than Markdown, a dedicated content team exists, or schema-based relationships actually matter.
At that point, consider a git-based CMS like Keystatic, Tina, or Decap as a first step—they add UI without losing portability. Move to a headless CMS like Sanity or Payload only when you need cross-surface, omnichannel, or truly complex models.
But add either before you need it, and they'll slow you down and trap you.
9. You're Early. Stay Nimble.
A CMS is structure. Structure is stability. Stability is for late-stage companies. Speed is for early-stage companies, and speed comes from removing structure until the moment it stops working.
Don't over-engineer your publishing stack. Don't imitate companies 100x your size. Don't install enterprise workflows into a tiny team.
Just write and ship in the simplest system that respects your time. You can add complexity later. You cannot subtract it.
This is Part 4 of our publishing series.
