There's this recurring mistake I see early teams make: they pick a CMS way too early.
Not because they need one. Not because their content is complicated. But because they feel like a "real company" is supposed to have a CMS.
It's the same energy as buying Jira before you have 5 engineers, or setting up a microservice before you have users. It feels official. Mature. Professional.
But it's fake work.
And it slows you down.
This post is Part 4 of our publishing series, and it's probably the most blunt one:
Don't use a CMS until reality forces you to. Most teams don't need one. And you probably don't either.
1. CMS Complexity Creeps Up Slowly and Quietly
Here's the curve:
- 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 becomes the product you have to maintain.
Not the tool you use.
2. CMS Systems Are Designed for Companies That Already Have a "Content Department"
Look closely at any enterprise CMS marketing page:
- 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
- a legal team reviewing everything again
If you don't have that yet, you're building overhead before you have the team to need it.
3. Most Early-Stage Content Lives in Three Places: Your IDE, Your Head, or Your Repo
When you're small, content comes from:
- founders
- engineers
- product
- support
- whoever feels like writing that week
You aren't running a newsroom. You're building a product.
So why pick a tool built for newsrooms?
4. Writing Should Be Fast, Not "Structured"
The whole point of early-stage content is:
- communicate clearly
- ship quickly
- correct later
- move on
A CMS flips that energy:
- define model
- configure schema
- decide fields
- arrange layout
- create environment
- publish through abstraction
You end up spending more time setting up the publishing pipeline than actually publishing.
The best writing stacks make writing feel like thinking. A CMS makes writing 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:
- exports with weird block formats
- "portable text" that isn't portable
- HTML blobs with inline attributes
- API rate limits
- broken image references
- schema migrations that silently fail
- "upgrade your plan to unlock this feature"
At the exact moment when:
- you want to redesign the site
- you want to migrate to a new framework
- your content volume has grown
- you have no time to unravel technical debt
That's when your CMS taps you on the shoulder and says: "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)
- the "code world" (MDX, components, styling, deployment)
You now maintain a mental bridge between both.
Every change travels across two systems:
- content updates → CMS
- component updates → code
- schema updates → both
- workflows → CMS
- build pipeline → code
Early teams can't afford that cognitive tax. You need one world, not two.
7. Git + MDX + IDE Will Take You Much Further Than You Think
People underestimate how far you can get with:
- a repo
- MDX
- an IDE
- a few components
- a preview environment
- GitHub PR flow
It scales surprisingly well:
- blogs
- docs
- changelogs
- guides
- handbooks
- landing pages
- tutorials
- API examples
- even product marketing pages if you build a few MDX components
Many companies you admire still run on file-based stacks:
- Vercel
- Supabase
- PlanetScale
- PostHog
- Expo
These aren't "toy setups." They are running content at world-class scale.
8. There Will Be a Time to Add a CMS — But Let That Moment Arrive Naturally
You'll know it when:
- non-engineers need to ship content independently
- you publish across multiple frontends (docs + app + website)
- you need localization / scheduling / workflows
- your content model is truly richer than Markdown
- a dedicated content team exists
- schema-based relationships actually matter
At that point:
- Git-based CMS (Keystatic, Tina, Decap) → Good first step. Adds UI without losing portability.
- Headless CMS (Sanity, Payload) → Only when you need cross-surface, omnichannel, or rich models.
But if you add any of these before you need them? They slow you down and trap you.
9. The Real Reason: You're Early. Stay Nimble.
A CMS is structure. Structure is stability. Stability is efficiency. Efficiency is for late-stage companies.
Speed is for early-stage companies. And speed comes from removing structure until the moment it stops working.
So 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.
