Exit Command

A worked illustration, not a client result

Read this as a description of a product and how it behaves. No transaction has closed through Exit Command, and nothing here reports a client outcome. Every figure in the interface and in the proof module above is invented illustration of mechanics. The product itself offers no opinion of value, and no real acquirer is named anywhere in it.

That framing is not legal throat-clearing. It is the same discipline the product enforces internally, applied to how the product is described.

Executive summary

Exit Command is a transaction operating system for founders selling a company. It is not a CRM and it is not a data room, though it contains work that both would recognise.

The premise is narrow: what raises a sale price is evidence the company got measurably better while buyers were watching. That makes buyer intelligence and internal roadmap one system rather than two, and it is why every module belongs to a link in a single chain — buyer signal, strategic requirement, internal development, measurable improvement, acquisition proof, buyer engagement, competitive tension, price.

The challenge

A founder running a sale process is doing two jobs that are usually served by unconnected software. One is relationship work: which buyers exist, who has engaged, what they asked for, what stage each conversation is at. The other is operating work: what has to improve in the business, by when, and who owns it.

Kept apart, both degrade. The roadmap fills with initiatives that are defensible internally but answer no buyer's stated concern. The buyer pipeline accumulates notes about what acquirers care about that never reach the people who could act on them. The company improves, or does not, on a schedule unrelated to the process meant to be pricing it.

There is a second and less obvious problem. A transaction is an environment where being confidently wrong is expensive, and where most software is built to look confident. Filling an unknown financial with a plausible estimate, letting a repeated rumour harden into a fact, or presenting a modelled figure with the same authority as an audited one are all ordinary product behaviours — and each one produces a number a founder might negotiate against.

Approach

The loop came first, and it constrains what may enter the system. An initiative that cannot name the link it serves and the buyers it answers does not go on the roadmap. That single rule is what keeps the operating work tied to the process rather than running beside it.

The rest of the design is mostly a list of refusals, and they are the point rather than the fine print.

A figure with no source renders as an em dash — never a zero, never an estimate. Anything modelled carries a badge everywhere it appears, so a projection can never be mistaken for a measurement.

Confidence only ever falls. An inference does not become a fact by surviving three research runs; repetition is not evidence. Only verification against a primary source restores standing, and sources are graded rather than counted.

Research proposes and approvals write. Every consequential field — tier, score, probability, decision authority, priority — has exactly one writer, and it is a human. The research pipeline is delta-first and raises proposals; it cannot write to the record it is researching.

Offer comparison holds no house view of an earnout, applying only the discounts a human supplied, so a large contingent headline never automatically outranks smaller certain cash.

Outreach records but does not transmit. Nothing leaves the system, and the sent timestamp has one writer.

Authorisation is decided server-side against live database roles on every request rather than trusted from a session token, across ten roles, deny-by-default — a resource absent from a role's grants is denied rather than permitted by omission.

And a research run that finds nothing is treated as a success, with a test asserting it. A pipeline rewarded for producing findings will produce findings.