Content operations for tiny teams

Two writers and an engineer do not need a content management workflow. They need a folder, a review step, and something that shouts when a link breaks.

The pipeline

• Drafts live as files beside the code they describe
• Review happens in pull requests, which writers learn in an afternoon
• Continuous integration checks links, spelling, and front-matter
• Merging publishes

The whole thing is about eighty lines of configuration and it has outlived three tools we were told to use instead.

Why files win at this size

A content management system solves permissions, workflow, and non-technical editing. With two writers who both use an editor, none of those are problems, and you have taken on a database, an upgrade path, and a plugin surface in exchange for solving nothing.

The checks that pay for themselves

• Internal links resolve to files that exist
• External links return something other than a 404, checked weekly rather than per commit
• Front-matter has every required field
• No document is missing a description
• Spelling, with a project dictionary that everyone can add to

The link checker has caught more genuine problems than everything else combined, mostly because pages get renamed and nobody thinks about who was pointing at them.

When to stop doing this

The moment someone who does not use an editor needs to publish without help. Not when they need to suggest an edit — a document with a comment thread handles that fine — but when they need to ship. At that point the tooling has become a gate, and gates are how content operations die.