If you’ve decided to move to a headless CMS, or you’re seriously considering it, the next question is brutal: how do you evaluate the options without locking yourself into a six-figure mistake?
The headless CMS market has grown from a niche developer concept into a mature industry with dozens of options. That’s good news (competition drives quality) and bad news (the research phase can be paralyzing, and the cost variance between patterns is enormous, anywhere from $0 to $300,000+ over five years for what looks, on the surface, like the same category of product).
This isn’t a tool-by-tool comparison. It’s an evaluation framework, focused on the architectural patterns and the criteria that matter to the marketing leaders, content teams, and CTOs who will live with this choice every day. We’ve built production sites across all three patterns. We know what works, what doesn’t, and where each pattern is genuinely the best fit.
What are the three questions that matter when choosing a headless CMS?
Every headless CMS decision comes down to three questions:
- How will my marketing team create and manage content? (The editing experience)
- How much control do we want over our data and infrastructure? (The ownership model)
- What does this cost, now and in five years? (The economics)
Everything else (API speed, developer experience, plugin ecosystem) is downstream of these three. The same three questions apply across every headless CMS pattern. What changes is the answer.
There are three patterns to evaluate against those questions. Pick the pattern first; pick the vendor second.
Pattern 1: Hosted API-driven CMS
The dominant pattern in the headless CMS market. A vendor-hosted platform stores your content in their database and serves it through an API. The editor app is hosted by the vendor, sometimes with a customizable studio you can extend. Editorial polish is the highest of the three patterns. Real-time collaboration is built in. Enterprise governance (SSO, audit trails, approval workflows, multi-market localization) is the most mature.
Sanity and Contentful are the leading examples of this pattern.
The editing experience
Hosted API-driven CMS lead the market on editorial polish. Multiple editors work on the same document simultaneously, with presence indicators showing who’s editing what. It feels like Google Docs for your CMS. Visual editing (clicking directly on elements on the live site to edit them) has largely closed the gap with traditional WYSIWYG editors.
Structured content modeling is the strongest in the market. You define exactly what content types exist, what fields they have, and how they relate to each other. This structure pays dividends in content reuse, consistency, and, increasingly, AI readiness. Well-modeled content is an appreciating asset. Some vendors in this pattern store rich text as structured data (not HTML blobs trapped in proprietary formats), which means your content investment is genuinely portable: reusable across channels, easy for AI to parse and optimize, and never held hostage by a vendor’s export limitations.
The trade-off is that the initial setup is developer-driven. Your dev team configures the content model and the studio before the marketing team uses it. The flexibility can also be overwhelming; there are many ways to model the same content, and making good modeling decisions early prevents refactoring later.
Mature platforms in this pattern also bring enterprise governance out of the box: content workflow stages (Draft → In Review → Approved → Published) with role-based permissions, first-class multi-language support, and large integration marketplaces for DAM, experimentation, and translation tooling. The trade-off there is rigidity; those governance features come with opinions about how content operations should run, which is the right answer for some teams and a constraint for others.
The ownership model
Your content lives on the vendor’s cloud infrastructure. You don’t manage servers or databases. Some platforms in this pattern offer an open-source studio (the editing interface) that you host yourself, an unusual hybrid where the content is managed by the vendor but the editor app is yours to customize and deploy. Others are fully closed-source SaaS, where you extend the editor through a vendor-controlled app framework rather than customize it directly.
Your content is an asset on your balance sheet, not a sunk cost in someone else’s ecosystem.
Content is accessible through the API and exportable at any time. The structured-data approach removes the proprietary-format lock-in of legacy CMS (no migration fees, no re-entry costs to escape a closed format). Your content is an asset on your balance sheet, not a sunk cost in someone else’s ecosystem. The dependency you keep is on the vendor’s runtime, not on a closed content format, and on the closed-source platforms inside this pattern, you’re still renting access to the editing tool itself, which matters when renewal negotiations come around.
The economics
Hosted API-driven CMS (5-year cost range): $0 (free tier for small teams) to $300,000+ (enterprise plans with multi-market localization, SSO, and custom SLAs). The variability is enormous because vendors price by team size, content volume, and feature gating.
Most mid-market teams land somewhere in the middle. Smaller teams start free and grow into a per-user pricing tier running $45–$150/month depending on team size, pricing that’s user-based, not seat-based with feature gates, and usage-based above the included limits. Larger organizations on enterprise plans negotiate annual contracts that can run $2,000–$5,000+/month once SSO, custom roles, and multiple spaces become requirements.
The most common complaint about this pattern is the cost ceiling. The jump from free to paid is significant, and enterprise pricing can approach legacy CMS levels, meaning you’ve reduced technical lock-in but not financial lock-in.
Where this pattern wins
When the editorial workload is heavy (multiple content types, complex relationships, content reused across channels), the team is collaboration-heavy (multiple editors working in parallel), and AI readiness matters (structured content compounds in value as agent-driven content operations grow). Also when enterprise governance (SSO, audit trails, approval chains, multi-market localization) is a binding constraint that can’t be negotiated.
Pattern 2: Self-hosted open-source CMS
A database-backed CMS like the first pattern, but the CMS software itself is open source (typically MIT-licensed) and runs on infrastructure you control. The content lives in a database you own (MongoDB, PostgreSQL). The admin app is generated from a content model you define in code. Ownership is maximum: you own the software, the data, and the runtime.
Payload and Strapi are the leading examples of this pattern.
The editing experience
The admin panel is generated from your content model, a code configuration that defines content types, fields, relationships, and access control. The interface is clean, fast, and functional. Because the CMS runs on your own infrastructure, content operations feel instantaneous, no network round-trips to a third-party API.
Authentication, access control, file uploads, image resizing, drafts, versions, live preview, all built in. You’re not assembling plugins. The UI patterns feel familiar to anyone who’s used a modern web application: lists, filters, bulk actions, inline editing.
The trade-off is that the admin app is less customizable than the leading hosted studios. You can extend it, but you’re working within the pattern’s design conventions rather than building a custom interface. Content modeling is also code-first, defined in TypeScript or another language, not in a visual UI. Marketing teams use the admin panel; developers define its structure.
Self-hosting also means responsibility. Your team (or your agency) owns uptime, backups, and security. For teams with infrastructure expertise, that’s a feature. For teams without it, it’s a concern that has to be planned around, usually by paying an agency or a managed-hosting tier.
The ownership model
This is the maximum ownership position in the headless CMS landscape. You own the CMS software (open-source license, typically MIT, the most permissive). You own the database. You own the infrastructure. There is no hosted version you’re renting access to.
If the vendor disappeared tomorrow, your CMS would continue to run. No sunset risk, no forced migration, no emergency procurement cycle.
If the vendor company behind the project disappeared tomorrow, your CMS would continue to run. No sunset risk, no forced migration, no emergency procurement cycle. Your content, your code, your infrastructure, your data, all of it is on your balance sheet, not a vendor’s recurring revenue line.
Self-hosted open-source CMS in this pattern also often double as application frameworks. Built-in authentication, access control, API generation, and database management mean you can build your CMS and your backend in the same codebase. For teams running on a modern JavaScript runtime, the integration between the CMS and the site can be the tightest in the market, one team, one skill set, no key-person risk from proprietary expertise. The largest developer talent pool in the world (JavaScript/TypeScript) can maintain the system.
The economics
Self-hosted open-source CMS (5-year cost range): $600 to $15,000, almost entirely hosting and infrastructure. The CMS software is free. You pay for the servers it runs on, which on a competent VPS provider runs $10–$100/month for most production environments. Managed hosting from the project (if available) starts higher but offloads infrastructure responsibility.
Even at the high end with managed hosting and redundant infrastructure, total cost stays well below $20,000 over 5 years. Compare that to enterprise SaaS at $300,000+ over the same period and the leverage is obvious, though the operational responsibility is also yours.
Where this pattern wins
When ownership is a non-negotiable priority, developer resources exist (internal or agency), and the team values consolidation, one codebase, one skill set, no key-person risk from proprietary expertise. Particularly strong when the rest of the stack runs on the same JavaScript runtime as the CMS.
Pattern 3: Git-based CMS
A fundamentally different architecture. Content lives as files (MDX, Markdown, JSON, YAML) directly in your git repository. The editor commits to git on save. There’s no database. No API tokens. No recurring CMS bill. The “head” is your site framework reading content from disk at build time.
Keystatic and TinaCMS are the leading examples of this pattern.
The editing experience
The editing UI commits directly to a branch when an editor saves. Marketing operates a structured editor (fields, content types, image uploads) and the underlying mechanics are git rather than a database. Visual previews and inline editing exist in the more mature options. The experience feels different from the API-driven patterns: less real-time, more deliberate, more aware that “saving” is “committing.”
The trade-off is collaboration mode. Multiple editors working on the same document simultaneously, presence indicators, instant conflict resolution, that’s the API-driven story. Git-based collaboration is branch-based: you edit on a branch, the system handles diffs, merge conflicts surface like they would for code. Modern git-based options have softened this, but for very large editorial teams, it’s still the principal limitation.
The ownership model
Maximum ownership in a different shape than self-hosted open-source. The content lives in your repo, not a database you operate. There’s no CMS runtime to maintain; the site framework reads the files at build time. AI agents can author and edit content the same way a developer would, by opening a pull request. That makes this the most agent-friendly editorial pattern in the market today.
The lock-in surface is also the smallest of the three patterns. If you abandon the editor tool tomorrow, your content is still in your repo as files you control, in formats (MDX, Markdown) read by every modern web framework. You’re not migrating a database. You’re not exporting from a vendor. The content is already where it needs to be.
The economics
Git-based CMS (5-year cost range): $0 to $1,800. The CMS software is open source and free. If a managed backend tier exists for collaboration features or media handling, it’s typically $0–$30/month. There is no recurring CMS bill in the legacy sense; your hosting cost is the cost of running your website, which you’d pay regardless of CMS pattern.
This is the cheapest pattern by a wide margin, and the gap widens at scale. A 10-person editorial team on a hosted API-driven CMS at the growth tier costs more in a single month than git-based costs over five years.
Where this pattern wins
When the content surface is moderate (blogs, marketing pages, documentation), ownership is a priority, and minimum operating cost matters. Also when AI-agent editorial is a strategic asset; git-based is the only pattern where agents author content with the same primitives developers do.
We chose a git-based pattern for this very library; every article you’re reading lives as MDX in our repo, edited through Cursor by humans and AI agents alike. That’s the trade-off we’ve stress-tested in production.
How do the three patterns compare on cost and ownership?
| Pattern | 5-year cost range | What drives the cost | Ownership |
|---|---|---|---|
| Hosted API-driven CMS | $0 – $300,000+ | Team size, content volume, feature tier | Vendor’s runtime |
| Self-hosted open-source CMS | $600 – $15,000 | Hosting and infrastructure only | Yours |
| Git-based CMS | $0 – $1,800 | Optional managed backend | Yours (in your git repo) |
| Enterprise SaaS CMS (incumbent reference: HubSpot Content Hub Enterprise) | ~$105,000 (Lynton modeling, 8% escalator on $18,000/year list) | Bundled licensing | Vendor’s |
The gap between the cheapest pattern and the most expensive spans two orders of magnitude. The wrong pattern locks you into the high end. The right pattern lets you redirect the difference into pipeline experiments, AI integration, or any capability the legacy vendor’s roadmap won’t reach for the next three years.
Why is git-based CMS gaining traction?
The three patterns above all decouple content from rendering; that’s what makes them “headless.” Git-based is the most architecturally different of the three: it removes the database entirely.
The trade-off is clean. Git-based wins on operating cost (no database, no recurring CMS bill) and ownership (content in version control). It also opens the most agent-friendly editorial workflow available today: AI agents author content via pull request, the same way a developer does. It loses on real-time collaboration (branch-based, not Google-Docs-style) and enterprise governance. The pattern fits moderate content surfaces; it doesn’t scale to complex multi-channel operations.
For content-driven marketing sites (blogs, marketing pages, documentation), git-based is a legitimate alternative to the API-driven patterns. For complex content models reused across many channels, the API-driven patterns still win.
For the architectural distinction in depth, see What is a headless CMS?. For the broader stack context, see the open-source stack guide.
Which architectural pattern fits which team?
We’ve built production sites across all three patterns. The choice is about which pattern matches your team profile; the specific vendor inside the pattern is the next decision down, and the one we make as part of an engagement, not in a published listicle.
For most mid-market marketing teams: hosted API-driven. Best balance of editorial polish, content modeling, and AI readiness without the operational burden of self-hosting. The free or growth tier covers most teams under 10 editors. Choose this pattern when the editorial workload is heavy and collaboration is constant.
For teams with strong ownership requirements: self-hosted open-source. When ownership is non-negotiable and developer resources exist (internal or agency), this is the pattern. Particularly strong when the rest of the stack runs on the same JavaScript runtime as the CMS, so the integration is the tightest possible.
For enterprise organizations with complex governance: hosted API-driven at the enterprise tier. When SSO, multi-market localization, audit trails, and approval chains are binding constraints, the enterprise tier of the API-driven pattern is built for it. Budget accordingly; this is where the $300,000+ ceiling lives.
For content-driven sites where ownership and minimum cost matter most: git-based. Content lives in your repo, no recurring CMS bill, the most agent-friendly editorial workflow available today. The pattern we use for this very library.
We don’t have a financial relationship with any of the vendors in this space; the recommendation is fit-driven. The choice you’re making is the pattern. The specific vendor inside the pattern is a downstream decision, shaped by the same three questions and a few additional ones (vendor stability, ecosystem maturity, your team’s existing skills) that are easier to answer once the pattern is locked in.
What decision are you actually making when you choose a CMS?
Choosing a headless CMS isn’t just a technology decision. It’s a decision about how you want to operate for the next 3–5 years.
The 35% of enterprises that have already replaced a SaaS tool didn’t start with their CRM. Many of them started here, with the CMS.
Do you want your content locked in a proprietary format, a sunk cost that depreciates inside a vendor who raises prices every year? Or do you want structured, portable content that works with any frontend, any AI tool, and any future channel you haven’t thought of yet, an appreciating asset that compounds in value as AI capabilities grow?
The 35% of enterprises that have already replaced a SaaS tool (Retool, 2026) didn’t start with their CRM. Many of them started here, with the CMS. Because the content layer is the foundation everything else is built on, and freeing it from vendor lock-in creates leverage across your entire stack.
Pick the pattern that matches your team, your values, and your ambitions. Then evaluate the specific vendor inside the pattern. The pattern is the architectural decision; the vendor is the procurement decision. Most teams get those two backwards and pay for it for five years.
Related reading
- What Is a Headless CMS?: Start here if you’re new to headless.
- Modern Website Tech Stack: The full stack these CMS choices fit into.
Not sure where your current site stands? Our free assessment evaluates your website’s tech stack, performance, and AI readiness, a good starting point for understanding what a modern CMS migration would involve.