How do I prepare a SaaS product’s documentation for a buyer’s developer?

Begin with the map. A short architecture page should show the main parts of the product, the data stores, the outside services it calls, and how a customer request travels through them. Add a plain list of every account the product depends on, such as hosting, payments, email, monitoring and domain registration, with the account owner for each.

Next, write the runbook. How does a release go out? How is it rolled back? What happens when the database fills up or a scheduled job fails? Include the odd things only you know: a manual step on the first of the month, a customer with special settings, a fix that must be repeated. These are the items that cause trouble after you leave.

Then admit what is weak. A list of known bugs, shortcuts and aging components lets the buyer’s developer plan, and it builds trust. Test the whole bundle by asking a developer outside your business to set it up from your notes alone. Whatever they ask you becomes the next page to write. Date every page, so the buyer knows how current it is.

Key takeaways

• Draw the architecture and list every outside account with its owner.
• Write the runbook including manual steps only you know.
• Test the documents with a developer who has never seen the code.
• Date every page so the buyer knows how current it is.