I shipped a long technical article recently, and the unusual part was where the “source material” came from.
The piece wasn’t written in isolation. It grew out of the same Cursor Agent conversations where we went from design notes to production-ready code: implementation, deploys, debugging, and the actual fixes we landed when things misbehaved in the real stack (AWS, OAuth, MCP, etc.). So the article isn’t generic architecture hand-waving - it’s tied to decisions, endpoints, and failure modes we really hit.
That has a downside: specs drift from code unless you maintain them. Here, the write-up stayed aligned because it was fed by the same thread of context as the implementation, including what we changed when we were wrong the first time.
After many rounds of edits and alternate outlines, I used Brivvy’s brand voice tooling to pull the tone and terminology back to something consistent with how we talk as a company - without flattening the technical detail.
If you’re building your own MCP server (especially remote MCP with OAuth on AWS), that article is the end-to-end write-up that came out of the same work - not a separate “marketing doc”: How to ship MCP authentication on AWS
If you use Cursor with remote MCP and want Brivvy in the editor (brand voice, templates, etc.), we published setup here: Cursor + Brivvy MCP
Curious how others handle this: when you’re writing deep technical articles tied to real shipped code, what’s your workflow—same repo/thread as implementation, separate docs branch, PR-driven updates, something else? Any habits that keep the article honest when the code keeps moving?