You are stuck on an API reference that says an endpoint returns a user object and nothing more. No example. No word on what happens when the token expires. So you open the sandbox, make the call, watch it fail and write down exactly what happened. Without noticing, you just did paid work.
Maybe you are a developer who is better at explaining than shipping, or a writer who has always liked technical things. Either way, you have seen the headlines about AI writing everything and wondered where that leaves you. It leaves the people who verify, structure and test ahead of those who only write fluent sentences.
Here is the honest picture. The field is flat: 1% growth between 2024 and 2034, about 500 jobs added across a workforce of 56,400, against 3.1% for the economy as a whole. Work still turns over at roughly 4,500 openings a year. Those openings go to people who can show a portfolio, and every month you wait, more people with AI tools are building one.
Getting started costs you anywhere from nothing to about $400. First money typically arrives after 2 to 6 months, and $1,000 a month is a fair picture of the early rungs. Companies pay because the engineers who built the endpoint can no longer see what a newcomer does not know.
Tonight, open the docs of one API you already use. Find the page that left you guessing, and rewrite it the way you wish it had been written.
Well paid and barely growing. That combination is the whole strategic picture for you, and it leads to a specific and slightly surprising conclusion about where the work is.
Set that against net growth of 500 jobs over a decade. Almost every one of those 4,500 annual openings is replacement demand, meaning people leaving the occupation rather than new positions being created. Writers retire, move into product management, move into developer relations, or leave for roles next door.
Why does that matter to you? Because a flat occupation with high replacement demand behaves very differently from a shrinking one. You get 4,500 chances a year to enter a field paying a $91,670 median. What you will not find is a growing crowd of employers competing for writers, which is what would push those salaries up.
So here is the practical reading. Jobs in this field are available but static, and your leverage sits in selling documentation as a service to the many organisations that need it and have no technical writer at all. BLS cannot see that market, because it counts employees and you would be counting engagements.
I want to dwell on that gap between what the statistics count and where the work is, because it comes up across several guides on this site and people misread it again and again. An occupational projection measures payroll positions at organisations large enough to have them. It says nothing about the software company with forty people, an API, and documentation written by whichever engineer had time. There is no employee to count there, so the demand stays invisible to the statistics while being entirely visible to anyone who tries to integrate with the product. A flat projection tells you about hiring, and says little about need. Reading it as a verdict on the whole field is the most common mistake people make with these numbers.
The apparent contradiction clears up once you look at what generative tools did to the work.
Drafting prose from a specification got dramatically cheaper. So did tidying inconsistent terminology, generating boilerplate reference sections, and producing a first pass at a how-to guide. These were real parts of the job, and they are now fast.
What stayed expensive is everything that depends on knowing whether the documentation is true.
A model can write a fluent explanation of an API endpoint from its signature. It cannot run the endpoint, discover that the documented parameter was renamed two releases ago, notice that the error response is undocumented, or work out that the recommended approach breaks under pagination. That checking is the actual product you sell, and it takes access to the system, access to the engineers, and the willingness to test what you are describing.
So the pay stays high because the remaining work is skilled, and the headcount stays flat because each writer now covers more ground. You will see the same pattern in the graphic design guide on this site, with one important difference: designers' median sits at $61,300 while technical writers are at $91,670, because the checking here is harder to fake and getting it wrong is more visible.
The headline growth number is close to nothing. So where do those 4,500 yearly openings actually sit, and which of them pay well?
There are five categories, and they pay very differently.
A sixth category deserves its own mention, because it is growing and barely staffed: documentation for machine readers. As more software gets integrated by AI agents instead of by developers reading pages, the qualities that make documentation useful shift. Structured, complete, unambiguous reference material with machine-readable specifications and consistent naming matters more, and discursive tutorials matter less. Companies are starting to notice that their documentation is now read by systems that cannot ask a clarifying question or infer intent from context. Nobody has a decade of experience writing for that reader, so it is unusually open to you if you enter now. It is the one part of this field where you can genuinely be early.
Across all five, value follows the cost of the documentation being wrong. Where wrong means a support ticket, rates are moderate. Where wrong means a failed integration, a compliance finding or a safety incident, rates are high.
API documentation sits where a wrong page means a failed integration, which is why it pays at the top of this field. Even at the low end, around 1,000 a month, a single retained client could fund your child's coding club and the laptop they need for it. Win that client by showing a guide whose code you have run yourself.
Think about what one steady documentation client could change. A bill covered every month, or the first real cushion in your savings account. Clients who trust your docs keep coming back, because changing writers means teaching someone new everything you already know.
Anyone can write clearly. The rate difference comes from something narrower.
Employment is flat, and nobody measures the demand for engagements. That second part is where your opportunity sits.
Verification passes on generated documentation. New, growing, and created directly by the tools that flattened the field. Companies generating documentation at volume need someone to confirm it is accurate, and that service has a clear scope and an obvious value.
The buyer to target is a software company with an API, engineers who dislike writing, and no technical writer. That description fits an enormous number of companies, and the ones actively losing customers to bad onboarding documentation are the most motivated. Can you name three of them from the tools you used this month? Start your list there.
Building a portfolio with no clients
You now know what you are selling. The next problem is showing someone the work before anyone has paid you for any of it.
Everyone entering hits the same wall: clients want to see documentation you have written, and you cannot show work nobody has hired you to do. This field has an unusually clean way through.
Document an open source project. Thousands of genuinely useful projects have poor documentation, the maintainers know it, and they welcome contributions. Pick a project, set it up as a new user, document what was missing, and submit it. The result is public, has your name on it, is reviewed by real maintainers, and is demonstrably used. No client work gives you all of that.
Write the quickstart that was missing. Skip polishing prose. Find a project where getting started is genuinely hard and write the guide that fixes it. That is the single most valuable artefact in developer documentation and the easiest way to show your value, because a reader can follow it and see whether it works.
Document a public API you did not build. Pick a service with mediocre reference documentation, integrate with it, and publish a better integration guide. This proves the two things clients care about: you can read an unfamiliar system, and you verify what you write instead of copying it down.
Show the defects you found. A portfolio piece saying "the existing quickstart failed at step three because a prerequisite was undocumented, here is the corrected version" persuades better than any polished sample. It shows the checking work, and that is what sets you apart from generated output.
Contribute to documentation in the toolchain. Doing this through pull requests in a real repository also proves you can work docs-as-code, which is the other thing the better-paying clients screen for.
This works better here than in most fields because documentation quality can be checked objectively. A prospective client can follow your guide and see whether it gets them working. Very few portfolio pieces in any discipline can be tested that directly. Which open source tool have you sworn at during setup? That one is your first portfolio piece.
What to charge
That handles your samples. Now for the question at the top of this page.
There is no published freelance rate card for technical writing, so anchor on the employment figure and adjust for what freelancing actually costs you.
The BLS median of $91,670 works out to roughly $44 an hour of salary value. Your freelance rate also has to cover the missing benefits and paid leave, the unbillable hours you spend selling and on admin, gaps between engagements, self-employment tax, and the employer overhead you now carry yourself. The usual multiple for turning a salary into a defensible freelance rate lands well above that figure, and specialists in API documentation and regulated sectors sit higher again.
Better still, avoid the hourly conversation entirely.
Price the audit as a fixed fee. It has clear limits, it is the natural first engagement, and its value lies in the defect list. The hours you spent finding the defects are your business.
Price documents as deliverables. A quickstart, a migration guide, a set of reference pages. State what is included, how many review rounds, and the turnaround.
Price the retainer per release cycle. This arrangement matches how documentation actually decays, and it is easier to renew than a project is to repeat.
Two things justify a higher number, and you should say both plainly in a proposal. You verify what you write, which means running the software and reporting defects the client did not know about. And you work in their repository through their review process, so no engineer has to reformat anything you produce.
Pricing up from the $91,670 median gives you a floor that covers your real costs. If the work reaches the middle of this range, a few thousand a month from API guides could leave enough after costs for three nights somewhere new with your partner, booked without months of saving first. What would your last quote have looked like with testing and review time priced in? Price your next proposal to cover both.
Rookie Mistakes
Writing from the specification without running anything. This is the fastest way to produce documentation that is fluent and wrong. If you have not executed the thing you are describing, you are copying down a spec, and your reader deserves a tested page.
Organising around the system instead of the task. Documentation that mirrors the codebase is comfortable to write and hard to use. Start from what your reader is trying to accomplish.
Charging hourly. Your speed improves quickly with tooling and experience, and hourly billing turns that improvement into a pay cut.
Competing on writing quality alone. Fluent prose is now cheap. What sells is accuracy, verification and structure, and if you position yourself on writing craft alone, you compete with something that costs nothing per extra page.
Avoiding the toolchain. Refusing to work in a repository, in Markdown, through pull requests, shuts you out of the best-paid part of this field.
Accepting an engineer's explanation without testing it. Engineers describe how the system is supposed to work. What it actually does is sometimes different, and finding that gap is part of what you are paid for.
Neglecting the maintenance conversation. Documentation written once and never updated becomes actively harmful, because readers trust it. Raise this at the start and it leads naturally to the retainer.
Documenting everything equally. New writers try to cover the whole surface at the same depth, which spreads effort across pages nobody reads and leaves the critical path thin. Most readers follow a small number of paths, and the quickstart and the top few integration flows deserve more care than the rest of the reference combined. Ask your client which three tasks matter most and build outward from those, and you get a visibly better result for the same budget.
Accepting a rewrite brief without auditing first. A client asking for a rewrite has usually spotted a symptom and missed the cause, and the cause is often structure. If you quote a rewrite before checking that, the project can end with better-written documentation that is still hard to use.
Finding clients
A rate only matters once somebody asks you for one. What follows decides how often that happens.
Your buyer is unusually easy to describe, which lets you prospect more precisely here than in most freelance work.
A software company with an API, engineers who dislike writing, and no technical writer. That is the whole specification, and it fits an enormous number of companies. Approach first the ones whose documentation is visibly failing.
Diagnose before you contact. Try to integrate with their API as a new developer would, using only their documentation. Note where it fails. That failure list becomes your opening message, and it persuades far better than any pitch, because you are handing them evidence.
Approach developer relations and engineering leadership first. Documentation quality shows up as support load and failed integrations, and the people who feel that pain are the ones who can approve fixing it. Marketing owns the website and rarely owns the docs.
Time it to a launch. A company shipping a new API, a major version or an SDK has an urgent, dated documentation need and often no capacity. Launch announcements are your prospecting list.
Watch for the support-load signal. Public issue trackers, community forums and support channels full of questions the documentation should have answered show you a company paying for bad docs in engineering time. Put a number on that and you have a strong argument.
Subcontract through agencies and developer relations consultancies. They win work they cannot staff. You accept a lower rate because they hold the client, and in return you have no sales function to run while you build your portfolio.
Ask the maintainers you contributed to. If you built your portfolio by documenting open source projects, those maintainers work somewhere, and some of their employers need exactly this.
Your strongest opening is still the audit offer framed as evidence: here are six specific places your quickstart fails, and here is what it would cost to fix them. That converts far better than describing your writing experience. Could you find six failures in a stranger's quickstart in one evening? Try it on one company this week, and you will know whether this work suits you.
Each week you hold off, another writer sends the audit you could have sent and becomes that company's go-to person for docs. Your first client is probably one well-documented failure away. Tonight, pick one company, run their quickstart, and note every point where it breaks. Send it tomorrow.
Gotchas Worth Knowing
Access is the bottleneck, and it is often slow. You need the environment, the credentials, the repository and the engineers' time. A project that looks like three weeks of writing becomes eight because access took a month. Make access a contractual dependency with a stated start condition.
Subject matter experts will disappear mid-project. The engineer you depend on gets pulled onto an incident. Build this into your timeline and your terms instead of quietly absorbing it.
Documentation debt is usually worse than the client believes. An audit often finds that the existing documentation describes a version of the product that no longer exists. Scope the audit before you commit to a rewrite price.
Review cycles expand without a cap. Engineering review is necessary, and it is also where projects lose their margin. Agree two defined rounds, with a stated rate for any more.
You may need to sign broad confidentiality terms. You are being given access to unreleased features and internal systems. That is normal, and it limits what you can show in a portfolio, so agree publishable case study terms early.
Regulated documentation carries real liability. In medical devices, aviation and similar sectors, documentation is part of the compliance record. Understand what you are signing before you work in those fields, and price accordingly.
The product may change under you mid-project. Software ships continuously, and a team can rename a parameter or restructure a flow while you are documenting it. That is normal, and it says nothing bad about your client. Agree what happens when it occurs: whether changes during the engagement are absorbed, billed, or deferred to the next cycle. Silence on this point means absorbed, and on a fast-moving product that can eat your whole margin.
Your best work is invisible and hard to credit. When documentation is good, integrations succeed and nobody notices why. Support tickets that never get filed appear in no report. That makes renewal conversations harder than the value deserves, so capture the evidence while you can: the defects you found, the failed steps you fixed, the support threads that went quiet. Without that record, your client remembers the invoice and forgets the problem.
How documentation became a profession
The shape of this job, and why it pays what it does, comes from a specific history you should know.
Technical writing began as a manufacturing function. Complex machinery needed manuals, and the people who wrote them sat close to engineering because the information existed nowhere else. The defining rule was that the writer had to understand the machine, and that rule has never gone away.
Software inherited the practice and changed the economics. Manuals became help files, then web pages, then sites updated all the time. The important shift was in the update cycle: a printed manual described a product that had shipped, while software documentation describes a product that changes weekly. Documentation stopped being a finished object and became an ongoing process.
Then developer-facing software changed it again, and this change produced the pay. When your customer is a developer integrating your API, your documentation is the product surface itself. A prospect evaluating a service reads the docs before they ever talk to sales, and if the quickstart fails they leave. That made documentation quality a direct revenue input at a kind of company with money, which is why API documentation pays what it does.
Two structural facts follow from that history, and both explain where you stand today.
Documentation quality can be checked in a way most writing cannot. A reader either gets working or does not. That objectivity is unusual, and it is why building a portfolio works so well here and why generated documentation gets found out.
And a writer's value has always come from closeness to the system, with command of prose a distant second. The manual writer needed to understand the machine; you, as an API writer, need to run the endpoint. Every wave of tooling that made the prose easier left that requirement untouched, which is why the field survived desktop publishing, content management systems, structured authoring and now generation.
Working with engineers
Most of the difficulty in this job sits outside the writing. It lies in getting accurate information from people who are busy, who find explaining tedious, and who often do not remember which parts are undocumented because they have known them for years.
Arrive with specific questions, never with a blank page. "Tell me how authentication works" gets you a twenty-minute ramble. "I got a 401 calling this endpoint with a token that works elsewhere, is there a scope requirement that is not in the reference?" gets you a two-minute answer and the engineer's respect.
Do the reading first. Read the code, the tests and the pull requests before you ask. Tests in particular are documentation written by someone who had to be precise, and they answer a surprising share of your questions without troubling anyone.
Ask about failure as well as success. Engineers naturally describe the intended path. Documentation defects cluster in what happens when something goes wrong, so ask directly: what does this return on a bad input, what happens on a retry, what breaks under pagination.
Never make them review three drafts. Ask for one technical review of something close to final. Writers who send draft after draft for comment teach engineering teams to put them last.
Surface disagreements and leave the ruling to them. When two engineers describe the same behaviour differently, you have a finding, and it is theirs to settle. Writing it down and putting it in front of them is genuine value, and it is often the moment a team realises the documentation project is worth having.
Give them credit. Thank an engineer publicly when their explanation improved the docs, and they become a willing source for your next question. It is the cheapest investment you can make in a job that runs entirely on other people's attention.
Report defects as findings. You will discover things that are actually broken: an endpoint returning the wrong status code, a parameter that does nothing. Raise these as bugs you found while documenting, in the team's own tracker, in their format, and you become an asset. Raise them as proof the documentation was impossible to write and you become an irritation. The difference is entirely in how you frame it. How would your last complaint about a tool read if you rewrote it as a bug report? That rewrite is the habit to build.
Who This Suits
I will be direct here, because the barrier to entry is unusual: what you need is comfort with technology, and writing ability comes second.
It suits you if you write clearly and code does not scare you. You do not need to be an engineer. You need to read a function signature, run a code sample and notice when reality and the documentation disagree. Someone who can do both halves is rarer than someone who can do either.
It suits you if you are a developer who dislikes building but likes explaining. That is a genuinely common profile, and the field pays it well, because the verification work that makes documentation valuable is trivial for someone with an engineering background.
It suits you if you enjoy bringing order to a mess. Most of the highest-impact work is structural: realising the documentation is organised around the system when it should be organised around the reader's task.
It suits you if you can be pleasantly persistent with busy specialists. Much of the job is getting twenty minutes from someone who would rather be coding, again and again, without becoming an irritation.
It will frustrate you if you want to write creatively. Good documentation is invisible, plain and unmemorable. Prose that draws attention to itself counts as a defect here.
It will frustrate you if you need money quickly. Access alone often takes weeks, and your first engagement typically starts with an audit before any substantial fee. Could your savings carry you through 2 to 6 months before the first payment? If not, start this alongside your current job.
It will shut you out if you refuse to work in a repository. That single preference excludes you from the best-paid segment.
Behind the scenes: an API documentation project
The realistic version begins with a client who thinks they need writing and actually needs testing.
A software company has an API, a set of reference pages generated from code annotations, and a complaint from their sales team that prospects cannot get integrated. They want someone to "clean up the docs".
Your first week involves no writing. You spend it getting access, which takes longer than anyone estimated, then setting up the environment as a new developer would, using the documentation as it stands.
That exercise is the audit. You fail at step three because a prerequisite is undocumented. You fail again at step six because a parameter was renamed. The error you get appears nowhere in the documentation. By the end you hold a list of defects nobody inside the company could have produced, because everyone inside already knows the undocumented parts.
Then comes the structural finding, which is usually the same: the documentation is organised by endpoint, and the reader wants to accomplish a task that touches four endpoints in a specific order. No amount of improving individual pages fixes that.
Then the interviews, twenty minutes each with engineers who are helpful and busy, to settle what the code could not tell you: which approach is recommended, what the rate limits actually are, what happens on retry.
Then the writing, which is the fastest part and the part the client thought they were buying.
Then review, where an engineer disagrees with a recommendation you documented, and it turns out two engineers disagree with each other, and the documentation cannot be finished until they settle it. Surfacing that disagreement is genuine value, even though it will not feel like it at the time.
Then delivery, and the observation that all of this will be out of date in two releases. That is your retainer conversation.
And the retainer is where this work becomes reliable for you. A monthly fee to keep the reference pages current through each release arrives on schedule. It is the kind of income that could let three months of expenses sit untouched in savings, so the boiler repair gets approved without waiting for a new project. Ask who maintains the docs after the next release, and quote for that work.
Refusing to use generative tools in this field is a losing position: clients can see the productivity gain and will not pay for slowness. Using them badly is worse, because it produces exactly the confident, unchecked output that damaged documentation's reputation. There is a split that works.
Use them for first drafts of descriptive content. Reference sections, parameter tables, boilerplate structure. This is the work that got cheap, and pretending otherwise wastes your time and your client's money.
Use them to find gaps, and fill the gaps yourself. Ask a model what questions a reader would have about a page, or what is missing from a quickstart, and you get a useful checklist. You then answer the checklist by testing, which is the part it cannot do.
Never let them assert behaviour. Any statement about what the software actually does, what a parameter accepts, what an error means or what the recommended approach is must be checked against the running system. A model will produce a plausible answer for an endpoint that does not exist, and plausible-and-wrong is the worst documentation defect there is, because readers trust it.
Disclose it and make it a selling point. Tell your client you use these tools for drafting and verify everything against their system. That puts you in the right place: faster than a writer who refuses, and safer than output nobody checked. It is the honest description of the value you add, and it is the same division of labour every other guide on this site keeps arriving at.
Keep the verification record. Note what you tested, in what environment, on what date, and your accuracy becomes something you can show. It also makes the maintenance conversation concrete, because a verification dated three releases ago is visibly stale.
This matters for your income as well as your ethics. The market is currently full of cheap generated documentation, and clients are learning what it costs them. Being demonstrably the careful alternative is the strongest position you can hold, and it asks only that you actually do the testing. When you last used a model to explain an API, did you run the code it gave you? Make that the rule for every page you sell.
Where This Goes Next
These are four arguments about direction, offered as reasoning more than forecasts. The common thread is which parts of the work resist automation and which do not.
Headcount stays flat and engagements grow. The 1% projection measures employees. It leaves out the software companies with an API and no writer, and that is where demand is heading, because the work comes in projects and the need comes and goes.
Verification becomes a named service. As more documentation is generated instead of written, confirming that it matches the system becomes separate work. It uses the same skills, it is easier to scope, and it is growing precisely because generation got cheap.
Docs-as-code becomes non-negotiable. The gap between writers who work in the repository and those who do not will keep widening, because the first group can be part of the release process and the second cannot.
Regulated documentation holds its value best. Where a documentation defect is a compliance or safety issue, nobody will accept generated output without human sign-off. That segment is slow, exacting and durable.
The replacement demand stays and the way in narrows. Those 4,500 annual openings are people leaving, with few new positions behind them, and they will keep coming. What changes is the shape of the vacancy: fewer roles for a writer who turns specifications into prose, more for one who verifies, structures and works in the toolchain. That job is harder to enter with no technical exposure, which is why the portfolio route through open source contribution matters more to you each year.
Structure outlives prose. Information architecture, task orientation and knowing what a reader needs are the parts of this job with no automated substitute. If your value is fluent sentences, you compete with something free. If your value is knowing what to document, in what order, having verified it, you hold the part of the job that lasts.
As AI floods the world with fluent prose, the people who can prove their docs actually work grow scarcer and more valuable. That reputation takes time to build. The writers starting their portfolios now will be the obvious hires when companies realise generated docs are failing their users.