Posts

Most API documentation problems are not writing problems. They are structure problems. Format problems. Consistency problems. The kind that compound quietly until a developer opens your docs at 11pm and cannot tell whether the endpoint they’re reading is current, deprecated, or simply documented differently from the one before it. I have spent twenty years watching this happen across financial platforms, compliance systems, and SaaS products. The documentation itself was often fine. The system holding it together was not. ...

Every technical writer I know has the same complicated relationship with AI documentation tools. You try one. It generates fast, fluent, confidently structured output. You read it and immediately know something is wrong, but it takes a minute to place exactly what. The audience is off. The doc type does not match what the source material actually supports. There are three paragraphs explaining a concept the target reader already knows, and no explanation of the thing they actually need. The tool wrote well. It just wrote the wrong thing. ...

Technical writers build content. UX designers build interfaces. For twenty years, these two disciplines have operated in separate buildings, separate tools, separate reporting lines. That worked when documentation lived on a portal and the product lived on a screen. Users moved between two worlds: the application where they did their work, and the help center where they went when they got stuck. That world is ending. AI chatbots now pull documentation into the product and surface it as conversational answers. In-app guidance layers docs content directly onto the interface. Newer tools can expose your knowledge base as something an AI assistant can query directly. The documentation portal is no longer the destination. It is the backend data source for five different delivery surfaces, and neither the tech writer nor the UX designer fully owns the pipeline that connects them. ...

Documentation engineers build the infrastructure that ships products to readers. We wire up Git repos, configure linters, write CI/CD workflows, wrangle multi-format outputs, and maintain content taxonomies. We do all of this across a patchwork of tools that were never designed to work together. Copilot writes prose faster. GitBook gives you somewhere to publish. Vale catches style violations. But no single tool treats the pipeline from source to reader as one system. I went looking for one. I couldn’t find it. So I built a prototype to see what it would look like. This post is a build log. What I built, why I made the choices I made, and what I learned along the way. ...

I built this blog to document the work behind the documentation. Most writing about docs stays at the surface layer: style tips, templates, and tooling comparisons. That matters, but it skips the harder part of the job. Documentation teams do not just write pages. We build systems. We make information findable, structured, testable, reusable, and publishable across changing products and release cycles. That is the lens for this site. I write about documentation engineering, information architecture, API documentation, Docs-as-Code workflows, quality gates, and the operational problems that make documentation harder than it should be. Some posts will be build logs from things I am creating. Some will be field notes from enterprise documentation work. Some will be opinionated essays about what our tooling still gets wrong. ...