How long does it take to write technical documentation?

29 September 2026 · 6 min read

Longer than the writing alone, because the writing is only one part of a doc. Understanding the feature, trying every step, capturing screenshots and working through review rounds take the rest, and how that splits depends on the type of doc and how finished the feature is. The dependable estimate comes from measuring one real doc, stage by stage, from the ticket to the published page.

Why docs estimates slip

A docs estimate usually starts as a guess at drafting time: a page, a few hours. The work around the draft is what moves the date:

• Research: reading the spec, the code or the pull request, and asking engineers what the feature is supposed to do.
• Testing the steps: running every command and clicking every button yourself, often in an environment that has to be set up first.
• Screenshots and diagrams: capturing, cropping, annotating, and recapturing after the interface changes.
• Review: technical review for accuracy, editorial review for style, and a round of fixes after each.
• Publishing: the docs build, broken links, navigation, redirects.

The type of doc changes the mix. Reference pages lean on research. Tutorials lean on testing. Release notes lean on finding out what actually shipped. A single hours-per-page figure hides all of that.

What to measure

For one doc, keep:

1. Active hours by stage: research, drafting, testing, visuals, review fixes, publishing.
2. Elapsed days from starting to published, and how many of those days were spent waiting on a reviewer or on the feature.
3. The doc type, so you compare like with like later.

Active hours tell you how much work a doc is. Elapsed days tell you when to start. An estimate that only covers the first is the one that gets caught out by the second.

Recording your hours without a timer

Docs work is interrupt-driven. You draft for twenty minutes, run a command that fails, ask an engineer in chat, wait, and switch to another doc. Timers do not survive that.

Punchcard is a Mac menu bar app that notices which app is in front during your day, by name only, and prints a receipt at the closing time you set: the top five apps with the time on each, the rest as MISC, and a day total. You never start or stop anything, and it needs no macOS permissions.

The docs stages map onto apps closely enough to be useful. The text editor is drafting. Terminal is testing commands. The chat app is research with engineers. The image editor is visuals. The browser is everything that happens on the web: reading the code host, checking the docs preview, working through review comments.

That browser line can easily be the biggest on a docs day, so itemized browsing helps. Switch on “Itemize websites” in Settings, and browser time in the supported browsers prints as the sites you used: the code host, the issue tracker and the docs preview, each on its own line. Only the site name is kept, never the full address, the repository path or the page title. Web apps vs desktop apps explains why this matters when so much work lives in tabs.

The limits, plainly:

• No per-doc or per-ticket tracking. Punchcard has no projects or tags. Note which blocks belonged to the doc you are measuring; the CSV export lists every session with its start and end times so you can add them up.
• Meetings and walkthroughs away from the Mac are not on it. Add them from your calendar.
• It does not see content. It never records window titles, file names, keystrokes or screen contents, so it cannot tell a first draft from a review fix inside the same editor. You add that label.

On a work Mac, ask before installing anything. Punchcard needs no macOS permissions, keeps its record in one file on the Mac, and your tracked data never leaves it, which makes the question easier to answer, but the answer belongs to your IT team.

Tracking never expires and the CSV export works without a license. The first two printed receipts are free; printing after that needs a $9 one-time license.

A one-doc measurement

1. Pick a typical doc that is about to start, and note its type.
2. Each evening, write a line when the receipt prints: date, hours on this doc, the stage, and whether you were blocked.
3. Log the waiting days as waiting, with what you were waiting on.
4. When it is published, total the hours by stage and count the elapsed days.
5. Add a row to a table by doc type. After three or four docs of the same type, you have a range you can quote.

Using the numbers in planning

With a range per doc type, an estimate becomes a short calculation: active hours for the type, plus one review round per reviewer, plus the waiting your team usually does. Give it in planning as two numbers, hours of work and days to publish, so nobody mistakes one for the other.

The stage totals also point at fixes that have nothing to do with writing faster:

• Research is the long stage. Ask for a short walkthrough with the engineer before you draft, instead of a dozen chat threads afterward.
• Testing is the long stage. Ask for a stable test environment or a sample account. Setting one up yourself for every doc is time nobody planned for.
• Review is the long stage. Agree on who reviews what, and batch the comments into one round.

If you work alongside developers, their day has the same shape. Time tracking for developers and how much of your week goes to code review measure it from their side, which helps when you are negotiating for an engineer’s time.

Questions

Does Punchcard read my drafts or the code? No. It records app names only, never window titles, document names, URLs, keystrokes or screen contents. With itemized browsing on, it keeps site names and nothing more.

Can my manager see my hours? No. There is no account, no cloud and no team feature. You share a receipt as a PNG or plain text if and when you want to.

We write docs in a browser-based editor. Does that still work? It shows up on the browser’s line. With itemized browsing on, the editor’s site gets its own line in the supported browsers.