Most buyers of lower middle-market software businesses are not engineers, and most deals at this size do not budget for a full third-party technical review. The result is a predictable gap. Financial diligence gets weeks of attention, commercial diligence gets reference calls and market work, and the product itself, the thing customers are actually paying for, gets a demo and a few questions to the founder.

That gap matters because technical debt is a real liability. It does not sit on the balance sheet, but it shows up after closing as slower product development, higher support costs, security exposure, and in some cases a rewrite that nobody priced into the deal. You do not need to read code to size it. You need to ask the right questions and know which answers should worry you.

What technical debt actually costs a buyer

Technical debt is the accumulated cost of shortcuts: older frameworks that were never upgraded, features added without tests, infrastructure that only one person understands. Every software business has some. The question for a buyer is not whether it exists but whether it will consume capital or growth after close. That usually shows up in one of four ways: engineering capacity absorbed by maintenance instead of new features, rising support volume, security or compliance remediation, or a forced platform rebuild. Each one is a cost that belongs in the model.

Question 1: How old is the stack, and who can still work on it?

Ask for a plain-language list of the main languages, frameworks, databases, and hosting environment, with the version of each. You do not need to judge the choices. You need to check two things. First, whether any core component is out of vendor support, which creates security risk and will eventually force an upgrade. Second, whether the skills required are still easy to hire for. A product built on a technology with a shrinking talent pool will cost more to maintain every year, and that cost compounds.

Question 2: Where does engineering time actually go?

Ask the engineering lead to estimate how the team's time split over the last twelve months across new features, bug fixes, customer-specific customization, infrastructure, and support escalations. If most of the team's time goes to keeping the existing product running, the roadmap in the CIM is not funded by the current team, and hitting it will require either more hires or a slower plan than presented.

Customer-specific customization deserves particular attention in vertical software. Many founder-led businesses grew by building one-off features for large customers. Each of those becomes a separate thing to maintain, and a codebase with many customer-specific branches is expensive to upgrade and hard to migrate to the cloud.

Question 3: How are changes shipped?

Ask how often the product is released, how long a release takes, whether there is automated testing, and what happened the last time a release caused a problem for customers. Frequent, routine releases with automated testing generally indicate a healthy codebase. Infrequent, large, manually tested releases that the team dreads are a strong signal that the product is fragile, and fragile products slow down every plan a buyer might have for them.

Question 4: Who knows how it works?

In many founder-owned software businesses, one or two people understand the core of the system. Sometimes one of them is the founder. Ask who would be able to fix a critical production issue at two in the morning, and ask what documentation exists. Then ask how long a newly hired engineer takes to ship their first meaningful change. If the answer is many months, knowledge is concentrated and undocumented, and the retention of those individuals should be treated as a deal term rather than a hope.

Question 5: What does security and hosting look like?

Ask whether the company has had a penetration test, a security incident, or a customer security questionnaire it struggled to complete. Ask where customer data is hosted, who has administrative access, and whether backups have been tested by actually restoring them. In verticals that handle sensitive data, such as healthcare, education, or financial records, gaps here can become contractual or regulatory problems quickly, and larger customers increasingly require evidence of controls before renewing.

Question 6: Is the cloud version real?

If the CIM describes a cloud product or a modernization program, ask how many customers are live on it, what share of the codebase it replaces, and what the remaining plan and budget look like. A modernization effort that has been "about a year from complete" for several years is a common pattern, and it tends to consume far more capital than expected once a buyer takes ownership of it.

Turning answers into numbers

The point of these questions is not to produce a technical report. It is to produce adjustments to the model. A practical approach is to translate findings into three items:

  • One-time remediation cost: upgrades, security fixes, and documentation work needed in the first year, estimated in engineering months and converted to dollars.
  • Run-rate engineering adjustment: additional headcount needed to deliver the stated roadmap given the current maintenance burden.
  • Key-person protection: the cost of retention arrangements for the individuals the product depends on.

If the findings are serious, for example unsupported core infrastructure or a stalled rebuild, that is the point to bring in a specialist technical diligence provider for a targeted review. The questions above will tell you whether that spend is justified and what it should focus on, which keeps it focused and affordable.

Non-technical buyers do not need to become engineers to underwrite software businesses well. They need to treat the product with the same skepticism they bring to the financials, and to make sure what they learn ends up in the price.