Buying or investing in a software company without looking under the hood is an expensive gamble. The product demo looks clean, the revenue chart trends the right way, and the founders sound confident. Then, a few months after close, you discover that three people hold all the real knowledge, the test suite is theater, and a critical dependency has been unmaintained for years.
I have sat on both sides of this. As a partner, I helped grow a software consulting company from about $6M to $60M in under three years, and later I founded a fully remote consultancy. Along the way I have reviewed codebases for buyers, sellers and investors who needed a clear picture in a few days, not a multi-month audit. A good technical due diligence checklist does not try to prove the software is perfect. It tries to surface the risks that change the price, the timeline or the decision itself.
What You Are Trying to Learn in a Few Days
You will not rewrite the product or interview every engineer. You are answering a short list of questions that matter to the deal.
Is the product buildable and shippable by a competent team that is not the current one? How much of the roadmap is blocked by hidden debt? Are there security or compliance landmines that turn into immediate spend after close? Does the engineering organization have depth, or does everything rest on one or two people?
If you can answer those with evidence, you have done enough for most acquisitions and investment rounds at this stage.
A Practical Technical Due Diligence Checklist
Code quality you can see, not hear about. Ask for read access to the main repositories and look at recent pull requests, not a prepared tour. Are reviews real, or rubber stamps? Is the style consistent, or does every file feel like a different author? Spot check error handling, logging and edge cases. A polished architecture slide means little if the last twenty commits are chaotic.
Architecture and change cost. Sketch how requests move through the system: clients, APIs, data stores, queues, third party services. Ask what would break if traffic doubled or a key vendor disappeared. Monoliths are fine. Tangled ones that nobody can safely change are not.
Tests, releases and observability. Ask to see continuous integration run on a real branch. Care less about coverage theater and more about whether tests catch regressions people fear. How often does production get a release? How do they know something is wrong before customers call?
Security and data handling. You do not need a full penetration test in every deal, but you do need basics. How are secrets stored? Who can reach production? What personal or payment data lives where, and is access logged? Ask about the last incident, even a small one. Teams that cannot describe one either have not been watching or are not being honest.
Hidden tech debt and third party risk. List the libraries, cloud services and contractors the product depends on. Flag anything abandoned, personally licensed, or known only to one engineer. Ask what they would rewrite first if they had a free quarter. The answer is often the real debt map.
Team depth and bus factor. Sit with the tech lead and two or three individual contributors separately. Ask who can deploy, who understands billing, who owns the data model. If the same name appears every time, that concentration is part of the valuation. Also check open roles and how long they take to fill.
Process that survives the founders. Look at how work is planned, how incidents are written up, and how knowledge is shared. A company that runs on Slack lore and one person's memory is harder to scale after an ownership change, even when the code is decent.
How to Run It Without Getting Lost
Timebox the work. For many mid-market software deals, three to five focused days with a small review team is enough. Longer reviews find more detail, but diminishing returns arrive fast if the first pass already shows clear patterns.
Start with access and a written request list. Repositories, CI, diagrams, incident history, org chart and a staging environment. Send the list before kickoff so day one is not burned on accounts.
Sample, do not boil the ocean. Pick the revenue-critical paths and the modules the sellers say are strongest. If the "best" code is rough, assume the rest is rougher.
Talk to people after you have looked at artifacts. Interviews are sharper when you can ask about a specific pull request, a flaky job or a scary dependency you already found.
Write risks as decisions, not vibes. For each finding, note the evidence, the likely cost or delay after close, and whether it is a price adjustment, a close condition or a plan-to-fix item.
What Good Looks Like
A healthy target is not debt-free. It is honest. The team can explain tradeoffs, show you where the sharp edges are, and demonstrate that they ship and learn in a repeatable way. Red flags cluster: 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 scoped.
Technical due diligence will not replace financial, legal or commercial work. It will keep you from discovering, after the wire hits, that you bought a demo wrapped around a fragile system. Use a clear checklist, move fast, sample the places that matter, and turn findings into decisions the deal team can act on.
I took a firm from $6M to $60M in under three years.
If you are evaluating a software company and want an honest view on running technical due diligence before you buy or invest, visit https://tdzpro.com.
Ashkan Rajaee is the founder of TDZ Pro. As a partner, he helped grow a software consulting company from about $6M to $60M in under three years, and he founded and scaled a fully remote software consultancy.
Top comments (0)