What to Write First When You Have No Docs at All
A running order for building a help centre from nothing: which articles to write first, why that sequence works, and how to tell when coverage is enough.
Ten articles is roughly where a help centre stops being an embarrassment and starts being useful. Not fifty. Ten. That is a fortnight of evenings, or an afternoon if something is generating drafts for you, and it is a small enough number that the real obstacle is not effort at all. It is that nobody knows which ten. So the team writes "Getting Started", then "FAQ", then stalls for eight months.
The order matters more than the count, and it is not the order most people pick.
Start where the money is, not where the product starts
The instinct is to document in product order: sign up, then set up, then the first feature, then the second. That produces a tidy table of contents and a help centre nobody reads, because it mirrors how you built the thing rather than where people get stuck.
Document in order of abandonment risk instead. The first article should cover the step where new users most often stop, which is almost never the sign-up form and almost always the first moment the product asks them for something they do not have to hand - an API key, a DNS record, a CSV in a particular shape, a permission they need someone else to grant.
Here is the running order that has held up across the help centres we have built:
| # | Article | Intercepts |
|---|---|---|
| 1 | The one setup step that needs something external | "I got stuck on the API key bit" |
| 2 | The core loop, end to end, once | "What am I actually supposed to do here?" |
| 3 | The feature people ask about most in sales calls | the question your demo always gets |
| 4 | Inviting a teammate and what each role can do | "Can my designer see this?" |
| 5 | Billing: plans, limits, what happens at the cap | "What happens if I go over?" |
| 6 | The most common error message, verbatim | people pasting it into a search box |
| 7 | The second most common error message | as above |
| 8 | Importing or connecting existing data | "Can I bring my stuff over?" |
| 9 | Cancelling, exporting, deleting an account | the trust question nobody asks aloud |
| 10 | What the product deliberately does not do | the mismatched signup you would rather avoid |
Articles six and seven do the most work per word in that list. Users do not search for concepts, they search for the string in front of them, and an article titled with the literal error text will outrank every general troubleshooting page you ever write.
Two of those are not documentation at all
Nine and ten are there for a different reason, and it is worth being explicit about it.
Publishing your cancellation and export process is a trust signal. Buyers evaluating you at any size will look for it, and its absence is read - correctly - as a company hoping to make leaving difficult. Writing "here is how to get your data out" costs a page and removes an objection you will otherwise field over and over in email.
Article ten is even more useful and almost nobody writes it. A page that plainly states what your product is not for turns bad-fit signups away before they cost you a trial, a support conversation and a churn event. It is the highest-leverage page in this list and the one that feels most uncomfortable to publish.
How to know when ten is enough
You are done with the first pass when new inbound questions stop being answerable by an article you could have predicted. Not when they stop - when they stop being predictable.
Practically: keep a tally for a fortnight. Every question that arrives, mark it "should have been in the ten" or "genuinely new". When the first category drops below about one in five, the skeleton is doing its job and you should switch from writing new articles to improving the ones getting traffic.
What we didn't include
This list has a bias worth naming: it is built for self-serve SaaS with a technical setup step. If your product is sold entirely through demos and onboarded by a human, the abandonment risk sits somewhere else entirely - usually in month two, around a feature nobody showed them - and articles one and two are close to worthless for you.
It also says nothing about API reference documentation, which is a different artefact with a different reader and should be generated from your schema rather than written by hand.
And ten articles will not make a help centre feel finished. It will not look like Stripe's. That is fine, and chasing that on day one is how the eight-month stall starts.
Where to start tonight
Open your last twenty support conversations and tally the openers. The one you see four times is article one.
About the Author
Simon Moxon has been building SaaS companies since 2009. He's scaled teams to 20+ people, hit £2m ARR, and learned most of the lessons the hard way. Now he's building SupportPages.io - help docs that write themselves when you ship code. He writes about what's changed in SaaS and what hasn't.