ESC
Currently taking documentation engagements
Documentation Systems · DevTools & SaaS · Prague

Your product is scaling.
Your documentation isn’t.

Every sprint ships. Your docs don’t keep up. Your users pay for it: in confusion, in support tickets, in churn. I build documentation systems that hold up as your product grows.

Douglas Ebhoman
Book the Audit — €300 See my work →
6
Portfolio pieces
5+
Years writing
€300
Audit entry point
5
Working days
Douglas Ebhoman — Documentation Systems Specialist, Prague
Douglas Ebhoman
Documentation Systems · Prague
docs-strategy.md
Docs-as-Code API Documentation Information Architecture Documentation Audits DevTools & SaaS Prague · Available Globally Docs-as-Code API Documentation Information Architecture Documentation Audits DevTools & SaaS Prague · Available Globally
What good documentation actually does

Documentation is a product surface.
Treat it like one.

Three things that are true about my work and can be verified right now. Not estimates. Not projections. Facts.

0

Publicly accessible portfolio pieces

Every piece is version-controlled, live, and readable right now. Not a PDF. Not a screenshot. Documentation you can evaluate the same way a developer would encounter it.

All six available at douglasebhoman.com/work

0+

Years building documentation systems

Not writing. Systems. The difference between a document that exists and documentation that holds up as the product evolves, the team changes, and the sprints keep shipping.

API docs · Docs-as-Code · DevTools · SaaS

0

Working days to audit delivery

You send me the link. I send you the report. A written diagnosis, prioritised action plan, and 30-minute walkthrough. Fixed fee. No scope creep.

€300 flat · Currently available
About the Writer

Most documentation is written for the person who built the product.
Not the person who has to use it.

Douglas Ebhoman

That distinction sounds small. It isn’t. When an engineer documents a feature, they document what it does. What they forget, because they cannot unknow it, is that the reader arrives without that context. The reader does not need a description of the feature. They need a map from their problem to the solution.

I came to technical writing through creative writing. That is not a detour. Fiction trained me to analyse an audience's mental state before writing a single word, to understand what they are carrying, what they already know, and where they are likely to get lost. That is not a writing skill. It is an information architecture skill. And it is exactly what most technical documentation is missing.

“The reader does not need a description of the feature. They need a map from their problem to the solution.”

What drives me is not passion. It is responsibility: to be the advocate for the users who are quietly suffering the consequences of documentation nobody designed with them in mind.

I write fiction in Prague in the evenings, the same discipline as documentation, at its core: imagine the reader you have never met, understand what they need to know, and build something they can move through without getting lost.

Narrative is infrastructure. I treat it that way.

01 — Principle

Empathy before architecture

Knowing the reader’s pain point is not a soft skill. It is the baseline every documentation decision should be built on.

02 — Principle

Structure is a reader service

Findability is an architecture problem, not a writing problem. Good structure means the reader never has to guess what comes next.

03 — Principle

Narrative is infrastructure

Documentation written with narrative logic gets read. Documentation written without it gets skimmed, misunderstood, and ignored.

Documentation health check

Is your documentation
holding up as your product grows?

Six questions. Two minutes. A specific diagnosis of where your documentation system is failing and what it is costing you right now.

Question 1 of 6

0
Documentation health score

Based on your answers across accuracy, ownership, and findability.

Book the audit — €300 →
Selected work

Documentation built the way
engineers ship code.

View all work →
MkDocsDocs-as-Code
01
MkDocsGitHub PagesDocs-as-Code

MkDocs for Technical Writers

The problem

Writers adopting Docs-as-Code had no guide that didn’t require a developer alongside them.

What I built

A complete guide from installation through production deployment, written for writers not engineers.

Result: Removes the developer dependency from the onboarding process entirely.

Read the documentation→
OpenWeather APIAPI Documentation
02
API DocsRESTPostman

OpenWeather API — Getting Started Guide

The problem

Engineers had no clear path from authentication to a working first API call.

What I built

End-to-end docs covering auth, endpoints, parameters, and response interpretation.

Result: Eliminates the most common first-session failure points for new API users.

Read the documentation→
Website SetupInfrastructure Docs
03
GitHub PagesDNSCloudflare

Personal Website Setup Guide

The problem

GitHub Pages, DNS, HTTPS, and email setup had no single coherent reference.

What I built

End-to-end docs covering every component, with troubleshooting for every common failure point.

