Technical Due Diligence Without Full Access
Mad Devs assessed a revenue-generating digital platform for a potential buyer without access to its source code or production systems. Through structured interviews, guided demonstrations, and AI-assisted analysis using our Enji Fleet and Enji Guard, we identified 7 critical-priority issues and found that some of the deal's most serious risks lay outside the codebase.
Overview
A potential buyer asked Mad Devs to assess a software platform before an acquisition. The platform had been in production for about three years, processed user payments through roughly 30 payment providers, and handled around 1.7 million API requests a day. A team of about 30 people supported it, including six core engineers and a 12-person support team working around the clock.
The main constraint was access. Until the deal closed, the buyer did not control the platform, and the company being acquired did not give external auditors access to its repositories or production environments. It did open its knowledge base, task tracker, and team chats for review, and its engineers agreed to walk us through code and infrastructure in live sessions.
The buyer approved 18 key questions across seven assessment areas.
In short, they asked:
- Is the code maintainable, and how much technical debt needs immediate investment?
- Is the architecture modular enough to grow, and which components fail first under 5–10x load?
- Are there critical security vulnerabilities, and how is sensitive data protected?
- Which external services and internal components are single points of failure?
- How dependent is the product on individual engineers, and how mature are the team’s processes?
- What would it cost to fix the platform, and what would it cost to rebuild it?
The platform had a solid engineering foundation. The most consequential finding was organizational: critical knowledge about the system lived with a few people, and the processes that would let a new owner keep it running were largely undocumented.
Project at a glance
Challenges and solutions
Two challenges shaped this audit: gathering reliable evidence without access to the code, and making the results useful for an acquisition decision.
Challenge 1: Auditing a platform without access to its code
A typical technical due diligence gives auditors read-only access to repositories, infrastructure configuration, monitoring, and development tools. Here, the target company kept its code and production environment closed to outsiders until the deal was signed. This is common in acquisitions, and organizations with strict security requirements often impose the same limits.
Without direct access, an audit risks describing how the team says the system works instead of how it actually works. We needed enough first-hand evidence to test engineering decisions, challenge assumptions, and find risks the team itself might not see.
Solution: A four-stage audit built on observable evidence
How Enji Fleet and Enji Guard supported the audit
Alongside the manual review, we used two of our own AI tools from the Enji platform: Enji Fleet and Enji Guard. Because the audit had no access to the client’s code, neither tool scanned the repositories. Their job was to make the human part of the audit faster and more systematic.
Enji Fleet runs recurring engineering work with specialized AI agents. Instead of handing a complex assessment to one general-purpose assistant, Fleet splits it into focused tasks and runs each one through a predefined procedure, or runbook. In this audit, Fleet agents:
- Turned the 18 key questions and the system context into tailored checklists, interview questions, and a demo-session plan for each area.
- Processed the artifacts the target company opened for review (knowledge base, task tracker, team chats) and flagged contradictions with interview answers for auditors to raise in the next session.
- Consolidated findings from four codebases and seven assessment areas into one report structure, mapped to the 18 questions and ranked by priority.
Enji Guard is an AI code auditing tool that checks repositories for security issues, outdated dependencies, test quality, CI/CD gaps, and dead code. In this audit, Guard’s check catalog served as the code-level checklist for the guided sessions: it defined which checks the product team ran on screen and the categories auditors used to record the results.
When a client can grant access, Guard connects to repositories through scoped, revocable GitHub App access and reads the code in a temporary workspace that is removed afterward. For stricter environments, it runs self-hosted, inside the client’s own infrastructure and with the client’s own AI provider.
Automated checks still cover only part of a due diligence. No tool can tell whether a team can recover from a major incident, whether key decisions are written down, or whether the product survives the departure of two engineers. Those answers came from interviews and engineering judgment, and they led to the audit’s most important finding.
What the audit found
The platform was a working, revenue-generating product with a modern core. Its main backend ran as Go microservices in Kubernetes, deployments went through a GitOps pipeline built on ArgoCD and Terraform, and the team shipped backend releases five to six times a week. The API averaged 100 ms per request at current load. About 70% of the server-side functionality had already been migrated from a legacy Node.js backend to Go, with a clear strategy for the rest. Against this foundation, the audit identified five groups of risks:
Finding 1: Critical knowledge was concentrated in a few people
A small, fast team with little documentation: efficient today, fragile under a new owner.
What we found
- One frontend developer and one QA engineer.
- Legacy Node.js modules and the balance-locking service understood by only a few engineers.
- Requirements and architecture decisions passed on verbally or kept in chats.
- No onboarding checklists; new developers needed 2–4 weeks of close mentoring.
- Part of the team also worked on another product.
Risk: buying the code would not guarantee the ability to maintain it.
Recommended: a knowledge base with named owners, documented decisions, onboarding and offboarding checklists, a RACI matrix, and agreement on key engineers’ involvement at the deal stage.
Finding 2: Code-level risks to transaction integrity
Two critical issues could cost money directly.
What we found
- User balances stored as floating-point numbers, causing rounding errors.
- No graceful shutdown in the Go API, schedulers, and lock service, so a deployment could interrupt a financial operation.
- 1,057 linter warnings, 277 panic calls, and 272 unhandled errors in the Go code.
- No backend unit tests; QA automation covered 39% of key scenarios, outside CI/CD.
- The legacy Node.js backend had 613 linter errors and was no longer being improved.
Risk: financial losses and growing maintenance costs.
Recommended: exact types for balances, SIGTERM handling in every service, linters and tests in CI/CD, and 15–20% of each sprint for technical debt.
Finding 3: A single database limited growth and resilience
What we found
- One Percona (MySQL) instance for all services, vertical scaling only.
- Years of archived data kept alongside live data, with no replication or partitioning.
- The balance-locking service as a second single point of failure.
- No disaster recovery plan and no RTO or RPO.
- No distributed tracing or business metrics in monitoring.
Risk: a database failure with unpredictable downtime and data loss, made worse by recovery knowledge held by a few engineers.
Recommended: partitioning and archiving, replication, a tested recovery plan with defined RTO and RPO, and tracing with structured logs.
Finding 4: Security stopped at the perimeter
Strong: Vault for secrets, SSO with role-based access, separate staging and production clusters.
What we found
- Unencrypted traffic between services, the database, the cache, and the message broker.
- No security scanning in CI/CD pipelines.
- Pods running as root, no network policies, Vault audit logs disabled.
- No incident response plan.
- 3 critical and 20 high-severity vulnerabilities in Node.js, 26 in the admin panel, critical ones in the frontend.
Risk: one compromised service exposes all internal data.
Recommended: now patch critical dependencies, move tokens to HTTP-only cookies, enable internal TLS. Next: mTLS, pipeline scanning, network policies, an incident response process.
Turning findings into an acquisition decision
Technical audits often end with a long list of issues and leave the buyer to work out what matters. We built the final report around the decisions the buyer had to make.
Challenge 2: Making technical risks actionable for the buyer
A list of vulnerabilities does not tell a buyer what to do. The client needed to know which risks required action before or right after the deal, how long the fixes would take, and whether the platform was worth building on.
Solution: Prioritized recommendations, direct answers, and a rebuild estimate
Each finding in the report came with its consequences, a priority level from critical to low, concrete remediation steps, and a business justification. The report answered each of the 18 approved questions directly and gave the buyer the timelines needed for planning:
- Priority fixes: about 2–3 months of team work.
- Longer-term debt (data layer, completing the Node.js migration, typing): another 6–9 months.
- Process formalization and documentation: an investment for the first 6–12 months after the acquisition.
- Integration into the buyer’s organization: a phased transition of at least 12 months.
We also estimated what it would take to recreate comparable functionality from scratch: a team of nine engineers working for about 20 months, at $400,000–$680,000. The estimate covered development only and excluded requirements analysis, marketing, licenses and infrastructure, hiring costs, and the existing user base and brand. It was a reference point for the engineering effort behind the platform, not its market value.
Key results
- Acquisition risks made concrete. The buyer received 7 critical-priority issues, each with a fix, a priority, and a time estimate, separated from improvements that could wait for longer-term planning.
- A continuity risk that code analysis alone would miss. The audit showed that the platform’s sustainability depended on a few people and gave the buyer a plan to reduce that dependency, along with terms to agree on at the deal stage.
- A clear picture of what to invest and when. Fix timelines, the transition period, and the rebuild estimate gave the buyer inputs for budgeting and negotiation.
- A balanced view of the asset. The report confirmed the platform’s strengths (a modern Go core, GitOps infrastructure, frequent releases, stable performance) alongside its risks, so the buyer could weigh both.
- Delivered ahead of schedule without code access. Close collaboration with the product team let us finish early while working only through interviews, guided sessions, and the artifacts the target company opened.
Audit scope
This engagement assessed the platform’s existing technology, team, and processes rather than building new software.
Technical due diligence beyond the codebase
A technical audit asks whether the technology, infrastructure, processes, and people behind a product can keep it running and growing under a new owner. Code quality is one input to that answer.
Access restrictions are common in acquisitions and investment deals, where the buyer does not yet control the target’s systems. Banks, fintech companies, and other regulated organizations face similar limits whenever an external team needs to assess their technology.
Mad Devs adapts the audit method to these constraints: controlled evidence collection, experienced engineers, and AI-assisted analysis with Enji Fleet and Enji Guard, which work within whatever access a client can grant, up to a fully self-hosted setup. The result shows what needs fixing, what the organization depends on, and what it will take to make the product ready for its next owner. A reliable technology business needs more than reliable code.
