Where your content lives looks like a technical decision. For a school, it is a teaching one.
We teach a way of working that is keyboard first and code first. A workflow you can drive without reaching for a mouse, without hunting through a web interface, without waiting on a screen to load. We do this partly for speed and focus, and partly for accessibility. A workflow built from text, files, and the keyboard is one more people can reach, automate, and own.
For a while, the words on this site lived somewhere that quietly worked against that. This is the story of bringing them home, and the plan we are following to do it without stopping the work.
Why a cloud CMS stopped serving us
Our writing has been living in a hosted content service, kept apart from the code that renders it. On paper that is a clean separation. In practice, for us, it added friction at every turn. Edits did not appear on our local site without a refresh. Drafts we could not see. A second system to keep in step with git. A way of working that leaned on a pointer and a browser tab rather than the keyboard.
The tool itself is capable. It is built for teams of authors publishing constantly without ever touching code, and that is a real and common need. It was not ours. We are a small, code first team, and every edit we make is already a commit waiting to happen.
What we actually want
Content as plain files. Living in git, beside the code, with one history and one source of truth. Editable in the same editor we write software in, reloading the moment we save. A workflow a new teammate can learn in an afternoon, because it is the same workflow they already use for code. Write, review, commit, push.
This is the lesson hiding inside the tooling. The tools we teach should be the tools we use. If we ask students to own their work through git, we should hold our own words the same way.
The plan, in two moves
We have a live site to build and a deadline that does not care about elegance. So we are doing this in two honest steps rather than one perfect leap.
First, Nuxt Content. Our site already runs on Nuxt, so we are moving our writing into markdown files that Nuxt reads directly. Same framework, same components, no rebuild of the house. We get files in git, hot reload, and a single source of truth now, rather than next quarter.
Then, bit by bit, Astro and Keystatic. Once the live site is standing, we migrate piece by piece toward the end we actually want. Astro for a content site that ships almost no JavaScript, and Keystatic for a calm editor that writes those same files straight back into git. Authors who do not live in a terminal still get a gentle interface. Nothing leaves the repository. Publishing stays a commit.
We are naming the order plainly, because the order is the point. The cheap, reversible step first. The deeper change second, in small pieces we can review.
Doing it in the open
This post is the first piece of writing to live in the new way. It is a markdown file in our repository, and publishing it is a commit. We are documenting the decision here, including the parts that are unfinished, because a school that learns in the open should show its working, not only its conclusions.
We will be wrong about some of this. We will find something markdown handles badly, or a step that is harder than it looked. When we do, we will write that down too.
What we are really practising
None of this is about a framework. It is about ownership. Holding your work somewhere you can read it, version it, and pass it on. It is about curiosity. Asking what a tool is really for before reaching for it. And it is about humility. Being willing to move off a choice we made a year ago because we have learned more since.
The workflow is not the dull setup you rush through before the real teaching begins. The workflow is the lesson.
