Product documentation often falls short at the table of contents. Readers have three different types of questions. A set that mixes concept, tasks, and references on the same page will serve none of the questions.
The first deliverable is usually a structure. Pages get written into it afterward, each with one task and a clear idea of who the audience is.
Documentation is read by people who may have little to no familiarity with a topic, often through a translation, and often entered into the documentation halfway through via a web search result. Keeping sentences short and concise, as well as using the same terms consistently, will remain helpful to all readers. When describing a concept, use the same word each time to convey the idea. This helps prevent ambiguity and is a great help to the reader. Avoid overcomplication by using different terms.
The author of the generated documentation is overconfident about defaults. He writes about limits, settings, and file paths that can be considered standard because they are standard somewhere else, and there is no way a reader can distinguish invented from real. A wrong number, if used in the documentation, has a greater negative impact than having a number missing.
The writer has now spent sufficient time with the product to offer insights, which requires an account, data with realistic numbers, and a list of workflows that are most important to the users. Next, we see what already exists and what users request. More often than not, this exercise shows two heavily documented areas and another with no documentation at all.
Documentation pays for itself when the product points at it. Contextual help links, empty states and error messages should link to a page that answers the question the user might have at that moment. We add these connections as we write, meaning the documentation isn’t just waiting on some website that no one ever visits.
One rate, whatever the format: $10 per 100 words. You are paying for the writer’s time and judgement, so the price scales with the words rather than with a package tier.
| Typical product documentation | Words | Writing | Fee (1%) | You pay |
|---|---|---|---|---|
| Single reference | 800 | $80 | $0.80 | $80.80 |
| Standard doc set | 2,000 | $200 | $2 | $202 |
| Full documentation | 5,000 | $500 | $5 | $505 |
The writer receives 100% of the writing price. Our 1% fee is added on top of it, and 0.5% is donated to tree planting. Full pricing breakdown.
Ask on the contact page and a person will answer, usually the same working day. For a live order, reply to your confirmation email and it reaches whoever is handling it.
Ask on the contact page and a person will answer, usually the same working day. For a live order, reply to your confirmation email and it reaches whoever is handling it.
We format Markdown files to match your file structure to make importing easier. It imports cleanly into most platforms, but to do so in your tooling is possible but becomes an access conversation rather than a standard order. Most teams find that reviewing files in Markdown is easier than working directly in your tooling.
Write down which pages are dependent on which sections of the product. Check those pages when the part of the product that the page is dependent on changes. We include the mapping of dependencies with the set. Unless someone tells you which pages are affected by each release, your documentation will rot.
Completely. Copyright transfers to you on delivery, with no attribution requirement and no licence back to us. Nothing written for you is resold, repurposed or republished.
Reviews from completed, paid orders in this category.
Our releases happen every fortnight, and our notes have evolved into change logs. To keep things organized, the writer has noted what changed within a card or view and what changed underneath. Each note is a brief summary of the change. The biggest metric I’m interested in post release is the volume of support tickets. It always dips.
Our release notes went unread, but they serve the purpose of listing what breaks and what doesn’t when considering whether to upgrade. Two customers actually took the time to send thank yous in the same week, something that had never happened before.
They requested access to our staging endpoint with read access and used it too. The auth section of your docs shows us the 409 error we return for duplicate idempotency keys. That error is not documented anywhere in our old docs. Contract documentation has never come back and educated me about my API before.
We do not ask you to take the no-AI promise on trust. Each draft is run through these platforms and the reports are attached to your delivery email.
Originality.aiAI detection + plagiarism
GPTZeroAI detection
TurnitinAI detection + similarity
CopyleaksAI detection + plagiarism
Winston AIAI detection
ZeroGPTAI detection
SaplingAI detection
Content at ScaleAI detection
Send the brief, get a human draft back within 3 days. No account, no subscription, no AI.
$10 per 100 words · all of it to the writer · 0.5% to trees