Skip to content
Log in
← Statistics glossary

due diligence

The detailed check a buyer runs before closing a deal to confirm that everything the seller claimed is true: finances, metrics, contracts, code, legal risks. Sellers should also check the buyer.

Due diligence is the detailed check a buyer (or investor) runs before closing a deal, to confirm that everything the seller has claimed is true. For a small software company it usually covers the financials and payment records, the metrics (MRR, churn, customer list), contracts with customers, staff and suppliers, ownership of the code and other intellectual property, personal data and how it is protected, and any legal or tax risks.

It usually starts after the letter of intent is signed and takes from a few weeks to a few months. Most deals that fall apart do so here, or get repriced: a problem the buyer finds becomes a reason to lower the price, add conditions or move money into an earn-out. The seller's best defense is to prepare in advance: clean books, a metrics history that matches the bank statements, signed contracts, and clear ownership of everything the business uses.

Due diligence runs both ways. A seller who will stay on after the deal, or who will receive part of the price later, should check the buyer too: their finances, their plans for the product and the customers, and how previous acquisitions went. A lawyer who does deals of this size is worth having from the letter of intent onwards.

Example

After the letter of intent, the buyer of GarageDesk spends six weeks checking the customer list against payment records, the contracts with shops and who owns the code, while the founders keep running the business, since a dip in MRR during the checks would cost them.

Two things need care. The buyer asks for the full list of car owners' phone numbers; those belong to the shops' customers, so the founders give counts and anonymized samples, read-only, and the full data moves only at closing under the contract. And their lawyer finds that the contract with Ethan, the part-time developer, doesn't say the code he writes belongs to GarageDesk; a signed assignment of rights fixes it the same week.

Common mistakes

  • Preparing only when the buyer asks. Clean books and signed contracts take months to fix under pressure.
  • Metrics that don't match the bank. Any gap between your dashboard and your statements costs trust and money.
  • Forgetting code ownership. Every contractor and employee who wrote code needs an IP assignment.
  • Not checking the buyer. If part of your payment comes later, their plans and finances are your risk too.