Many technical teams treat editorial work as an afterthought. The website grows out of internal wiki entries that someone eventually rewrites. Blog posts get written between meetings. Feature announcements wait until an engineer has time to enter them into forms. The result: content appears late, is inconsistent, and nobody owns it.
The problem with traditional CMS
The classic answer is: "Install a CMS." WordPress, Contentful, Sanity — all of them solve the publication problem in their own way. But none of these solutions truly fits technical teams used to working with Git, IDE, and code review.
CMS interfaces are built for non-technical users. That is great for editorial teams without a technical background, but it forces engineering teams into a foreign work environment. The consequence: content is maintained twice (once in the wiki, once in the CMS), or the publication process is fully outsourced to marketing.
Git-native editorial
Our solution — proven in three projects — is Git-native: all content (blog posts, landing pages, product descriptions) lives as Markdown files in a separate content repository. Engineers push changes like code. Editorial works in the same place — but we built a lean web editor that produces Markdown under the hood.
The flow is:
- Draft: a new post is created either in the web editor or directly as a Markdown file. Status:
draft. - Review: pull request or share link. Editorial + subject-matter owner review. Feedback via comments.
- Publish: merge into
main. CI triggers a rebuild, the content goes live.
Every step is auditable. Every change is reversible. Every approval is tied to a name.
Status values that matter
We agreed on five status values:
draft— work in progress, not ready for reviewreview— waiting for approvalscheduled— approved, publication in the futurepublished— livearchived— once live, no longer surfaced
Archiving is important. Deleting is too destructive — URLs go nowhere, SEO juice disappears. Archived posts remain reachable under their URL but are hidden from index listings.
The role split
We defined clear roles:
- Author: creates and edits drafts.
- Reviewer: approves. Can be the author for simple cases.
- Publisher: triggers the deploy (automatic on merge).
- Owner: is responsible for a post's lifecycle. For us, usually the subject-matter expert.
The owner is the most important role. Without a clear owner, posts slowly become outdated. With an owner, a missed review date is not silent — they get a review reminder via Slack.
Tooling integration
Slack integration for status changes is a given. A Grafana dashboard shows us: how many drafts are older than 30 days? Which posts have been waiting more than 7 days for review? Which posts are over 12 months old and need review?
The dashboard is the quiet win of this setup. Editorial work becomes measurable.
What we'd pass on
If you want to abolish a CMS, clarify the flow first. If you want to introduce a Git-native setup, get the editorial team involved first. The tool switch is the easy part — the hard part is renegotiating roles and expectations.