When you invest in or acquire a company that runs on software, you are buying that software whether you look at it or not, and it is either an asset that carries the business forward or a liability that will drain the returns you modelled. A real technical due diligence exists to tell you which one you are actually buying. The most important thing I can say up front is this: a working product tells you almost nothing about whether it is a good acquisition. Plenty of software works right up until the moment it becomes impossible to change, and by then you own it.
What a real technical due diligence actually examines
A superficial review looks at the product, confirms it runs, and reads the sales deck. A real one looks underneath at the things that determine what the software will cost you and enable for you over the years you will own it. There are a handful of areas that matter more than the rest.
Architecture and technical debt
The question is not whether the code is elegant. It is whether the system can absorb the growth and change the investment thesis depends on. If your plan requires doubling the customer base or entering a new market, can the architecture support that, or will it need a rebuild that nobody has priced into the deal. Technical debt is normal and every real system has it. What matters is whether it is understood and managed, or invisible and accumulating. A team that can tell you clearly where their debt is and why they accepted it is in a far healthier position than one that insists there is none.
Key-person risk
This is the single most underrated risk in a software acquisition. Often there is one engineer who holds the entire system in their head, the only person who understands why things are the way they are and the only one who can safely change the critical parts. If that person leaves after the deal, and acquisitions are very good at making people leave, you have bought a system nobody can maintain. I always want to know how many people genuinely understand each critical part of the system, and whether the knowledge lives in more than one head.
Security posture
Security is where hidden liabilities live, because the cost of getting it wrong lands after you own the business, not before. How is sensitive data handled and stored. How are secrets and credentials managed. When did anyone last look at this seriously. You are not looking for perfection. You are looking for whether security is something the team thinks about deliberately or something that has simply never blown up yet. Those two states look identical from the outside and could not be more different once you own the risk.
How the team actually ships
This tells you more about the future than the code itself. How does a change get from an idea to production. Is there automated testing, or does every release rely on someone manually clicking through and hoping. How often do they deploy, and what happens when a deployment goes wrong. A team that ships small changes frequently and safely has a healthy system. A team that deploys rarely, nervously, and with a lot of manual checking is telling you the software is fragile, whatever they claim about it. The way a team ships is the most honest signal of engineering health you will get.
Red flags that should slow you down
Some findings are not automatically fatal, but every one of them should change your valuation, your integration plan, or both:
- No tests, or tests nobody runs. It means every change is a gamble and the true cost of future work is far higher than it looks.
- Nobody can explain a critical part of the system. Knowledge has already walked out, or lives in one head.
- Deployments are rare and frightening. A reliable sign the software is brittle underneath.
- No environments to test in safely. Changes are validated in production on live customers.
- The team cannot describe their own technical debt. Either it is invisible to them, which is worse, or they are not being straight with you.
- Everything depends on one person. You are buying a dependency, not a system.
None of these are automatically deal-breakers. But every one of them changes what the company is worth and what it will cost you to own, and each should be priced into the deal rather than discovered after it.
Why working is not the same as maintainable
This is the distinction the whole exercise turns on. Working software does what it does today. Maintainable software can keep doing that, and change safely, at reasonable cost, with the team you will actually have after the deal closes. The gap between the two is where acquisitions go quietly wrong.
A system can work perfectly and still be a liability: written in a way only its original author understands, impossible to change without breaking something elsewhere, dependent on ageing technology no one wants to touch. It runs fine in the demo. Then you need to add a feature, or fix a security issue, or scale it, and you discover that every change is slow, risky, and expensive because the software was never built to be changed. It works. It is also a trap, and the demo cannot tell the two apart.
That is precisely why a real technical due diligence is worth the cost. It is the difference between finding out a system is unmaintainable before you buy it, when the price is a negotiating point, and finding out afterwards, when it is your problem and the money is already spent. We approach this the same way we approach building software in our custom software and transformation work: judge the system by whether it can change safely, not by whether it happens to run today. If you are weighing an investment or acquisition and want a straight assessment of what you would actually be buying, that is a good conversation to have in a free consultation before you sign.