Case Study Tech audit

Technical Due Diligence for a Three-Party Software Acquisition

Mad Devs conducted an independent, month-long technical assessment of a production B2B SaaS platform with AI components before an acquisition. The review gave the buyer a verified view of the product’s technical condition, deal-related risks, and the work required to take the system under its own technical control.

Overview

A Western European company was preparing to acquire the rights to a B2B SaaS product developed by another company. The buyer planned to bring the product under its technical control and introduce it to a new market. The vendor that had built the platform was expected to remain involved as a development partner after the transaction.

That arrangement made the assessment different from a conventional buyer-led review. The vendor was both the subject of the due diligence and a future partner in the product’s development. The buyer needed an independent technical assessment for its decision and negotiations. The vendor needed a clear, evidence-based report that could also guide work after the transaction.

Mad Devs reviewed the product’s architecture, code, dependencies, documentation, security posture, delivery practices, mobile application, and readiness for enterprise and on-premises deployment. The work covered more than a dozen repositories containing server-side services, web clients, a cross-platform mobile app, and documentation, as well as a public API and external AI and infrastructure services.

The assessment took about one month. It produced a risk-ranked findings report, a set of verifiable conditions for the transaction, and a sequence of recommendations for both parties.

Project at a glance

About 1 month

from repository access to the final report

9 areas

reviewed across architecture, security, delivery, mobile, and operational readiness

10+ repositories

overing the product’s server, web, mobile, and documentation components

About 120 findings

grouped by severity, with around 30 positive observations documented separately

15 conditions

defined so transaction-related assumptions could be checked

7 cross-cutting themes

used to connect related findings and focus follow-up work

The business challenge

The vendor had a dual role. The buyer commissioned Mad Devs to assess the product independently. The vendor was the subject of the review and was expected to continue developing the product after the transaction. The report had to give the buyer reliable evidence for its decision and provide both parties with recommendations they could use during the transaction and handover. The vendor answered questions, joined technical sessions, and reviewed the draft report, so its involvement extended beyond providing access.

Questions the buyer needed answered. The buyer needed external technical expertise to determine:

Whether the product was technically workable and what risks could affect it after the acquisition.
Whether its architecture could support enterprise customers in the target market.
Whether a new team could take over code maintenance and documentation.
What an on-premises deployment would require and how involved that work could be.
How much the product depended on external AI and cloud services, and what might happen if those services became unavailable.
How mature the DevOps and CI/CD practices were, and whether software licenses and code rights were clear.
Whether the buyer could release application updates independently.

The report was prepared for the buyer’s decision-makers, legal advisors preparing the agreement, and the technical team expected to take over the product. It needed to distinguish verified evidence from vendor statements and areas that remained unverified.

How Mad Devs conducted the assessment

We used AI tools and open-source scanners to widen coverage across all nine review areas, while senior engineers remained responsible for the analysis and conclusions. They reviewed the code, investigated tool signals, and verified material findings against source code, configuration, and repository history. Tool output alone did not count as a finding; the auditors made and documented the final assessment.

1. Defined the questions and review scope

Mad Devs mapped the buyer’s transaction questions to nine technical review areas: architecture, scalability, on-premises readiness, code quality, documentation, dependencies and licensing, security, CI/CD, and mobile applications. This kept the review tied to the decisions the buyer needed to make while allowing the team to investigate further where evidence raised concerns.

2. Examined the repositories and technical evidence

The team reviewed more than a dozen repositories, their commit histories, tracked files, dependencies, and available documentation. A live technical session with the vendor provided additional evidence about the working system, including monitoring, alerting, and administrative interfaces.

The review ran in an isolated environment without network or production access. Source code was not taken out of that environment, and sensitive details were masked in the report.

3. Used tools to widen coverage

An AI coding assistant supported systematic searches across repositories, comparisons between documentation and implementation, and component and dependency inventories. Open-source scanners supported secret detection, dependency vulnerability checks, static analysis, and software bill of materials (SBOM) generation. Git history and standard utilities helped the auditors examine repository activity and tracked content.

These tools helped the team cover a large codebase in a limited timeframe. Their output was treated as a lead for review, not as a conclusion.

4. Verified material findings with senior engineers

Mad Devs’ CTO and CIO reviewed the code and investigated material signals against the source, configuration, and repository history. A senior mobile developer assessed the iOS and Android client. The delivery manager coordinated the sessions, consolidated evidence, and prepared the report.

The team separated verified observations from statements made in vendor documentation or interviews. Each review area recorded its confidence level and what remained unverified. The assessment did not provide a cost or engineering-hours estimate, which was outside the scope of this express due diligence.

5. Cross-checked the report with both parties

The vendor received a consolidated question list in advance and took part in technical sessions with live demonstrations. Both sides provided feedback on the draft report. The feedback clarified wording and context without changing the findings.

What the audit found

The assessment identified technical risks and strengths across the product. Mad Devs reviewed findings in context, grouped related issues into cross-cutting themes, and connected the results to transaction conditions and handover priorities.

Area	Findings
Severity	The review documented about 120 findings: 3 critical, around 30 high, 70 medium, and 20 low-severity items. The report ranked them so the parties could distinguish urgent risks from issues for later improvement.
Third-party dependencies	More than 100 known vulnerabilities were identified in server-side dependencies. Mad Devs checked scanner results in context and documented their limitations; a vulnerability alert alone was not treated as proof that the product could be exploited.
Product strengths	Around 30 positive observations highlighted product capabilities and engineering practices worth preserving during maintenance, refactoring, and the transition to a new technical team.
Cross-cutting themes	Seven themes brought related observations together, helping the parties see where findings were connected and focus follow-up work.
Transaction and handover	The report translated technical findings into 15 conditions that could be verified as part of the transaction. It also identified five areas where knowledge transfer would help the buyer take technical control of the product.

Recommendations for the transaction and handover

The final report gave the buyer and vendor a phased basis for action:

Before the transaction: verify defined conditions before proceeding.
During the transaction: clarify responsibilities and commitments between the buyer and vendor.
After the transaction: follow an ordered work plan, including knowledge transfer and technical improvements.

The recommendations also identified product strengths to retain during future maintenance and refactoring. This helped the buyer distinguish risks that needed attention from functioning parts of the system that should not be disrupted without cause.

The audit concluded that the transaction was technically defensible and that the buyer would be acquiring a working system. The buyer received an evidence-based view of the product, a list of conditions that could be verified, and a post-transaction plan. The vendor received recommendations that could support its continued role in product development.

The buyer responded positively to the report. Based on the information available to Mad Devs, the recommendations were accepted for follow-up. The case does not disclose the parties’ identities.

A technical assessment built for a complex transaction

When a software acquisition involves a future development partnership, technical due diligence has to give the buyer an independent basis for decisions and produce findings the vendor can use. Mad Devs combined repository-wide tool-assisted analysis with manual review by senior technical leaders, then connected the evidence to transaction conditions, knowledge transfer, and post-deal priorities.