Why the blog and CMS stay content-as-code

Start with the lowest-friction system

For a personal site, the content model is small and predictable. Introducing a database, role model and rich editorial surface too early usually creates operational weight before it creates value.

The first useful version can stay much simpler:

• Markdown files hold the source of truth
• Git history provides review and rollback
• the admin route acts as a thin publishing helper

What this buys immediately

Keeping content in the repository makes deployment and content changes move through the same pipeline. That reduces the number of systems that can drift apart.

content/blog/{locale}/{slug}.md
        -> parsed at build time
        -> rendered in the localized route
        -> measured through lightweight API counters

This is not the most flexible architecture possible. It is the one with the best ratio between effort, control and migration cost at the current stage.

The upgrade path stays open

If the writing volume grows or editorial workflows become more complex, a stronger CMS can still be introduced later. Starting with content-as-code does not block that path.

It simply avoids paying the complexity tax before there is evidence that the project needs it.