Almost every knowledge base is built in the same order and almost every one stalls at the same point, about six weeks in, with a beautiful structure and eleven articles in it. This is the order that does not do that.
Start from the questions, not the structure
Open the support inbox, the Slack channel where people ask things, and the onboarding notes. Write the questions down. Forty questions is a realistic first list and it is the only artefact in this process that is definitely accurate, because it is a record of what was actually asked.
Group them afterwards
Categories that come out of real questions are the ones readers can navigate, because they were derived from how people think about the problem rather than how the company is organised. A structure invented first always has a section nobody files anything under.
Assign owners before writing
This is the step everybody skips and it is the one that decides survival. An article with no owner has nobody to ask in six months. Count it before you commit: the planner on this site turns categories, articles and owners into the reviews each person will carry a month, and a base whose answer is twelve a month will not be maintained.
Write the smallest useful version
One screen per article, answering one question. Short articles get finished, get read and get reviewed. Long ones get half-written, and a half-written article is worse than none because it looks like coverage.
Shortcut one: importing everything
Bulk-importing the old drive feels like progress and imports the staleness with it. You now have four hundred articles, no owners and no idea which are true, which is a harder position than the empty base you started with.
Shortcut two: launching without a review date
The base is correct on the day it launches and that is the last day anybody can be sure of it. A review date set at launch costs nothing and is one field on a form; retrofitting one to four hundred pages after two years is a project with a name, a budget and somebody's evenings in it.
A worked plan: forty articles, five owners, six months
Forty questions from the inbox group into seven categories. Five people take them: the support lead takes billing and accounts, the product manager takes the two feature categories, the operations lead takes the how-do-I questions, and two engineers split the technical ones. At an hour and a half each that is sixty hours of writing across the five, most of it in the first month. On a six-month review cycle it is eighty reviews a year, sixteen per owner, one and a bit a month each. The planner on this site prints those figures from your own categories, articles and owners, and the useful thing it does is print the number that makes somebody say no before the base exists rather than after.
What launch looks like, and what the first review finds
Launch is twenty articles, not forty: the twenty the inbox ranked highest, each with an owner, a published date and a review date six months out, and a note in the base that says what is not here yet and where to ask. The remaining twenty follow as they are written, which keeps the base honest about its coverage. The first review cycle, six months on, is the moment the base either becomes a habit or a graveyard, and what it finds is predictable: a third of the articles unchanged and still true, a third with a screenshot or a step out of date, and a handful answering a question nobody asks any more. Confirming the first third takes minutes each; fixing the second takes an afternoon; retiring the last is the part nobody enjoys and the part that keeps the base small enough to maintain.
Questions people ask about building a knowledge base
How long does a first base take?
For forty articles at an hour and a half each, about sixty hours of writing spread across the owners. The planner prints the number for your own structure, which is worth doing before promising a date.
Who should write the articles?
The person who answers that question today. Handing the writing to one person produces a consistent base that is wrong in places nobody can spot, because they were not the ones being asked.
What if we already have a mess?
Do not import it. Start the question list from the inbox as though the mess did not exist, then check each new article against the old drive for anything worth keeping. Most of it will not be.
Where should the base live?
Wherever the team already writes, unless it is customer-facing and needs a domain and anonymous access. The platform is not the hard decision; the ownership and the review dates are, and they can be kept beside any platform, which is what the record on this site does.