Technology due diligence of a software development company

About the transaction

Starting point

A strategic investor had recently acquired a stake in an IT development company with a proprietary software product. Standard financial and legal due diligence had taken place during the transaction. Technology DD, however, had been deferred for timing or organisational reasons — one of those things that often gets “left for later.”

After the transaction closed, the investor recognised the need for an independent assessment of the real technology state — not to unwind the deal, but to understand what they were actually working with. Was the product as technically sound as it appeared in commercial meetings? Where were the hidden costs that would show up in the next 12–24 months? What was the realistic capacity to scale the product, add features, and bring in new customers?

The target company’s management cooperated openly with the DD — which is not a given for this type of post-transaction analysis. It turned out that management itself suspected some areas were not in ideal shape and needed them “officially” named so they could act on them.

What was in scope

• Product architecture — state of the codebase, technologies used, solution maturity
• Infrastructure and operations — hosting environment, deployment, monitoring, disaster recovery
• Development processes — CI/CD, code review, release management
• QA and testing — test coverage, quality processes, defect management
• People and organisation — key roles, single-person dependencies (bus factor), team structure
• Vendors and dependencies — external partners, open-source components, vendor lock-in
• Security and compliance — strategic level, not a technical pentest
• IP and licensing — who owns the code, licence situation of components
• Product roadmap and technical debt — what’s in the backlog and what’s hiding in it

How the DD ran

The DD took 5 weeks including all outputs and presentations. Because it was a post-investment analysis, it was less time-pressured than a typical pre-transaction DD.

Phase 1 — Access and materials (week 1)

Kickoff with the target company’s management, CTO, and key developers. Access to documentation, the codebase, monitoring tools, and reporting systems. Designing the interview and observation structure.

Phase 2 — Study and analysis (weeks 2–3)

I worked through the codebase and product architecture, the development processes (the real CI/CD pipeline, not just the one “on paper”), operational data (incidents, availability, performance, hosting cost structure), and conducted interviews with key developers and QA about where technical debt accumulates and where they are most worried.

Phase 3 — Consolidating findings (week 4)

I structured findings into three categories by urgency and impact:

• Red flags — high-impact findings that need to be addressed within months
• Yellow flags — risks that don’t hurt yet, but will show up within 12–24 months if not addressed
• Positive findings — areas where the solution was in good shape

Phase 4 — Draft, discussion, finalisation (week 5)

I shared the draft first with the target company’s management — giving them the opportunity to respond, add context, or challenge the interpretation. After this I presented the findings to the investor with the final report and recommendations.

Key findings

Architecture and technology stack

Key parts of the product were running on an older technology stack with limited long-term sustainability. Modernising certain components was needed within 12–24 months — otherwise difficulties recruiting developers and accessing up-to-date libraries would grow. The overall architecture was logical and understandable, but some modules carried significant technical debt.

Dependencies and vendor lock-in

There was significant reliance on specific open-source components where community development had slowed. For some specialised functions, the company used vendors without a worked-out exit plan — a vendor failure would lead to several months of reconstruction. Bus factor in several critical parts of the product — specific knowledge was held by 1–2 individuals with insufficient documentation.

Operations

Disaster recovery procedures were documented but had not been tested in the past 18 months. Observability (monitoring, tracing, logging) was inconsistent — good for some parts of the product, minimal for others. Incident response was functional but built on the heroism of specific individuals rather than on process.

Quality and testing

QA was significantly under-resourced relative to the size of the product and the release frequency. Test coverage was low and uneven. Regression tests were predominantly manual, which slowed the release cadence. Defects reaching customers were frequently linked to insufficient automated testing.

Positive findings

Overall domain know-how was strong — the team understood the problem their product solves. IP and licence situation was clean — the company tracked code ownership, open-source licences were compatible. Team culture was positive and motivated. Compliance was in order.

What the client (investor) received

• Executive summary for the investment committee — key findings and strategic recommendations in 2–3 pages
• Detailed report structured by area, with specific findings and their impacts
• Red-flag and yellow-flag register with prioritisation and recommended timeframes for addressing
• Estimate of required investments over 12–24 months — stack modernisation, QA strengthening, observability, vendor exit plans
• Proposal for organisational changes — particularly in QA and knowledge management
• Presentation for the investor’s leadership and the target company’s management

What the impact was

The DD output was used as strategic input for setting the direction of further development. It specifically led to:

• Revised roadmap — modernisation prioritised in parallel with new features
• Personnel changes — targeted team boost, especially in QA (capacity increase, introduction of automation)
• Operational stack modernisation — gradual migration of key components, rebuild of observability
• Unified monitoring standard — consistent monitoring, tracing, and logging introduced across the product

The investor gained a realistic picture of the product and organisation they were actually working with. Instead of a feeling of “we bought something with hidden problems,” they had a structured plan for what to do and in what order. The target company’s management received the mandate for internal changes they had long wanted to make but hadn’t had the “external pressure” to elevate to priority level.

Paradoxically, the post-transaction DD was even more valuable than a pre-transaction one would have been — the deal was already done, so the findings didn’t affect price but led directly to action and implementation. This was not a DD that gets filed away in a drawer. It was a DD that was systematically checked off item by item over the following 12 months.

A note from practice

This project confirmed that technology DD makes sense even after a transaction closes. In IT development companies with proprietary products, technology is the backbone of value — and during a transaction there is time pressure, so DD either gets shortened or deferred. An investor who later decides to independently assess what they are actually working with gains not just an overview but an action plan. The willingness of the target company’s management to cooperate openly was also important — post-transaction DD that management perceives as an audit “against them” is far harder than DD where management itself sees value in naming the real state of affairs.

Related service

Classic technology due diligence, carried out in a less typical post-transaction format. The service page sets out the scope and process for this type of engagement.