About the role
Customers integrate this product as an API and as a tool their agent calls. That makes documentation part of the product: a wrong or vague page costs a customer a day, and costs us a renewal.
You would own the developer documentation end to end: getting started, the contract model, the served tool's parameters and safety behaviour, the MCP and REST integration paths, plus the in-product copy that explains what a receipt or a ratchet field actually means.
The bar is that every example runs. Documentation here is written against the real API, and a page that drifts from the code is a bug.
What you'd do
- Own developer documentation: getting started, the API reference, integration guides and the safety behaviour
- Write the in-product copy for concepts a customer meets for the first time: contract, receipt, release, withheld
- Keep every example runnable, and treat documentation that has drifted from the code as a bug
- Turn recurring support questions into pages, and measure whether the questions stop
- Keep one voice across the docs, the product and the site
What we need
- Three or more years writing technical documentation for a developer audience
- You can read code well enough to document an API without being dictated to
- You have owned a documentation site and its information architecture, not just written pages for one
- You write plainly: short sentences, concrete nouns, no marketing adjectives
- You test your own instructions by following them on a clean machine
Nice to have, not required
- You have documented an SDK, a CLI or an agent-facing tool
- Experience with docs-as-code and review through pull requests
- You have written a migration or deprecation guide people managed to follow
How we work
- Small team, thin slices, shipped weekly. Nothing sits on a branch for a month.
- Reviews are real. Every feature ships with its tests, and a bug found in review is cheaper than one found by a customer.
- Safety-critical means the boring answer usually wins: fail closed, keep the receipt, don't guess.
- We only claim what ships. That applies to the product, the roadmap and the offer letter.
How hiring works
- 1A 30-minute call about something you've built and what was hard about it.
- 2A working session on a real problem from this codebase. You can drive, or we can pair.
- 3A conversation about how you make decisions when the evidence is thin.
- 4References, then an offer. We aim to answer within a week at every stage.