Why most tech due diligence misses the point
I have reviewed dozens of technology due diligence reports commissioned by PE firms and VC investors. The majority follow the same pattern: a detailed inventory of the technology stack, a list of programming languages, a diagram of the infrastructure, and a section on cybersecurity posture. They read like a health check performed by someone who catalogued every organ but never asked whether the patient can run a marathon.
The fundamental question that technology due diligence should answer is simple: can this technology support the value creation plan over the hold period? Not “is the technology modern” or “does the team follow best practices.” Those are inputs. The output that matters is whether the technology is a constraint on the investment thesis or an enabler of it.
When a PE firm acquires a retailer planning to grow from $200M to $500M in revenue over five years, the technology assessment needs to evaluate whether the current platform, architecture, and team can support that growth. If the plan involves launching new channels, entering new markets, or consolidating multiple acquisitions onto a shared platform, the technology assessment must address those specific scenarios. A generic stack review does not get you there.
The five areas that actually matter
Architecture scalability
Architecture age is one of the least useful indicators I see in DD reports. I have assessed businesses running fifteen year old systems that were well architected, well integrated, and perfectly capable of supporting the growth plan. I have also seen businesses on shiny microservices architectures that were so poorly connected that every new feature took three times longer than it should.
What matters is flexibility: can the architecture accommodate the changes the value creation plan requires? Ask for load testing results. Review how the system handled peak trading periods like Black Friday or end of financial year. Look at the integration layer between systems, because that is where most scaling problems actually live. A monolithic commerce platform that handles current volumes comfortably is not a problem. A collection of loosely connected services with no clear data flow between them is.
Ask the team to walk you through what happens when order volume doubles. Not in theory. Have them trace it through the actual systems, from the storefront to the warehouse management system to the finance platform. Where the explanation gets vague is where the risk lives.
Team capability and key-person risk
This is where most value creation plans succeed or fail, and it is consistently the area that gets the least rigorous assessment. Investors spend weeks evaluating the technology stack and thirty minutes meeting the engineering team.
Key-person risk is not just about the CTO. Look at who actually built and maintains the critical systems. In mid-market retail businesses, it is common to find one or two senior developers who are the only people who understand how the integration layer works, or how the pricing engine calculates promotions, or why the inventory sync runs at 3am on a specific schedule. If those people leave, the business loses institutional knowledge that cannot be replaced quickly.
Ask for an organisational chart of the technology team. Map it against the critical systems. Identify where a single departure would create a meaningful operational risk. Then ask the current leadership what their plan is if that person leaves. The answer, or lack of one, tells you a great deal about how the technology function is managed.
Beyond key-person risk, assess whether the current team has the skills to execute the post-investment roadmap. If the value creation plan involves migrating to a new commerce platform, but the team has only ever maintained the current one, that is a capability gap you need to price into the deal.
Technical debt and its trajectory
Every business has technical debt. The question is not whether it exists but whether it is being managed, growing, or being actively reduced.
Ask for the backlog. Not the feature backlog, the technical debt backlog. If the team does not maintain one, that is a signal in itself. It means technical debt is either being ignored or is invisible to leadership. Neither is good.
Look at the trajectory. Has the team been allocating time to reduce debt, or has every sprint been consumed by feature work and firefighting? Review the incident log for the past twelve months. Frequent production incidents, particularly recurring ones, are a reliable indicator that technical debt is accumulating faster than it is being addressed.
The artifacts to review here are deployment frequency, mean time to recovery from incidents, and the ratio of planned work to unplanned work. A team spending more than 30% of its capacity on unplanned work is a team drowning in accumulated technical decisions.
Integration health
Retail businesses run on integrations. The commerce platform talks to the ERP, the ERP talks to the warehouse management system, the WMS talks to the shipping provider, the shipping provider sends data back to the customer-facing order tracking. Every one of those connections is a potential point of failure, and in my experience, integration failures are the single most common cause of operational incidents in retail technology.
Map every integration. For each one, ask: is it real-time or batch? What happens when it fails? Is there monitoring and alerting? When was the last time it broke, and how long did it take to fix? Is it built on a supported, documented API, or is it a custom script that someone wrote four years ago?
The businesses I worry about most are the ones where integrations are held together by scheduled file transfers, undocumented scripts, and manual reconciliation processes. These work until they do not, and when they fail at scale, the recovery is painful and expensive.
Total cost of ownership
Technology cost is not just the hosting bill. It includes licensing fees, vendor contracts, the fully loaded cost of the technology team, contractor spend, implementation partner fees, and the hidden cost of manual processes that should be automated.
Review every vendor contract. Look at renewal dates, auto-renewal clauses, price escalation terms, and termination penalties. I have seen acquisitions where a single unfavourable vendor contract represented a seven-figure cost that was not surfaced in the financial due diligence because it was buried in a multi-year commitment signed by a previous management team.
Calculate the total technology spend as a percentage of revenue. For mid-market retail, anything above 4% to 6% warrants investigation into where the money is going and whether the business is getting value from it. Compare that against what peers spend and, more importantly, against what the business will need to spend to execute the value creation plan.
Red flags versus acceptable risk
Not everything that looks concerning in a due diligence is actually a problem. Part of the value of a good technology assessment is helping investors distinguish between genuine risk and manageable imperfection.
Red flags that should make you pause: a single developer who is the only person who can deploy to production; no automated testing of any kind; a commerce platform running on an unsupported or end-of-life version with no upgrade plan; vendor contracts that auto-renew within 60 days of the expected close date; no disaster recovery plan or backup testing.
Acceptable risk that can be managed post-acquisition: an older technology stack that works reliably and can be modernised incrementally; moderate technical debt with a team that acknowledges it and has a plan; manual processes that are well documented and can be automated as part of the value creation plan; a small team that is competent but needs to scale.
The distinction is between things that create existential operational risk and things that represent optimisation opportunities. A business with no backups is a red flag. A business with manual reporting is an opportunity.
How to read a technology roadmap critically
Every target will present a technology roadmap. Most of them are aspirational wishlists rather than executable plans.
A credible technology roadmap has three characteristics. First, it is sequenced logically, with dependencies mapped. You cannot migrate to a new commerce platform while simultaneously rebuilding the integration layer and launching a new channel. Second, it is resourced. Every initiative on the roadmap should have an associated cost estimate and a team assigned to deliver it. If the roadmap contains ten initiatives but the team can only execute three in parallel, someone is not being honest about the timeline. Third, it aligns to the business plan. Technology initiatives that do not directly support revenue growth, cost reduction, or risk mitigation should be questioned.
Ask the CTO to rank the roadmap items by business impact. If they cannot do it without hesitation, the roadmap is a technology wishlist, not a business plan.
What a good DD report looks like
A bad due diligence report describes what exists. A good one tells you what it means for the investment.
The best technology DD reports I have seen, and written, follow a consistent structure: an executive summary that states the technology risk rating in plain language, a detailed assessment of each of the five areas described above, a specific list of findings mapped to the value creation plan, a prioritised set of recommendations with estimated cost and timeline, and a clear statement of what needs to happen in the first 100 days post-close.
The report should be written for the deal team and operating partners, not for engineers. If the reader needs a computer science degree to understand the findings, the report has failed.
Post-DD: translating findings into the value creation plan
The due diligence does not end when the report is delivered. The findings need to translate directly into the technology component of the value creation plan. Every risk identified should have a mitigation strategy. Every opportunity should have a business case.
The strongest outcomes I have seen are where the DD findings inform the first 100-day plan before the deal closes. The operating team walks in on day one with a clear understanding of what needs to happen: which vendor contracts to renegotiate, which team gaps to fill, which systems to stabilise, and which investments to make in what sequence.
Technology due diligence done well is not a compliance exercise. It is the foundation of a technology strategy that supports the entire investment thesis.
Next steps
If you are evaluating a retail or commerce acquisition and need technology due diligence that goes beyond stack inventory, get in touch. I work with PE firms and VC investors to assess technology risk, capability, and readiness against specific value creation plans. The goal is always the same: give you the information you need to make a confident investment decision and hit the ground running post-close.
What to read next
- Post-acquisition technology playbook: the first 100 days — What happens after close — the technology programme that due diligence should set up.
- What usually goes wrong in retail technology transformation — The failure patterns that technology programmes must actively avoid.