Result: Collapses a multi-day setup process into a single navigable document.

Read the documentation→
Site DocsInternal Docs
04
ArchitectureCI/CDInternal Docs

douglasebhoman.com — Site Documentation

The problem

Portfolio sites are typically undocumented black boxes, hard to maintain, impossible to hand off.

What I built

Internal-style docs: architecture, local setup, deployment pipeline, contributing guidelines.

Result: A site that documents itself, the same standard I apply to every client engagement.

Read the documentation→
Documentation in practice

Not screenshots. Not PDFs.
Actual documentation, rendered live.

The best way to evaluate a technical writer is to read their work in context. Each tab below shows a real excerpt from a real piece, structured, styled, and readable exactly as a developer would encounter it. This is the creative-technical blend in practice.

openweathermap-api.md
GET/data/2.5/weather?q={city}&appid={API_key}

Current Weather Data

Returns the current weather for a given location. Supports lookup by city name, city ID, geographic coordinates, or ZIP code. Responses are in JSON by default.

Before you begin New API keys activate within 10 minutes of generation. If you receive a 401 Invalid API key error immediately after creating a key, wait 10 minutes and try again.

Request parameters

ParameterTypeRequiredDescription
qstringYes*City name. Add country code for precision: London,uk
appidstringYesYour API key
unitsstringNometric (°C), imperial (°F). Default: Kelvin

Example request

curl "https://api.openweathermap.org/data/2.5/weather?q=London,uk&units=metric&appid=YOUR_API_KEY"

Response

{"weather":[{"main":"Clouds","description":"overcast clouds"}],"main":{"temp":15.2,"feels_like":14.1,"humidity":82},"wind":{"speed":5.1,"deg":200},"name":"London"}
getting-started.md

Getting Started with MkDocs

MkDocs is a static site generator for building project documentation from Markdown files. This guide takes you from installation to a live documentation site, no prior experience required.

Prerequisites Python 3.8 or later. Run python --version to check.

Installation

1

Install MkDocs

pip install --upgrade mkdocs
2

Create a new project

mkdocs new my-project && cd my-project
3

Start the development server

mkdocs serve
architecture.md

Site Architecture

This document describes the technical architecture of douglasebhoman.com. Written for future maintainers who need to understand how the site is structured without reverse-engineering it from source.

Technology stack

LayerTechnologyWhy
GeneratorJekyllSupported natively by GitHub Pages.
HostingGitHub PagesFree, reliable, deploys on git push.
StylesCustom CSSZero dependencies. Full design control.
DNSCloudflareFree SSL and performance caching.
Deployment Every push to main triggers a GitHub Pages build. Deployments complete in under 60 seconds.
git-for-writers.md

Git for Technical Writers

Git is version control software originally built for code. As a technical writer, you will use it to track changes to documentation, collaborate with engineers, and publish updates without emailing files.

Why Git matters for writers When your documentation lives in Git alongside the code it describes, documentation debt becomes a code review problem, not a backlog problem.

The four commands you will use 90% of the time

git pull origin main git checkout -b docs/update-api-authentication git add docs/authentication.md git commit -m "docs: clarify token expiry behaviour in auth guide"
The service

Start with the
Documentation Audit.

Most teams know their documentation is a problem. They don’t know exactly where it’s failing or what to fix first. That’s what the audit solves. I read everything. I identify the structural failures and rank them by impact. You get a written report and a 30-minute call. No vague feedback. No generic advice. A clear, prioritised plan you can act on immediately.

Full documentation review

Every page assessed across accuracy, structure, ownership, and findability. Nothing assumed, nothing skipped.

Prioritised action plan

Every finding ranked by impact. You know exactly what to fix first, and why.

Structural recommendations

Not just what’s broken: what to build instead. Architecture, ownership model, and system logic.

30-minute walkthrough call

I walk you through every finding. You can ask questions, push back, and leave knowing exactly what happens next.

Delivered in 5 working days

You send me the link. I send you the report. Fixed timeline, fixed fee. No scope creep, no surprises.

Limited availability. Currently taking new audit clients.
See all services →

Documentation Audit
I read your docs. You get clarity.

Fixed fee · No surprises · 5 working days

€300
One fixed fee. Everything included.
Delivered in 5 working days

Consider this

One mis-documented API endpoint costs your team 3–5 hours of support time. The audit costs less than a single engineer’s half-day.

