I build documentation systems, not just documentation.
Two decades at the intersection of technical writing, engineering, and product design — now focused on AI-assisted content operations.
In most organizations, documentation is an afterthought. I've spent over 20 years proving it doesn't have to be, building the tools, systems, and processes that make it part of how a team ships, not something bolted on at the end.
Background
A career at the frontier of developer experience
My career doesn't fit one job title. I have a degree in computer science and over 20 years in the industry, and I work as a technical content manager, a developer experience practitioner, and a platform builder, often at the same time. That computer science background shapes how I approach every project: I read the code, understand the architecture, and document systems from the inside out rather than the outside in.
Across API platforms, cloud infrastructure, SaaS products, identity systems, and internal developer portals, I've consistently worked on problems where the technical stakes are highest and the cost of ambiguity is steepest.
Technical depth
Fluency across the full documentation lifecycle
What sets me apart from content practitioners who specialize in writing alone is the depth of my technical reach. I work directly in the systems I document: authoring in Markdown and MDX, building in React and TypeScript, designing in Figma, wiring up CI/CD pipelines, and validating real-world API behavior in Postman and against OpenAPI specs. At Microsoft's Azure Dedicated team, I co-authored deployment documentation for Azure VMware Solution by working directly alongside Azure engineers and UX researchers to validate workflows firsthand.
“Documentation built from the outside in — written after the product is finished — is always a liability. My instinct is to build it from the inside out.”
At Cigna (November 2023–May 2026), I worked within the Enterprise DevOps organization, owning Alchemy Docs, the documentation platform supporting Alchemy, Cigna's internal developer portal built on Backstage. My work there went well beyond writing: I built the ContentOps Playbook, wrote the enterprise style guide, contributed to portal UI redesign, designed the prompt and content architecture for the DevOps Communications Utility, and built content systems that scaled across multiple engineering teams with different cadences and ownership models.
I'm now a Senior Technical Content PM (contract) at Microsoft, focused on AI-assisted content workflows and content operations for learn.microsoft.com.
Building my own tools
From practitioner to founder: Pixl'n Grid Studios
The clearest sign of how I work is what I build when no one has asked me to. Through my independent studio, Pixl'n Grid Studios, I've designed and shipped two production-grade platforms that address problems I ran into in my own practice.
TechWrit AI
A code-aware SaaS documentation platform with 14 generation and audit modes, a VS Code extension with inline style diagnostics, and a REST API for CI/CD pipeline integration. Style guide enforcement happens at generation time, not after.
Trellis Docs
An open-source documentation framework built on Next.js 15 with reusable content variables, build-time design token processing, client-side fuzzy search, and audience role tagging.
Both platforms came out of the same problem: the gap between what documentation tooling promises and what it actually delivers at scale. I launched TechWrit AI publicly in February 2026, and it's live at techwrit.ai. Trellis Docs is available as an open-source project with an active public repository.
Approach
Strategy, structure, and the system behind the sentence
My approach to documentation is fundamentally architectural. Whether I'm establishing an information hierarchy for an internal developer portal, designing a Diataxis-aligned content structure for an API reference, or defining metadata naming conventions for Backstage software templates, I think in systems before I think in sentences. The result is documentation that stays coherent and maintainable across team changes, product iterations, and organizational growth.
My content operations work at Cigna is a clear example of that instinct. Rather than producing documentation in isolation, I built the infrastructure, playbooks, style standards, and publishing workflows, that make documentation quality a property of the system, not just the person writing that day.
What this adds up to
What I bring to a team
End-to-end ownership
I don’t hand off to engineers — I build alongside them, from content strategy through front-end implementation.
Platform thinking
Whether inside an enterprise or as an independent founder, I build systems designed to outlast any single project or team member.
Why I build tools
TechWrit AI and Trellis Docs exist because I ran into real gaps in the tooling — and had the skills to close them myself.
Cross-discipline range
My work spans UX research, product design, AI integration, open-source development, and enterprise documentation strategy.
The software industry doesn't lack people who can write about technology. What I bring is the ability to build it too, and the conviction that documentation belongs inside the product, not bolted onto the end of it.