If only developers edit your site’s content and the page count is small, you don’t need a separate content management system: text can live directly in the repository next to the code. If a non-technical team publishes content, volume is growing, and there are more than one or two editors, the site will quickly hit a wall with the developer as the only publishing channel. The line isn’t drawn by company size - it’s drawn by two specific factors: who edits the content, and how often.
In web development projects for SaaS and B2B sites, we regularly see the same pattern: the team picks a CMS in the first week of the project, before it’s clear who will publish content and how often. Six months later it turns out that only the developer opens the CMS editor, once a quarter, while the monthly SaaS subscription keeps getting charged. The opposite situation shows up less often: content lives in code files for years, and when a marketer joins the team, every text change turns into a developer ticket and a wait for the next release.
Below is a concrete breakdown of what Content Collections in Astro actually are, how they fundamentally differ from a Headless CMS, and the two questions that really determine whether your site needs a separate content management system.
The pain here isn’t abstract. Either the company overpays for infrastructure nobody uses, or the developer becomes a bottleneck for every text change - a typo fix, a pricing update, a new case study for the blog. Both scenarios cost real money: in the first case, it’s the subscription bill; in the second, it’s developer hours and a publishing delay that derails the marketing plan.
Content Collections: a built-in Astro mechanism for storing structured content - Markdown or MDX files - directly in the project repository, with a type-safe schema and no separate database or API.
Headless CMS: a content management system that stores and edits content separately from the site’s code and delivers it via an API - Sanity, Contentful, Strapi, Payload, and similar platforms.
What Astro Content Collections actually are
Content Collections aren’t a lightweight version of a CMS - they’re a way to treat Markdown and MDX files as typed data. Content lives in the src/content/ folder in the same repository as the site’s code, not in a separate database hosted by a vendor.
Each collection’s schema is defined with Zod, a type validation library for TypeScript. The developer sets once which fields a blog post requires - title, publish date, tags - and after that the editor gets a build error if a field is missing or has the wrong type, before the deploy ever happens.
Fetching content from a component looks like a plain function call, getCollection('blog'), not an HTTP request to an external API. That removes the network call at build time and drops the dependency on a third-party service’s uptime during deployment.
The main consequence of this architecture is versioning. Every text change goes through the same git repository as the code: rollback, edit history, and code review for content work exactly like they do for any pull request. Astro’s official documentation describes this as a built-in type-safety layer on top of the file structure, not a separate product.
Two questions that determine whether you need a content management system
The decision rarely depends on company size or budget - more often it comes down to two specific factors: who physically edits the content, and how often that happens.
The first question is who edits. If only developers touch the content - through a pull request, in their own dev environment, with code review - Content Collections fully cover the job and require nothing beyond what’s already in the project. If marketing, a copywriter, or a CEO without git access needs to make edits, every change routed through a developer creates a queue, and that queue grows with the team.
The second question is update frequency. A site with 5-10 static pages that updates once a month or less doesn’t generate enough load to justify a separate CMS layer: an MDX file and a pull request solve the task faster than logging into a third-party admin panel. A blog with several posts a week from multiple authors is a different story - the content pull request queue starts competing with the feature queue, and at that point it’s an architectural problem, not a matter of taste.
When code alone is enough
A small B2B site or marketing landing page where the engineering team writes and edits all the content is the typical case where Content Collections cover the job completely, and for free.
A technical team of two or three people who already work in git don’t need to learn the interface of yet another SaaS service for five static pages. An MDX file opens in the same code editor as a component, uses the same environment variables, and deploys through the same pipeline as the rest of the site - with no separate build step for content.
In a typical site built from scratch for an early-stage SaaS - a few product pages, a blog with occasional posts, a pricing page - setting up Content Collections along with the schema takes a developer less than a working day. For comparison: connecting and configuring a full Headless CMS with editor roles and deploy webhooks usually takes three to five days, even on a ready-made platform.
When you can’t do without a Headless CMS
As soon as someone without git access needs to edit content - a marketer, a product manager, a CEO without a technical background - Content Collections stop covering the job, regardless of site size.
A Headless CMS gives a non-technical editor an interface with no code in sight: a form with fields, a preview, and a publish button. Sanity, Contentful, Strapi, and Payload solve this differently - in pricing, deployment model, and how deep the visual editor goes. For a breakdown of the concrete differences and which platform wins in which case, see Sanity vs Contentful vs Strapi: choosing a Headless CMS for a B2B site.
Astro’s official guide to connecting a CMS confirms the same principle: the framework doesn’t dictate which platform you pick - the integration gets added when it’s needed, not by default on every project.
A separate case is a team that wants to keep control over its data and isn’t ready to pay a SaaS subscription per editor, but editors still need a no-code interface. For this scenario, a self-hosted option like Payload CMS often turns out to be the compromise between full developer control and editor convenience - see the architecture and real cost-of-ownership breakdown in Payload CMS: When to Choose It Over Strapi and Sanity.
The hidden cost of the decision - in both directions
Both kinds of mistakes cost real money - they’re just distributed differently over time.
Adopted a CMS too early
A Headless CMS subscription starts at several dozen dollars a month on growth tiers and scales with the number of users and the volume of content. For a team of two developers who write all the copy themselves, that’s a recurring bill for functionality that, in practice, nobody but them ever touches.
On top of the subscription there’s an architectural cost: a Headless CMS is one more external API that your build or render depends on being available. Every additional service in the chain is one more point of failure and one more set of access tokens you need to rotate and keep track of.
Waited too long to adopt a CMS
The opposite mistake is less visible at the start but more expensive over the long run. When a site’s content stays in code longer than the team stays purely technical, the developer becomes the only publishing channel - and every text change competes for their time with feature work.
In a typical B2B project where marketing grows faster than the engineering team, the pull-request queue for content edits starts eating anywhere from a few hours to a full working day of developer time per week - time that builds no new functionality and gets spent on something an editor interface would solve in minutes. Ongoing site support in that setup gets more expensive precisely because of this queue, not because of the code’s complexity.
Real case - the numbers
In a typical marketing site launch for a B2B SaaS with a team of three engineers and no dedicated content manager, setting up Content Collections along with the schema for the blog, case studies, and product pages takes 4-6 hours of developer time - with no monthly CMS bill.
8-10 months into growth, when the first marketer without git access joins the team, the typical scenario is migrating part of the content - blog, case studies, campaign landing pages - to a Headless CMS, while product descriptions and legal pages stay in Content Collections because only developers still edit them. This hybrid setup, where part of the content stays in code and part moves to a CMS, shows up in projects like this more often than an all-or-nothing choice for the entire site.
Which option fits which team
Content Collections with no CMS at all fit technical startups and product teams where engineers or a technically fluent founder write and edit all the content, and the page count is in the single or low double digits.
A Headless CMS earns its keep as soon as at least one person without git access enters the publishing process - a marketer, a content manager, an outsourced copywriter - or the number of posts passes a few per week. For companies with 15+ employees and a dedicated marketing team, a separate CMS is, in the vast majority of cases, already justified by the time the question is seriously on the table.
Frequently asked questions
Does a small site need a content management system?
Not always. If your site is 5-10 pages that only developers update, and the change frequency is once a month or less, Content Collections in Astro cover the job completely: content lives in the repository, deploys with the code, and requires no subscription and no separate API. A dedicated CMS becomes worthwhile once someone without git access joins the editing process, or publishing volume grows.
How do Content Collections differ from a Headless CMS?
Content Collections store content directly in the project repository as Markdown or MDX files with a Zod schema - no database, no API, and content gets versioned together with the code through git. A Headless CMS stores content separately, either on the vendor’s side or on your own server, and delivers it to the site through a REST or GraphQL API, which gives non-technical editors a dedicated interface with no code access.
Can you start with Content Collections and migrate to a Headless CMS later?
Yes, and in practice this is a common path. Content Collections store content in plain Markdown/MDX files, so migrating to a Headless CMS is mainly a matter of mapping fields to the new schema, not rewriting the site’s architecture from scratch. Many teams migrate only part of the content - the blog and case studies, for example - and leave static product pages in Content Collections.
How much does it cost to run a site without a CMS versus with a Headless CMS?
Content Collections add no direct costs - content deploys together with the rest of the site on your existing hosting infrastructure. A Headless CMS adds a separate bill: anywhere from free self-hosted tiers like Strapi and Payload, where the cost shifts to server infrastructure, to $50-100 or more a month on growth tiers of managed SaaS platforms like Sanity, scaling with the number of editors and the volume of content.
Who should make the decision - the developer or marketing?
The decision should be made jointly, because the criteria touch both sides: the developer weighs architectural complexity and maintenance cost, while marketing weighs the need for publishing independence from the developer. If only the engineering team makes the call, there’s a real risk of underestimating how quickly the lack of a CMS turns into a bottleneck for the content plan.
If you’re choosing the architecture for a new site, or you’ve already hit a queue of content edits stuck behind a developer, describe the task to the Exceltic.dev team. We’ll look at your content volume and editor team, and propose an architecture - with or without a Headless CMS.