Book the Documentation Audit →
Send a message first
How it works

From first contact to delivered system.

01

Audit

I review your documentation against four dimensions: accuracy, structure, ownership, and findability. You receive a written report and a 30-minute walkthrough within five working days.

You find out exactly what is broken.

02

Diagnose

We identify structural problems and prioritise what to fix first, and why. Every recommendation is ranked by impact, not by how easy it is to implement.

You know where to start.

03

Build

I design and implement the documentation system: architecture, templates, ownership model, deployment pipeline. The kind that stays accurate as your product grows.

You get a system, not a document.

04

Hand off

Your team owns everything. I document the system itself so you can maintain it without me. The goal is independence, not dependency.

You don’t need me forever.

docs-strategy.md
1# Documentation Strategy
2
3## Core principles
4- Empathy before architecture
5- Structure is a reader service
6- Narrative is infrastructure
7
8## Audit dimensions
9- [x] Accuracy
10- [x] Architecture
11- [x] Ownership
12- [x] Empathy
What clients say

Not compliments.
Outcomes.

LinkedIn · Verified

“A must-read if you want to adopt Git and GitHub for product documentation.”

Douglas has nailed it with his Git and GitHub for Technical Writers series. He has a knack for writing in a simple, clear style. It is a pleasure to read. The kind of documentation that removes the barrier between the writer and the workflow.

TD

Tejas Dandekar

Associate Director, DP&S

What this engagement delivered

A six-part Docs-as-Code series adopted as a practical reference for technical writers moving to Git-based workflows
Documentation that works as both a learning resource and a standing reference, no prior Git experience required
Reviewed and recommended by a senior director in a product and documentation practice
Before

Users couldn’t navigate the platform without asking for help. The documentation existed but wasn’t doing any work.

“Douglas doesn’t just write documentation. He builds clarity into the product experience itself. His ability to simplify complex systems while maintaining strategic structure significantly improved how our users interacted with our platform.”

Product Lead

Series A SaaS platform · 60-person team

→ Documentation systems engagement

The shift

They hired a writer. What they got was a systems strategist who changed how the whole team thought about documentation ownership.

“Sharp thinking. Structured execution. Documentation that actually moves the product forward. Working with Douglas felt less like hiring a writer and more like bringing in a systems strategist.”

Engineering Lead

Developer tooling company · Seed stage

→ Documentation systems engagement

The realisation

They came in thinking the problem was the writing. The audit showed the problem was the system underneath it.

“We came in thinking we needed a technical writer. What we actually needed was a documentation system, and Douglas delivered exactly that. Cleaner onboarding, fewer support questions, and documentation that finally felt intentional.”

Head of Product

DevTools company · Series A

→ Documentation Audit + systems build

The pattern across every engagement

Every client arrives with a different surface problem: docs that are out of date, users who can’t find what they need, engineers who are the single source of truth. The root cause is almost always the same: documentation that was written but never designed.

The audit makes the structural problem visible. Then we fix it with a system that holds up as the product grows, not a document that starts drifting the day after it ships.

100%

of audit clients identified structural ownership failures they hadn’t named before the report

€300

fixed fee · five working days · no scope creep · no surprises

Book the audit →
Tejas Dandekar recommendation visible on LinkedIn
All six portfolio pieces publicly accessible on GitHub
✦ Document360 content partner · documentation published and live
Get started

The audit is where you find out
exactly what is broken.

Every sprint that ships without a documentation update widens the gap. Your users are paying for it: in confusion, in support tickets, in churn nobody is measuring. The audit gives you a prioritised action plan in five working days. Specific findings. No generic advice.

Limited availability. Currently taking new audit clients.

Worth considering

One mis-documented API endpoint costs your engineering team 3–5 hours of support time. The audit costs less than a single engineer’s half-day. The question is not whether you can afford it — it is whether you can afford not to.

Documentation Audit — I read your docs. You get clarity.

A full review across accuracy, structure, ownership, and findability. Every finding is specific. Every recommendation is actionable.

  • Full review across all four dimensions
  • Prioritised action plan with specific next steps
  • Structural recommendations and ownership map
  • 30-minute walkthrough call
  • Written report in five working days
€300
Fixed fee · No surprises
Delivered in 5 working days
Book the Documentation Audit → Send a message

Get new writing when it publishes

Read the blog → All services →