The argument for a CMS is that non-technical people need to edit content. It is a good argument. It is also, for most projects in their first year, answering a question nobody has asked yet.
What you are actually buying
A CMS bundles several things that are worth separating:
- A schema for your content.
- An editing interface.
- A hosting and access-control layer.
- A publishing workflow.
The first is the one you need immediately. The other three become valuable at the point where someone outside the build team is editing regularly — which, on a project that is still finding its shape, is often several months after launch.
The version with less surface area
A content directory with a validated schema gives you the first item outright:
const blog = defineCollection({
loader: glob({ pattern: "**/[^_]*{md,mdx}", base: "./src/data/blog" }),
schema: ({ image }) =>
z.object({
title: z.string(),
description: z.string(),
pubDate: z.coerce.date(),
heroImage: image(),
categories: z.array(z.string()).min(1),
}),
});Bad frontmatter now fails the build rather than rendering an empty element in production. That is the same guarantee a CMS’s required-field validation gives you, enforced earlier and with nothing to host.
You also get content in version control, which is a bigger deal than it sounds: a content change and the code change that supports it land in the same commit, review together, and revert together.
When to actually migrate
The signal is not “someone asked for an editor”. It is someone outside the build team is blocked. Until that is true, the editing interface is a cost with no user.
When it does become true, a schema-validated directory is close to the easiest thing in the world to migrate from — the schema is already written down, the content is already structured, and the mapping is mechanical. Starting with a CMS and discovering the schema was wrong is the migration that actually hurts.
