What a handover actually costs

I sold OrderBump in February and I'm still working on it. Not as a favor and not because anything went wrong — because moving a small software company from one owner to another is a real project and nobody budgets for it honestly.

I've now done this twice in eighteen months, once as the seller of a company I built over three years and once as the seller of an asset I'd owned for four months. The second one should have been trivial. It wasn't, and that's the interesting part.

What you're actually transferring#

The code transfers instantly. It's in a repository and it moves in an afternoon. Everyone treats this as the transaction.

Here's what doesn't move in an afternoon:

Why anything is the way it is. Every non-obvious decision in a product is a compressed argument, and the compression is lossy. The new owner sees a weird special case and their instinct is to clean it up, and the special case exists because a specific merchant configuration breaks without it. Nobody wrote that down. Nobody ever writes that down.

Which customers are actually different. In any merchant product there's a small set of accounts that are unusual — high volume, strange setup, an arrangement made verbally. The support queue looks uniform until you know which names to be careful with.

The seasonal shape. What breaks in November. What support volume looks like the week after a Shopify release. Where the annual soft patch is. You know these things as instincts after a year and they read as anomalies to someone in their first quarter.

Relationships. With the platform, with partners, with the agencies who recommend you. These are attached to a person and they don't assign.

Why it's worse for small assets#

The intuition is that a small company is easier to hand over. It's the opposite, at least proportionally.

A larger company has forced its context into systems — documentation, process, more than one person who knows things. Redundancy is expensive and it's also what makes a company transferable.

A small app is maximally efficient, which means it's a pile of context living in one head with nothing written down, because writing it down would have been waste right up until the day it wasn't. The efficiency that made it a good business to own is exactly what makes it hard to sell cleanly.

What I'd tell a seller#

Budget the months and say so in the deal. Not a vague commitment to be available. An actual scope. Everyone is happier when it's explicit, including you, because an unbounded obligation to be helpful is worse than a defined one.

Start writing things down before you have a buyer. Not a full documentation project — a running file of "why is this like this" that you add to whenever you notice something only you know. If you'd started that a year before selling it would be the most valuable document in the transaction.

Understand that leaving early damages what you sold. If you take the money and disappear, the buyer receives something meaningfully worse than what existed. That matters ethically and it also matters practically, because this industry is small and how you handed over your last company is known.

What I'd tell a buyer#

Assume the seller's context is the majority of what you're buying, and structure for it. Get real access for real months. Ask the "why is this weird" questions early, while they still remember and still care.

And expect the first quarter to be about not breaking anything rather than about your plan. I wrote that to myself when I bought this thing in October, and it turned out to be the only part of my thesis I executed properly.