Why I Skipped the CMS

Every content site hits the same question early: where does the content live? The default answer in 2026 is a CMS. Headless, traditional, git-based, API-driven - the options are endless. I evaluated several of them seriously. Then I chose none of them.

This is not a rant about CMSes being bad. They solve real problems for real teams. But for a content site run by one person, every CMS I tested created more work than it saved.

The tools I actually evaluated

I spent time with five platforms, ranging from open-source and self-hosted to fully managed SaaS:

Decap CMS (formerly Netlify CMS). Git-based, open source, designed to sit on top of a static site. No server required. Sounds perfect on paper. In practice: the editor is clunky, the widget system is limited, the project's maintenance has been inconsistent, and configuration is fiddly enough that you spend more time debugging the CMS than writing content. For a solo operator who already knows Markdown, Decap adds a UI layer without adding value.

Directus. Open-source, self-hosted, database-backed. Beautiful admin panel. But self-hosted means I'm running a server, managing a database, handling backups, and patching security updates. For a content site that publishes a few articles a month, that's like leasing a warehouse to store a shoebox.

Strapi. Similar story to Directus. Powerful, flexible, well-documented. Also requires hosting, a database, and ongoing maintenance. The managed cloud option (Strapi Cloud) starts at $29/month. That's $348/year to manage content I can manage for free in a text editor.

Sanity. Hosted, real-time, excellent developer experience. The free tier is generous. But it introduces a build dependency on an external API, a custom query language (GROQ), and a content model that lives outside your codebase. If Sanity changes pricing, goes down, or sunsets a feature, your content pipeline breaks. For a team of five shipping a product with complex content relationships, that tradeoff makes sense. For a solo blog, it's risk without reward.

Contentful. The enterprise standard. Polished, reliable, expensive. The free tier caps at 5 users and 25,000 records, which is fine for a blog, but the content modeling is designed for teams with dedicated content strategists. The API-first approach means every page load depends on an external service. Same dependency risk as Sanity, with a higher price ceiling.

What I use instead

Markdown files in a folder. That's it.

Each article is a .md file with frontmatter (title, description, date, tags) and standard Markdown body. A build script reads them, converts them to HTML, and outputs static pages. The whole pipeline is one JavaScript file with zero CMS dependencies.

content/articles/
          why-i-skipped-the-cms.md
          how-this-blog-works.md
          ...14 more files
        

No admin panel. No database. No API calls. No login screen. No content model to configure. No plugin ecosystem to navigate. No vendor to depend on.

The actual cost comparison

Here's what each approach costs to operate for a site that publishes 2-4 articles per month:

The "free" options aren't really free. They cost time: learning a content model, configuring an editor, debugging API integrations, migrating when the vendor changes direction. For a team where content authors aren't developers, that time investment pays off. For a solo builder who writes in a text editor anyway, it's overhead with no return.

The objections (and honest answers)

"But you don't get a nice editor." True. I write in a text editor. For me, that's faster than any web-based editor because I already live in my editor all day. If I needed to hand content authoring to a non-technical person, this approach would not work. I'd probably reach for Sanity or Tina in that case.

"But you can't schedule posts." Also true. I publish by committing a file and pushing to git. Netlify builds automatically. If I needed scheduled publishing, I'd add a publishDate field to frontmatter and filter in the build script. Ten lines of code, no CMS needed.

"But what about content relationships and taxonomies?" Frontmatter handles tags. The build script handles sorting, filtering, and cross-linking. For 15 articles, this is more than enough. At 500 articles, I might reconsider. But building for 500 articles when you have 15 is a classic case of solving problems you don't have yet.

"But what if you need to collaborate?" Git handles collaboration. Pull requests handle review. This is the same workflow developers already use for code. Adding a CMS to enable collaboration is only necessary when your collaborators aren't comfortable with git, which is a fair constraint for many teams, but not mine.

When a CMS is the right call

I want to be clear: CMSes exist for good reasons. You should probably use one if:

• Non-technical people need to publish content. A marketing team shouldn't need to learn git. That's what Sanity, Contentful, and similar tools are for.
• Content has complex relationships. Product catalogs, multi-language sites, content that feeds multiple channels. A CMS with a proper data model saves real time here.
• You need granular permissions. Editor, reviewer, publisher roles. Draft states. Approval workflows. These are real requirements for organizations, and a CMS handles them better than git branches.
• Publishing volume is high. If you're shipping 20 pieces of content a week across multiple authors, the editorial workflow a CMS provides is worth the cost.

None of those describe my situation. I'm one person publishing a few articles a month. The simplest tool that works is the right tool.

What this means for small teams

If you're a solo builder or a small team where everyone is comfortable with Markdown and git, seriously consider skipping the CMS. The time you'd spend evaluating, configuring, and maintaining one is time you could spend on the product.

The content pipeline for this site is a single build script that reads Markdown files and outputs HTML. It took an afternoon to write. It has no dependencies to update, no vendor to negotiate with, and no admin panel that could get hacked. The content is version-controlled, diffable, and portable to any platform.

That's not the right answer for every project. But for a content site run by one person who already knows how to write Markdown, it's hard to beat.