The handover manual you build before you list (not after you've sold)

Ask a founder what they will do to get their business ready for sale and you tend to hear the same two answers. Clean up the code. Nudge the price. Both feel like progress. Neither is the thing that actually moves an offer.

The thing that moves an offer is confidence. A buyer is not paying for what the business earned last month. They are paying for the odds that it keeps earning after you walk away. Everything you present is really an argument about those odds, and the most persuasive argument you can make is a set of operating procedures that let the business run without you standing over it.

This is the handover manual. You should write it before you list, not after you accept an offer. Here is how, and why the timing matters more than almost anything else you will do.

Why the handover manual is a pricing lever, not paperwork

A small digital business is usually one person deep. You are the onboarding flow, the billing team, the support desk and the deploy pipeline, all at once, mostly in your head. That is fine while you own it. It is the single scariest thing a buyer sees, because on the day you leave, all of that leaves with you.

The handover manual is the answer to that fear, written down. It says: here is exactly how this runs, and you do not need me to run it. A buyer who believes that will pay more and argue less, because you have removed the risk they were quietly pricing in.

This is not the same document as your pre-listing data pack, which assembles the records and numbers that prove what the business did. It is not the asset inventory either, which lists what you own and hand across. Those two describe the business at rest. The handover manual describes the business in motion. It is the operating layer, the how-it-runs, and it is the layer buyers find hardest to verify and therefore fear most.

There is external support for treating this seriously. In lower-middle-market M&A it is commonly cited that documented standard operating procedures lift a sale price by roughly 20 to 40 per cent and cut the handover a buyer demands from something like twelve months down to around three. Treat those as general industry guidance rather than gospel, and certainly not as an Indiemaker figure. But the direction is reportedly consistent, and it matches what you would expect. Less dependence on the founder, less risk, a shorter tail of your time, a better number.

The four procedures that actually move the needle

You do not need a fifty-page binder. Most of what founders want to document is decoration. Four procedures carry almost all of the weight, because they map to the four ways a business can quietly stop working after you leave.

One, how customers come in and get onboarded. The full path from a stranger arriving to a paying, activated user. Where they land, what they sign up through, what happens automatically, and what you currently do by hand.

Two, how money gets collected, reconciled and reported. Which processor charges the card, what happens when a payment fails, how you know monthly revenue is real, and where the numbers live. A buyer who cannot see how money moves cannot trust the revenue.

Three, how support gets handled. Where tickets arrive, the three or four issues that make up most of the volume, and the fix for each. This is the task that eats a new owner alive if it is undocumented.

Four, how it gets deployed and maintained. How a change reaches production, what the recurring maintenance jobs are, and what breaks if they are skipped. This is where founder-in-the-head knowledge is most dangerous.

Write these four well and you have covered the operating spine. Everything else can be a footnote. If you want the wider case for why this documentation is what separates a sellable project from an unsellable one, what makes a digital project transferable makes it in full.

How to write a procedure a stranger can follow

Here is the test that separates a real procedure from a note to yourself. Call it the cold-start test. Could someone who has never seen the business, and has no access to you, follow this and get the right result? If the answer is no, you have written a note, not a procedure.

Notes assume context. Procedures supply it. A note says "send the welcome email". A procedure says which trigger fires it, where the template lives, what it should contain, and what happens next if the user does nothing. The gap between those two is exactly the gap a buyer has to cross alone at 2am in month one.

Take one line most founders would write as "new user signs up" and run it through the test. Expanded into something followable, it looks like this.

Procedure: new user onboarding

1. Trigger. A user completes signup. The user.created event fires in [your auth provider] and writes a row to the users table.
2. Welcome email. Within five minutes the automation in [your email tool] sends the "Welcome" template. Template lives in [folder or link]. If it has not sent, check the automation is switched on.
3. Activation check. A user is "activated" when they have completed [the one core action, named exactly]. This is tracked in [your analytics tool] under [event name].
4. Follow-up. If the user has not activated within 48 hours, the "Getting started" template sends automatically. If that automation is off, this is the first thing to switch back on, because inactive signups churn fastest here.

Notice what that version supplies that the note did not. The exact trigger. The named tool. The location of the template. A definition of "activated" a stranger could not have guessed. And a rule for the failure case, which is where new owners lose users. That is the standard. If a step assumes something only you know, name the thing or link it.

Where the manual lives, and how you hand it over cleanly

Keep the whole manual in one place, in plain text or a shared document, not scattered across your own head, a Notion page and three pinned Slack messages. One document, four procedures, links out to the tools and templates each one references.

At handover, you do not just email the file. You walk the buyer through each procedure once, live, and then let them run it while you watch. Reading a procedure proves it exists. Executing it proves it works, and it surfaces the one assumption you did not realise you had baked in. That live run is worth more than any amount of documentation the buyer reads alone, and it is what turns their first thirty days from guesswork into a checklist. The buyer's own version of this, from the other side, is laid out in the first 30 days after you've bought it.

On settlement itself, keep it clean and keep it simple. Indiemaker is cash and wire only. You hand over the manual and the access, the funds settle by wire, and the deal is done in full at close. No earn-outs, no deferred slices, no seller financing tied to how well the buyer follows your procedures. A clean handover deserves a clean settlement, and both sides sleep better for it.

Build it before you list, not after you accept an offer

The timing is the whole argument. A handover manual written under deadline, after an offer is on the table and diligence is breathing down your neck, comes out thin and defensive. You write the minimum, you write it fast, and it reads exactly like something produced to satisfy a buyer rather than to run a business.

A manual written early is a different object. You have time to test each procedure against the cold-start test, catch the steps that only work because you were there, and fix them while it costs nothing. That version does not just survive diligence. It shapes the offer, because the buyer meets a business that visibly runs without you before they have even made a bid.

Most projects that get listed are not actually sellable, and undocumented operations is the most common reason why, as why most digital projects are listed, not sellable sets out. The fix is unglamorous and entirely in your control. Write the four procedures. Test them cold. Build the business to be handed over from the start, and the manual is already written long before you ever need it.

You are not documenting the business to sell it. You are documenting it so the buyer can see it will keep running once you are gone. Do that early, and the better offer tends to follow.