Most teams think of GitHub as a place to store code. We treat it as the place where everything lives — code, docs, blog posts, ideas, experiments, and the entire history of how Hyprnote evolves.
This wasn't a grand strategy. It just slowly became obvious: if our work already happens in GitHub, why should publishing be anywhere else?
The more we leaned into that idea, the more natural it felt. Now it's just how we ship.
You Don't Need a CMS When You Already Have Git
Most CMS platforms try to solve two problems:
- where your content lives
- how your team edits it
Git already solves both.
Content lives in plain files. Editing happens through commits, branches, reviews, comments, and diffs.
There are no plugins. No migrations. No schema lock-in. No "oops our CMS updated and it broke your content model."
Just Markdown, MDX, and a repo.
You never worry about losing access to your writing because everything is portable. You can zip the folder and take it anywhere. There's something comforting about that — a simplicity modern CMS platforms forgot.
PRs Are a Better Editorial Workflow
If you're a technical team, this is the part that just clicks.
A blog post becomes a pull request. A pull request becomes a draft. Review comments become edits. A merge becomes publication.
There's no ceremony. No separate editorial queue. No abstracted "content status." No dashboards trying to reinvent what Git already does perfectly.
You get:
- inline comments
- suggested changes
- clear diffs
- commit-by-commit history
- revert ability
- preview builds
- CI checks for grammar, broken links, lint rules
- permanent traceability
This is more powerful than any CMS collaboration feature because it's built on top of something every engineer already understands.
Content Is Just Code, So You Get All the Benefits
Once your blog posts live in the repo, everything becomes composable.
Need a new MDX component? Ship it. Need to fix a typo? Commit it. Need to update metadata? It's just frontmatter. Need to refactor how posts are structured? Rip through it with a script.
There is never a moment where you're stuck thinking:
"How do I do this in the CMS again?"
Instead the question becomes:
"How do I want this to work?"
And that's a better question.
GitHub Scales With Your Team, Not Against It
Most CMS systems age poorly:
- content models become rigid
- plugins break
- WYSIWYG editors drift
- migrations become risky
- versioning becomes chaotic
GitHub is the opposite.
The larger your team grows, the more valuable its primitives become:
- branch-based workflows
- code owners for reviewing specific areas
- protected branches
- required checks
- bots for automation
- auditability
These are problems GitHub already solved at a global scale.
Why recreate them in a CMS?
Images, Assets, and the Non-Code Stuff
A common argument for CMS platforms is the convenience of asset uploads.
Paste an image → instantly appears. Drag a file → gets stored in their bucket.
It is nice.
But we don't lose that. We just do it differently.
You can:
- drag images directly into GitHub's web editor
- upload screenshots into Supabase, S3, or R2
- paste the public URL into MDX
- or commit images directly into the repo
It takes seconds.
The difference is you control the storage and the URLs forever — they're not tied to whatever CMS you happened to be using that year.
Portability Matters More Than People Think
Every CMS feels safe until the day you want to leave.
Then you find:
- proprietary block formats
- hidden HTML
- vendor-specific markdown
- custom schemas
- migration scripts that only half-work
A folder of .mdx files has none of that.
If we move frameworks, hosting providers, or even redesign everything from scratch, the content survives untouched.
Portability isn't a feature. It's insurance.
GitHub Gives Us the Kind of Freedom We Care About
Writing should be simple. Shipping should be fast. Content should last.
For us, GitHub checks all three.
We don't need a CMS to feel modern. We just need something that respects how we work.
GitHub does.
This is Part 2 of our series on building a modern publishing workflow. Next: How to choose the right CMS for your team (and when not to use one at all).