This site used to run on a full content management system. It worked, but the machinery was larger than the job.
There was a database, an admin interface, server-side code, and a deep stack of dependencies supporting a portfolio and a small collection of notes. Every layer was defensible by itself. Together, they created more maintenance than value.
The new version uses Astro and Markdown. Pages are generated ahead of time. Notes live next to the code. There is no database to keep alive and no runtime API between a reader and the words on the page.
The useful question is not “can it scale?”
Almost any architecture can be justified by describing a sufficiently large future. The more useful question is: what does the project need now, and how expensive will it be to change later?
For this site, the answer was a small, static system with strong content structure:
- typed metadata catches mistakes during the build;
- English and Spanish have stable URLs;
- untranslated notes fall back clearly instead of pretending to be translated;
- the browser receives ordinary HTML and very little JavaScript;
- adding a note means adding a Markdown file.
This is enough system to keep the site consistent without turning publishing into infrastructure work.
Simpler is not the same as unfinished
A simple implementation still needs care. It needs accessible navigation, useful metadata, good typography, predictable URLs, responsive layouts, and a content model that will not collapse after the fifth post.
The goal was not to build less thoughtfully. It was to move thought into the parts that readers and future maintainers will actually feel.
That is the kind of simplicity I want in product work: not fewer decisions, but fewer unnecessary ones.