What an Owner's Manual for your software contains

An Owner's Manual for your software is a set of six plain-language documents, each reviewed and signed off by an engineer, that explain what your software is built on, who can do what inside it, how its data is organized, how secure it is, what needs updating, and how well it's tested. It takes a week to produce. When you're done reading it, you can answer any question a buyer, a partner, or a new developer asks you about the software your business depends on.

That's the short version. The rest of this post is what's in each document and why it's there.

Who it's for

You own software that someone else built. A freelancer, a small shop, a former employee, or an AI tool with you at the keyboard. The business depends on it. And if someone asked you tomorrow what it's built on, who has admin access, or what would break if a dependency was two years out of date, you'd have to go find the person who built it.

The Manual exists so you don't have to.

The six documents

1. What it's built on (architecture)

The languages, frameworks, hosting, and services your software uses, drawn as one diagram and explained in one page. It answers the question every new developer asks first, and it tells you whether the choices were reasonable for what the business needs.

2. User roles and permissions

Who can see what, who can change what, and who can delete what. Most owners are surprised by this one. It usually turns up an admin account nobody remembers creating, or a role that can do far more than its name suggests.

3. How data is organized (data model)

The tables, what they hold, and how they connect. This is the document a buyer's diligence team reads first, and it's the one that tells you whether a report you've always wanted is a small change or a rebuild.

4. Security review

Where the software is exposed and how it handles the basics: authentication, secrets, backups, and what happens when someone leaves. Findings are ranked by how much they matter, in language you can act on.

5. What needs updating (dependencies)

Every piece of third-party code the software relies on, how far behind each one is, and which updates carry risk. Out-of-date dependencies are the most common reason software that "works fine" stops working one Tuesday.

6. How well it's tested (test coverage)

Which parts of the software have automated tests behind them and which don't. This tells you where a change is safe and where it's a gamble, which is exactly what you need to know before you ask anyone to change anything.

What you can do with it

Three things, mainly.

Hand it to a developer. Any developer, including one you haven't hired yet. The Manual is written so a new engineer can pick the software up without a hand-off call from the person who built it. That alone removes the single biggest risk most owners are carrying.

Hand it to a buyer or a partner. If you ever sell the business, bring in a partner, or raise money, someone will ask for exactly this. Having it ready changes the tone of that conversation.

Decide what to do next. The Manual ends with a recommended path and a firm quote for our work: run it yourself, an Adoption Sprint to get it into steady hands, or straight to Operate. The quote covers Cloudburst. Hosting, databases, and third-party services stay in your name and are billed by those providers.

What it costs and how long it takes

$1,500 and one week. We'll need read access to the code repository and the database before we start, which also tells you something: if nobody on your side can grant that access, that's the first finding.

The guarantee, in full: Read your Owner's Manual. If your software doesn't finally make sense to you, don't pay — and keep the manual.

See the Owner's Manual, or talk it through first.