What buyers actually look at when they look at your software
By Steele Consulting
If you’re planning to sell your business in the next 12 to 24 months — or even just take on serious outside investment — there’s a conversation you’re going to have that most founders don’t see coming. It usually happens two to three weeks into the LOI period. The buyer’s technical advisor, or a specialist firm hired for the purpose, is going to spend three to five weeks looking at your software, your team, and your data. And they’re going to write a report.
The report is called tech due diligence. It’s rarely the deal-killer, but it’s very frequently the deal-repricer.
In our 24 years at Steele Consulting building custom software — including for clients who eventually sold, and for buyers who eventually acquired other businesses — we’ve watched the same story play out. A founder walks into a transaction expecting the tech side to be a formality. Three weeks later, they’re negotiating a $2M discount because the buyer’s advisor found something the founder didn’t know was there.
This post is about what those advisors actually look for, and what you can do about it before you’re in the room defending against their findings.
Why tech DD reprices deals more than any other DD
Financial due diligence is mostly a math problem. The numbers are the numbers, and buyer and seller usually agree on what they mean. Legal DD is a paperwork problem. Slow, tedious, but predictable.
Tech DD is different. It surfaces two categories of problem that neither the buyer nor the seller usually anticipated: hidden risk and hidden cost. Hidden risk is the security incident nobody wrote down, the key employee whose knowledge isn’t documented, the vendor contract that terminates on change of control. Hidden cost is the technical debt that’s been building silently for years, the modernization work the buyer will have to do post-close, the compliance gap that turns into a six-figure remediation project.
Neither shows up in the P&L. Both change the deal.
The tech DD firms know exactly where to look for these things, because they look for them dozens of times a year. The founder has usually never sat on the other side of a DD before. The information asymmetry is enormous, and it’s not in your favor.
The 5 Buckets of Tech DD
Every serious tech DD covers five things. Understanding what each one is looking for — and what “clean” looks like — is how you prepare.
Bucket 1: Ownership
The most important question and the one founders most often assume they’ve handled correctly. Do you actually own the software you’re selling?
Specifically:
- Every developer who has ever touched the codebase — full-time, part-time, contract, offshore — needs to have signed an IP assignment. Every one. If a single contractor from four years ago didn’t sign, you technically don’t own the code they wrote, and buyers will find this.
- Every open-source library in your codebase has a license. Some (MIT, Apache) are friendly. Others (GPL, AGPL) can require you to open-source your own code. Buyers will scan your dependency tree.
- Any code developed under a contract with a specific client may belong to that client, not to you. Buyers will read the contracts.
The clean version looks like a documented IP chain-of-title for every line of code in production, ready to hand over on request.
Bucket 2: Health
How good is the code, and how much technical debt is the buyer inheriting?
Advisors look at:
- Code quality metrics — test coverage, cyclomatic complexity, static analysis scores
- Security vulnerabilities — outdated dependencies, unpatched CVEs, exposed secrets in the codebase
- Deployment cadence — how often ships, how often rollbacks, how automated
- Documentation — architectural diagrams, runbooks, onboarding docs for new engineers
The DRIFT framework we wrote about in our tech debt post is essentially what tech DD is measuring — but the buyer is going to put a dollar figure on it, and that dollar figure comes out of your sale price. A codebase with 15% test coverage and eight unpatched critical vulnerabilities doesn’t lose you the deal. It loses you the multiple.
The clean version looks like a codebase that a senior engineer could pick up in two weeks, with automated tests that actually run and pass.
Bucket 3: Team
Can the team be transitioned to the buyer, and is the knowledge documented?
This is where the Key-Person Cost from our Underbuilt Tech Team post becomes an M&A problem. Buyers ask:
- Who understands the codebase? What happens if they leave post-close?
- Is knowledge documented, or is it in one person’s head?
- What are the retention risks in the engineering team? Who has one foot out the door?
- What’s the ramp time for a new engineer to become productive?
Tech DD advisors will interview your engineering leaders and often your senior individual contributors. They will ask pointed questions about who knows what. If two of those people can’t answer detailed questions about the same system, the buyer has just identified concentration risk.
The clean version looks like at least two people who can operate every critical system, with real documentation, and a retention plan for the people the buyer needs to keep.
Bucket 4: Risk
Security, compliance, and dependencies. What could blow up post-close?
Advisors examine:
- Security history — any breaches, incidents, close calls? How were they handled?
- Compliance posture — SOC 2, HIPAA, PCI, GDPR as applicable to your industry
- Third-party dependencies — which vendors are critical? Any single points of failure? Change-of-control clauses in the contracts?
- Data handling — where does customer data live, who has access, how is it protected?
- Disaster recovery — has it ever been tested?
Change-of-control clauses are the sneakiest of these. Some vendor contracts terminate automatically when your company is sold. If your CRM, your payment processor, or your data warehouse has one of these clauses, the buyer inherits a scramble on day one. They will notice. They will discount.
The clean version looks like a documented security program, current compliance where required, and vendor contracts with change-of-control terms that survive the transaction.
Bucket 5: Roadmap
Does the tech story match the business story?
The last bucket is the softest but often the most valuable. Advisors will read the tech roadmap and compare it to the business plan you gave the buyer. If the business plan assumes 3x revenue growth in two years but the tech roadmap doesn’t have the infrastructure work to support 3x load, that’s a red flag. If the roadmap has $2M of “modernization” and the CFO’s projections don’t have $2M of engineering spend, that’s another one.
Advisors are looking for coherence. They want to see a technical plan that could actually deliver the business plan the buyer is being sold.
The clean version looks like a tech roadmap a buyer’s advisor can read and say: “yes, this is what it would take to hit their numbers, and the cost matches the budget.”
What to do in the 12 months before you go to market
Nothing about the above list is hard to prepare for — if you have 12 months. Almost none of it can be fixed in the three weeks between LOI and closing.
Twelve months out, the highest-value moves are:
- Do a mock tech DD on yourself. Hire an outside firm (like us, or one of the specialist tech DD firms) to write the report a buyer’s advisor would write. Whatever they find is what the buyer will find. Fix it before the buyer sees it.
- Get your IP chain-of-title clean. Track down every contractor. Get every missing IP assignment signed. This alone can move eight figures on a nine-figure deal.
- Retire your worst technical debt. You don’t need a pristine codebase — buyers know they’re buying a real business. You do need to have addressed the specific issues a scanner will surface immediately.
- Document the systems that live in one person’s head. Every day of the sale process where knowledge is still concentrated is a day of leverage the buyer gets.
- Renegotiate change-of-control clauses. Anywhere you can. Now, while you have leverage and time.
Six months out, the moves get more tactical: security audit, dependency updates, roadmap alignment with the CFO’s projections. Three months out, you’re doing prep work, not fixing problems. And once the LOI is signed, you’re defending, not improving.
What to do if you’re already in DD and finding problems
If you’re reading this in the middle of an active DD and the advisor’s findings are worse than you expected — some things you can still do.
Get ahead of it. Don’t let the buyer’s advisor deliver the findings to the buyer without you having framed them first. Every problem has a remediation plan and a cost estimate. Present both alongside the finding.
Don’t argue with the finding. Argue with the implication. The advisor is right that your test coverage is 12%. They’re wrong that this justifies a $3M discount. Come with a specific remediation plan and a real cost — usually a small fraction of the proposed discount.
Bring in outside help. This is where a pre-DD engagement pays off even mid-DD — an outside firm can produce credible remediation estimates faster than your internal team, and buyers weight outside estimates more heavily than seller ones.
How we approach this at Steele Consulting
We do two flavors of tech DD work. The first is the pre-transaction audit — 12 months out, we go through all five buckets with you and produce the same report a buyer’s advisor would produce, so you can fix the problems on your own timeline instead of theirs. The second is transaction support — active engagement during a live DD, producing remediation plans, cost estimates, and credible technical responses to the buyer’s advisor findings.
Both are grounded in the same 24 years of building custom software and watching what happens on the other side of a sale. Every problem the DD will find is a problem we’ve seen fixed dozens of times. The question is only whether you fix it before the buyer sees it or after.
If you’re 12 to 24 months out from a transaction — or 12 to 24 days in — that’s the conversation we’re happy to have. Reach out and we’ll walk through the five buckets with your specific situation.