Documentation your integrators can build from, unaided.
API references, integration specifications, developer guides and release notes — written by the engineer who built the system, for readers who will never see the code.
Most integration failures are documentation failures.
The endpoint works. The other team still can't call it — because the spec omits the auth lifetime, or the example is a placeholder nobody can map to a real case, or two endpoints in the same document use different section orders and the reader stops trusting either. Documentation written by someone who has not built the thing produces text that reads well and is quietly wrong. I write from the implementation.
Everything this service covers
-
API & integration references
Endpoint-by-endpoint references with authentication, request and response schemas, worked examples and a status-code taxonomy precise enough to debug against.
-
Integration specifications
The whole contract between two systems, written for third-party engineers with no access to your side of it.
-
Developer guides & how-tos
Task-shaped guides that get a reader from nothing to a working call, in order, without prerequisites hidden three sections down.
-
Release notes & changelogs
What changed, what breaks, and what the reader has to do about it — separated, so nobody has to infer the third from the first.
-
Runbooks & internal handover docs
Operational documentation for the people who inherit a system: what it does, how it fails, and how to bring it back.
-
Documentation review & audit
An existing doc set assessed for accuracy, structure and clarity — including whether the examples actually run.
-
Docs-as-code setup
Markdown in Git with a static site generator, review through pull requests, and docs versioned alongside the code they describe.
-
Style guides & templates
A reusable per-endpoint template and house style, so the tenth document has the same shape as the first.
The outcomes you can expect
Correct, not just fluent
I build the integrations I document. The worked examples come from real payloads, so they hold up when someone pastes them into a client.
Structurally consistent
One template per endpoint, shared reference sections factored out. A reader who has used one document can navigate the next without re-learning it.
Written for the actual reader
Integration engineers outside your organisation, working from the document alone — not colleagues who can ask you a question.
Tools and platforms I use here
- Markdown
- Git
- Astro
- MDX
- OpenAPI
- Postman
- Word
- Confluence
- Mermaid
- JSON Schema
How we'll work together
- 01
Discovery
A free call to understand your goals, constraints and what success looks like. You leave with clarity even if we don't work together.
- 02
Proposal
A clear scope, timeline and fixed or milestone-based price. No surprises, no padded hours.
- 03
Build & ship
I build in focused iterations with regular demos, so you see progress and steer early — not at the end.
- 04
Support
Launch, monitoring and ongoing care. Systems need upkeep; I keep yours running and improving.
Related case studies
Two integration API specifications for a D365 F&O insurance deployment
Authored the integration API references — eight endpoints across two specifications — that let a large insurer's policy, claims and life-management platforms post transactions into Dynamics 365 Finance & Operations.
- 8 endpoints documented
- 2 specifications, sole author
A client portal API reference, written docs-as-code
The full API reference for a multi-tenant client portal — accounts, orders, two payment gateways, webhooks, subscription billing, usage metering and support messaging — written in Markdown alongside the code it documents.
- 25 endpoints documented
- 2 brands on one codebase
Technical writing & API documentation starts from $35/hr
Transparent USD pricing. Local (KES) and custom quotes available.
Common questions
What kind of documentation do you write?
Mostly developer-facing: API references, integration specifications, guides, runbooks and release notes. Most recently two integration API specifications covering eight endpoints for a Dynamics 365 Finance & Operations deployment at a large East African insurance group — see the case study.
Do you write in Markdown and Git, or in Word?
Both. I prefer docs-as-code — Markdown in Git, reviewed through pull requests, published with a static site generator — because it versions alongside the code. But plenty of enterprise clients need Word to a house template, and that is fine.
Can you document a system you didn't build?
Yes. I read the code and the endpoints and write from that, then verify the examples by calling them. That verification step is the part that catches specs which are plausible and wrong.
Will you sign an NDA?
Yes. Client work is confidential by default — the samples on this site are anonymised and every credential, hostname and token is replaced with a placeholder.
How is this priced?
Hourly for review, audit and ongoing work; fixed price per document set when the scope is clear. See pricing or ask for a quote.
Ready to get started with technical writing & api documentation?
Book a free 20-minute call. We'll map the fastest path from where you are to a working system — no pressure, no jargon.