I have sat in on acquisition conversations where the financials were audited for weeks and the technology stack got a single afternoon walkthrough with a slide deck. Technology due diligence is treated as a formality, something the CTO signs off on quickly so the deal can close. Then six months later the buyer discovers nobody actually owns the source code, or the one engineer who understands the system just quit. By then it is not a due diligence finding, it is a lawsuit or a rebuild.
If you are acquiring a business, taking an equity stake, or entering a deep technical partnership, the software is often the actual asset, not a supporting function. Technology due diligence deserves the same rigor as the balance sheet, because a broken codebase or a missing license can erase the value you thought you were buying.
The most common finding: nobody owns the code
This sounds absurd until you have seen it three times. A founder hired a freelance developer or an outsourced agency years ago. The contract, if one exists, never assigned intellectual property rights explicitly. The code sits in a personal GitHub account, not a company one. The domain, the app store listing, or the production server credentials are registered under an individual's personal email, not the company's.
None of this shows up in a demo. It shows up when you try to transfer ownership after signing, and the person who built it either cannot be reached or asks for money to hand over access they were never supposed to keep in the first place.
Ten questions and what bad answers sound like
Ask these directly, in writing, before you sign anything binding:
Who legally owns the source code, and can you prove it with a contract or assignment clause? Bad answer: "We've always just had access to it."
Is the code in a company-owned repository, or a personal account? Bad answer: "It's in our developer's GitHub, but he's been with us for years."
Who has production server and domain access, and is it under a company account? Bad answer: "Our old agency manages the hosting, we just pay them monthly."
What happens if your lead or only engineer leaves tomorrow? Bad answer: "That would be a problem, honestly."
When was the last security audit or penetration test, and what did it find? Bad answer: "We've never had one, but nothing's happened so far."
What third-party licenses, APIs, or open-source dependencies does the system rely on, and are they compliant? Bad answer: "Not sure, our dev handles that."
Is there documentation beyond what's in someone's head? Bad answer: "It's pretty intuitive once you look at the code."
What is the actual state of technical debt, and has anyone quantified it? Bad answer: "It works fine for now."
Are there any outstanding disputes with former developers or agencies over IP or payment? Bad answer silence, followed by a change of subject.
Can the system handle two to three times current load without a rebuild? Bad answer: "We haven't really tested that."
Each bad answer above is not disqualifying by itself. But three or more of them together should change your valuation, your deal structure, or your walk-away price.
Key-person risk is a financial risk, not just a technical one
The single biggest red flag I look for is concentration. If one person holds all the deployment credentials, understands the only undocumented integration with a payment gateway, and has never taken more than three days off in two years without something breaking, you are not buying a stable asset. You are buying a dependency on a human who has not signed anything binding them to stay.
I have seen this exact pattern at a multifinance company evaluating a fintech partnership: the target's entire loan-scoring logic lived in one developer's local machine, undocumented, no version control discipline for the critical module. The partnership proceeded, but only after a clause requiring documented handover and a three-month transition period with the original developer retained as a paid consultant. That clause alone probably saved the deal from unraveling in year one.
Security posture and technical debt are financial line items
Security exposure and technical debt do not show up on a balance sheet, but they are real liabilities. An unpatched system with customer data is a lawsuit waiting for a trigger. A codebase held together by patches on patches, what we cover in more depth in Technical Debt Explained for Business Owners, means every future feature costs more than it should, silently taxing the return on your investment. Ask your target's numbers to reflect this, either as a lower valuation or a remediation fund built into the deal.
The same logic applies to legacy platforms you might be inheriting, which we cover from the buyer's operating side in The Hidden Cost of Legacy Systems in Your Business.
The takeaway
Technology due diligence is not a checkbox for the deal lawyers. It is where you find out whether the asset you are buying can survive contact with reality after the ink dries. Ask who owns the code, in writing. Ask what happens when the one person who understands the system leaves. Ask for a security audit, even a light one, before you close. If your own technical team is too close to the deal to ask these questions with a straight face, bring in someone independent, that is exactly the kind of engagement worth a conversation at /partner.