About Savoie Studio
Most documentation problems are verification problems, not writing problems.
I'm Matthew Savoie. I reconcile a tracker, a repository, and the published docs and hand you the rows where they disagree. Read-only. Nothing publishes.
I tested the product before I documented it
I spent nearly three years writing unit and API test automation for a developer-facing low-code database platform — Python and shell on macOS, suites running through Jenkins, defects tracked in Jira, coverage recorded in Confluence.
Then I left. A year later the same company brought me back on contract to document the product I had spent three years trying to break, and hired me directly a year after that. I wrote its documentation for six years.
That sequence is why this practice exists. When you have written the regression suite and then the docs, you learn two things a writer rarely gets: where a product actually breaks, and where its documentation quietly stops being true. They are almost never the same place.
What I sell
Docs audit. One repository, one tracker, one docs source, one release or window. Structural pass first — identifier matching, no model, nothing sent anywhere. You get a report of missing links and a walkthrough. A skipped “code without docs” check is reported as skipped, not as “every change is documented.”
This is the first engagement.
Release-note drafts. Only from work that already shipped, and only after the audit showed the gap. Your terminology rules applied. Mechanical checks on the file (ungrounded CVE/GHSA, empty sections). A person reads the draft. Nothing publishes.
This is not “AI writes the notes.” Jira and GitHub already do that inside one system.
Governed drafting. Plan → audit → execute → verify for longer Markdown. Sibling to the audit, not a merge. The model does not get a shell. A human decision ends every run.
Docs-as-code / CI. Static-site toolchains, GitHub Actions templates, terminology linting in the build. Complementary. Not the first call.
How I work
Four of reconciliation's six checks are structural. No model. Nothing leaves the network. The two that need judgment are opt-in per run and verified against the cited page before anything is reported.
A team under a strict privacy constraint can pilot the structural half without a procurement conversation first. That is usually the difference between starting and never starting. I spent two years building test automation against healthcare credentialing and provider data, so this is not a theoretical reading of what a regulated environment will allow through the door.
I don't sell autonomous documentation. Every finding is a review queue for a person, not an automatic verdict.
The practices above were checked against public open-source repositories — Caddy, Hugo, Kafka, Bootstrap v3.3.7, Homebrew, and others — not unnamed client work.
What this does not do
Reconciliation reads the metadata around a change: commit messages, ticket titles, page text. It does not read the source inside it.
It will tell you a merged change never reached your changelog. It will not tell you whether the function that change introduced does what its docstring claims. Nothing here compiles, executes, or tests a code sample.
I will not:
- write back to Jira, GitHub, or the docs site
- open tickets from the report
- run a nightly bot
- staff SharePoint, ServiceNow, DOORS, or GitBook
- ship a chatbot over the docs
I'd rather you know that now than discover it in week three.
Who I work with
Mid-size SaaS, DevTools, API-first, and regulated-industry teams — roughly 50 to 500 people — shipping faster than their documentation can follow.
Before this
Twenty-three years in and around software, mostly on the Apple platform. FileMaker development, database design, and server administration at Xerox. Over a thousand automated regression and functional tests in C# at a housing-software company. Two years of QA automation and testing documentation for a healthcare credentialing platform, where I also mentored the QA team rather than absorbing all of the automation myself.
The through-line is both sides of the wall: writing the tests that prove what a product does, and writing the documentation that claims what it does. This practice is what happens when you stop treating those as separate jobs.
A first look
Send a public repository. I will run a structural pass on public commit metadata only — no source, nothing to install — and send back a short report of what shipped but never made the documentation.