Technical Writer · Prague
Documentation Systems · Docs-as-Code · Developer Content
Documentation built with the same discipline it teaches.
A six-part documentation series built and deployed as a live static site. Written in Markdown, version-controlled in Git, and deployed automatically via GitHub Actions — the same workflow the series teaches.
Read the Series →
Hands-on API documentation built using the OpenWeather REST API and Postman — covering authentication, endpoint structure, request parameters, and response interpretation. Structured in Markdown following Docs-as-Code standards.
Read the Docs →
A technical writer's evolution — from producing content to designing documentation systems. Long-form series on Docs-as-Code, information architecture, and the thinking behind great developer documentation.
Visit the Blog →
A practical guide to building a personal website with a custom domain and professional email — covering GitHub Pages, Cloudflare DNS, HTTPS configuration, and Gmail SMTP. Includes troubleshooting for every common failure point.
Read the Guide →
A documentation-led review of a static frontend website — covering architecture decisions, security considerations, known limitations, and deployment strategy. The documentation is the product.
View the Repo →
Technical documentation for this portfolio site — covering architecture decisions, local setup, deployment pipeline, content workflow, and contributing guidelines. The site documents itself.
Read the Docs →
A complete 11-page guide to building and deploying documentation sites with MkDocs — covering installation, configuration, content writing, GitHub Pages deployment, custom domains, and troubleshooting. Written for technical writers adopting Docs-as-Code workflows.
Read the Guide →Documentation fails in predictable ways. It drifts from the product. It loses its owner. It answers the question nobody asked while leaving the real question unaddressed. Most teams know this is happening. Almost none have a system to stop it.
That is what I build.
I am Douglas Ebhoman, a technical writer based in Prague who designs documentation systems for DevTools and SaaS companies. Not content strategies. Not style guides. Systems — the architecture that decides how documentation is structured, versioned, deployed, and maintained as products grow and change.
My background is unusual for this field. I started as a creative writer, which means I arrived at technical writing already knowing how to earn a reader's attention before asking for it. Most technical writers learn to write clearly. I learned to write in a way that makes people want to keep reading.
I do not just describe systems. I make them legible.
If you are building something engineers need to understand, that is the problem I solve.
What People Say
Douglas has nailed it with his 'Git & GitHub for Technical Writers' series. It's a must-read if you want to adopt Git and GitHub for product documentation. He has a knack for writing in a simple, clear style — it's a pleasure to read. I'm looking forward to more great insights.
Not a list of tools. A demonstration of how I think and what I build.
Most documentation systems are built once and left to drift. I design the architecture, workflows, and automation that make documentation maintainable as the product evolves — not just well-written at launch.
The same workflow this portfolio site uses.
The Diátaxis framework separates documentation into four distinct types. Most documentation fails because it mixes them — a tutorial that becomes a reference, a how-to that turns into an explanation. Click each quadrant to see what belongs there.
Click any quadrant to see what belongs there.
The difference between documentation engineers ignore and documentation they trust is not accuracy — it is precision. The same information, written for the right reader, in the right register, at the right level of detail. See the difference below.
{
"status": 200,
"data": {
"token": "eyJhbGc...",
"expires": 3600,
"scope": "read:docs write:docs"
}
}
// token: Use this in the Authorization header // for all subsequent API requests. // expires: Seconds until the token expires (1 hour). // Refresh before expiry to avoid 401 errors. // scope: Permissions granted. write:docs required // for POST and PATCH endpoints. { "status": 200, "data": { "token": "eyJhbGc...", "expires": 3600, "scope": "read:docs write:docs" } }
The code is identical. The documentation makes it usable.
Six questions. Sixty seconds. A precise diagnosis of where your documentation system stands.
Most teams reach that point and do not know it until something breaks. That is the problem I solve — documentation that works as a system, maintained deliberately as the product evolves.
I respond to every message within 24 hours.
Not sure where to start?
Run the free Documentation Health Check above. Six questions, sixty seconds. Once you have your score, send it to me and I will respond with a specific assessment of your next best step.
Run the Health Check