What I Look for Before Anyone Buys a Software Company

Note: This story was written with AI assistance and edited by me.

Note: An earlier version of this piece, "How to Run a Technical Due Diligence Before You Buy or Invest in a Software Company," was published on DEV.

I have watched deals close on the strength of a clean demo and a confident founder pitch, only for the buyer to learn later that three people held all the real knowledge, the tests were mostly for show, and a critical dependency had been quietly rotting. That is an expensive way to learn how a codebase actually works.

I have reviewed software companies for buyers, sellers and investors who needed clarity in days rather than months. Earlier in my career, as a partner, I helped grow a software consulting company from about $6M to $60M in under three years, and later I built a fully remote consultancy. The technical due diligence checklist below is the shortened version of what I actually use.

What a Short Review Is For

You are not trying to prove the product is perfect. You are trying to answer a few deal-changing questions. Could a competent team that is not the current one keep shipping it? How much of the roadmap is blocked by debt nobody put on a slide? Are there security or compliance problems that become immediate spend after close? Does the engineering organization have depth, or does everything hang on one or two names?

The Checklist

Look at real code, not a guided tour. Get repository access and read recent pull requests. Are reviews substantive? Is the style coherent? How are errors, logs and edge cases handled? Architecture decks mean little if the last twenty commits are messy.

Map how change moves through the system. Clients, APIs, data stores, queues, vendors. Ask what breaks if traffic doubles or a key service disappears. Coupling that nobody can safely unwind is a valuation issue.

Watch how they ship and how they see production. Ask for a real CI run. Ask how often production gets a release and how they learn something is wrong before customers do. Missing alerts often matter more than imperfect coverage.

Check the security basics. Where do secrets live? Who can reach production? What personal or payment data sits where, and is access logged? Ask about the last incident, even a small one.

Inventory debt and third parties. Abandoned libraries, personally owned accounts, contractors who own a core module. Ask what they would rewrite first with a free quarter. That answer is often the honest debt map.

Measure the bus factor. Talk separately with the tech lead and a few individual contributors. Ask who can deploy, who understands billing, who owns the data model. If one name keeps appearing, that concentration belongs in the deal math.

See whether process survives the founders. Planning, incident writeups and knowledge sharing tell you whether the company runs on systems or on Slack lore and one person's memory.

How to Stay Useful in a Few Days

Timebox the review. Three to five focused days is enough for many mid-market deals. Send an access list before kickoff. Sample the revenue-critical paths and the modules the sellers call their best work. Interview people after you have looked at artifacts. Write each risk as a decision: price, close condition or post-close plan, with evidence attached.

Honesty Beats Perfection

A healthy target is not free of debt. It is honest about tradeoffs, sharp edges and how the team ships. Red flags tend to travel together: no tests and no monitoring, one hero engineer, secrets in the repo, a core vendor with no contract, and a roadmap that assumes a rewrite nobody has sized.

Technical due diligence will not replace financial or legal work. It will keep you from discovering, after the wire hits, that you bought a polished demo wrapped around a fragile system.

I took a firm from $6M to $60M in under three years.