Help center · Comparison
Knowledge base vs documentation: what goes where?
Documentation explains how your product works, piece by piece. A knowledge base answers the questions people get stuck on. They overlap, but they're written for different moments.
Two different moments
Documentation is for someone who wants to learn. A developer reading your API docs, or a power user going through every setting. They often read in order, and they expect everything to be there.
A knowledge base is for someone who is stuck right now. They type “change email” or “export to CSV” into a search box. They want one answer, fast, and then they want to get back to work.
Example: your API docs have a full page on authentication, with tokens, scopes, expiry and every error code. Your knowledge base has one short article: “I get a 401 error. What's wrong?” It lists the three usual causes and links to the full docs page.
| Documentation | Knowledge base | |
|---|---|---|
| Reader | Wants to learn or build | Wants to get unstuck |
| Shape | Complete, organized by feature | Short, organized by question or task |
| Typical title | “Authentication” | “Why do I get a 401 error?” |
| Changes when | The product changes | People ask new questions |
Do you need both?
If your product has an API, a command-line tool or a lot of settings, yes, sooner or later. If it's a simple app with a few screens, probably not. A small knowledge base can carry you a long way. Most users of small apps don't read manuals. They search when they're stuck.
A good test: who is asking? If developers ask how something works, write documentation. If users can't finish a task, write help articles.
How to keep them from repeating each other
The risk with two places is two copies of the same answer. One gets updated, the other doesn't, and the customer finds the old one.
- Documentation holds the full details. The help article gives the short answer and links to them.
- Don't copy steps between the two. Link instead.
- When a feature changes, search both for its name before you ship.
Starting small
If you have no docs and no help yet, start with the knowledge base. Write the five answers you've already sent by email more than once. The questions that keep coming will show you which topics need deeper documentation.
Quick rule: If the title is a feature name, it's documentation. If the title is a question or a task, it's a help article.
MVPKit is built for the knowledge base side: a public help page for each project, with categories, articles and search, plus a contact form for questions the articles don't answer. It isn't a developer docs tool. If you need versioned API reference, use a docs generator and link to it from your help.
Need a place for the answers your users look for? Take a look at MVPKit.