The 5 software questions you need answered first
By Steele Consulting
Most acquisitions that fail don’t fail on the math. They fail on integration. And the single most common integration failure — the one that has quietly cratered more rollups and strategic acquisitions than every regulatory issue combined — is software.
You buy the company. You inherit the codebase. You inherit the vendor contracts. You inherit the technical team, or at least the part of it that stays. You inherit the customers who are running on that software. And within 90 days of close, you discover things about your new acquisition that nobody told you, because the seller didn’t know either.
In our 24 years at Steele Consulting building custom software — including work with clients on both sides of dozens of acquisitions — we’ve watched five specific software questions surface as the difference between acquisitions that integrated cleanly and acquisitions that consumed the following year of the buyer’s attention. Getting honest answers to these five before you sign is how you avoid buying somebody else’s technical debt at your own multiple.
We wrote about the seller side of this in Tech Due Diligence: What Buyers Actually Look At When They Look at Your Software. This post is the buyer’s-side companion — the five questions your team should be asking during DD, and what the answers actually mean.
Why software is the hidden integration risk
Financial due diligence tells you what you’re paying. Legal due diligence tells you what you’re signing. Neither tells you what happens on day 91, when the seller’s CTO leaves for a competitor, or day 45, when a key vendor terminates their contract because of the change-of-control clause you didn’t renegotiate.
Software is where the “hidden liabilities” of an acquisition actually live. And unlike financial or legal issues, software integration problems get worse over time rather than better.
A vendor contract that terminates on close is a one-day problem. An acquired codebase that only one person understands becomes a bigger problem every month.
Question 1: Whose software is this really?
The ownership question. If the target company doesn’t cleanly own the software you’re buying, you don’t cleanly own it after close either.
Ask specifically:
- Does the target have signed IP assignments from every developer, contractor, offshore vendor, and third-party firm that has ever contributed to the codebase? “Every” is not a rhetorical word. One missing assignment from four years ago can invalidate the ownership of substantial parts of the system.
- Are any parts of the codebase covered by open-source licenses that require you to open-source your own downstream work? Some open-source licenses (GPL, AGPL) can force you to release code you consider proprietary. Buyers frequently discover this in post-close.
- Was any of the software developed under a contract with a specific customer? Some client contracts contain “work for hire” provisions that mean the client — not the target — owns the resulting code. You may be buying rights to software the target’s biggest customer legally controls.
Red flag: the target can’t produce a documented IP chain-of-title for the codebase on request. That absence is itself the answer.
Question 2: What breaks the day after close?
The change-of-control question. Every vendor contract, license, and integration in the target’s stack has one of three behaviors when the company is sold: transfers cleanly, requires renegotiation, or terminates automatically.
You need to know which is which, and for which systems, before you sign. Specifically:
- Pull every vendor contract the target has. Read the change-of-control clauses. Flag any that trigger termination or renegotiation on acquisition.
- Identify the systems the business genuinely can’t operate without — the CRM, the payment processor, the data warehouse, the email platform, the ERP. Confirm the treatment of each in the transaction.
- Ask about single-sign-on, API keys, and integration credentials tied to specific people. Some of the target’s critical integrations are running on personal Google accounts or an ex-employee’s authentication. You’ll find out on day 8 when access fails.
Red flag: the target hasn’t done this inventory themselves. If they can’t tell you which contracts terminate at close, they haven’t looked.
Question 3: How much of this system is in one person’s head?
The key-person question. Every technical team has a “the person who knows how X works” problem. In an acquisition, that person is a specific retention risk — because a payout on close often means they now have the financial freedom to leave.
We wrote about the general version of this in The Real Cost of an Underbuilt Tech Team. The M&A version is sharper: identify the specific individuals whose departure would slow or stop critical systems, and price them into the retention plan explicitly. Not implicitly. Specifically.
Ask the target:
- For each critical system, who is the primary owner? Who is the secondary owner? Is the secondary owner real, or nominal?
- What documentation exists for the systems these people own? Not “we have wikis” — actually look at them.
- What’s the retention plan for the engineers you’d need to keep? Not the sales retention plan — the engineering one.
Red flag: the target’s answer to “what happens if X leaves?” is either a shrug or an assertion that “we could hire around it.” Both mean the concentration risk is real and unpriced.
Question 4: What’s the actual cost of running this?
The infrastructure cost question. Software has an ongoing cost that’s larger than what’s in the target’s P&L, because SaaS sprawl, personal accounts, free-tier abuse, and shadow IT don’t get accounted cleanly. We wrote about this in Your Company Is Paying for 47 Software Tools — the industry average for a 100-person company is closer to 130.
You will inherit all of that. Which means you need to know:
- What’s the full list of tools the target actually pays for? Not the ones they told finance about — all of them. Corporate cards, personal reimbursements, free tiers with company data.
- What are the vendor renewal dates in the 12 months post-close? Auto-renewals on unnegotiated contracts are inheritable liabilities.
- What’s the true cloud and hosting cost, and is it optimized or bloated? Buyers regularly discover that acquired companies were paying 40% more than necessary for their infrastructure because nobody had optimized it in three years.
Red flag: the target’s answer to “what’s your true software cost?” is a P&L line. That’s the accounting number. It’s usually 15–30% lower than the actual number.
Question 5: How does this stack fit with ours?
The integration question. This is the one buyers most consistently underestimate. You aren’t just buying the target’s software — you’re committing to running it alongside yours until you either integrate it or shut it down. Both options are expensive.
Ask:
- What are the target’s core systems built on? Are they compatible with your existing stack, or are they a parallel universe you’ll be operating separately?
- How much of the target’s technical value would survive a migration to your stack, and how much would need to be rebuilt?
- If you integrate the two customer bases, how do their two versions of “a customer record” reconcile? The reconciliation work we covered in What to Do When Two Reports Say Different Things happens at 100x the scale in an acquisition context.
Red flag: your integration team hasn’t looked at the target’s stack in enough detail to answer these questions before close. You’re inheriting whatever they missed.
When to ask each question
Not all five questions have the same timing.
- During confidential DD (post-LOI): ask questions 1 (Ownership) and 2 (Change-of-control). These are hard failures if wrong, and you want to know before you’re deep into commit.
- In the working sessions leading to close: ask question 3 (Key-person) and 4 (True cost). Both require access to the target’s team and financials that don’t typically open until later in the process.
- In parallel with legal close: ask question 5 (Integration fit). Your integration planning should start before day one. If it starts after, you’re already behind.
How we approach this at Steele Consulting
We do buyer-side tech due diligence for clients in growth-through-acquisition mode — running exactly this five-question audit on the target’s software before the deal closes. The output is a report the acquirer’s team can use in negotiations, along with an integration plan that starts before day one instead of after.
Our value is that we’ve been on the target side too. We’ve built the systems that eventually got acquired, and we know what a well-run team’s answers to these five questions look like — and what the answers of a team that’s been coasting look like. The gap between the two is where the price adjustments live.
If you’re evaluating an acquisition — or planning to become an active acquirer — reach out. We’ll walk through the five questions with your specific target.
Book a call
Twenty-four years of building custom software. Both sides of the table on more decisions than we can count. And a track record of telling clients honestly when the answer is us and when it isn’t.
If you’re sitting in the middle of this decision right now, that’s the conversation we’re built for. Book a 30-minute call and we’ll walk through it with your specific situation. No pitch. No pressure. You’ll leave with a clearer picture of what to do — whether you work with us or not.