How to Run a Technical Due Diligence Audit on Custom Software

You have three weeks before the deal closes, and someone just asked the question nobody wants to hear: "Is the code actually any good?" The pitch deck says the platform scales. The revenue says customers love it. But nobody on the buy side has opened the repository, and the founder who wrote most of it is already planning their next thing.

A technical due diligence audit exists to answer that question with evidence instead of vibes. It is not a code review for style points. It is a structured risk assessment that tells an investor, acquirer, or board whether the software can survive the next stage of the business — more users, more engineers, more compliance, or a new owner.

This guide gives you the framework we use when we are brought in on either side of a deal: what to inspect, how to weight what you find, and how to convert a pile of findings into a clear recommendation.

Key takeaways

• A technical audit is a risk assessment, not a bug hunt — you are pricing future cost and uncertainty, not grading code aesthetics.
• Scope it to the deal thesis: a seed-stage SaaS and a regulated enterprise platform carry completely different audit checklists.
• Inspect five domains in order: architecture, code quality, security, scalability and operations, and team/process.
• Every finding needs a severity, a business consequence, and a rough remediation cost — findings without those three are noise.
• The deliverable is a decision memo, not a report: proceed, proceed with conditions, reprice, or walk.

What a technical due diligence audit actually evaluates

Most audits fail because they try to assess everything. The better approach is to start from the deal thesis and work backwards. If the investment case is "this product will double its user base in a year," then scalability and onboarding velocity matter far more than whether the CSS is tidy.

Define the questions the audit must answer before you touch a repository. Typical ones look like this:

• Can this system handle the growth the business plan assumes, without a rewrite?
• Are there security or compliance exposures that create legal or financial liability?
• How much of the value lives in the code versus in the people who wrote it?
• What is the realistic cost to bring this codebase to a maintainable standard?
• What is hidden — licensing issues, third-party dependencies, undocumented infrastructure?

Write those questions down. Every hour you spend later should map back to one of them. This is also the point where you decide who runs the audit: an internal engineer with deal context, an external firm, or both. If you need a team that has sat on both the build and the diligence side, that is the kind of work we describe under our software development and advisory services.

Step 1: Inventory the system before judging it

You cannot assess what you cannot see. The first pass is pure inventory, and it usually takes a day or two.

What to collect

• Repository access (read-only is fine) including full commit history, not a squashed snapshot.
• Architecture diagrams — and a note on whether they match reality.
• Infrastructure and deployment configuration: cloud accounts, IaC files, CI/CD pipelines.
• Third-party dependencies, licenses, and any commercial or open-source obligations.
• Monitoring, alerting, and incident history.
• Contracts and IP assignments for every contributor, including contractors.

The single most common discovery at this stage is a gap between the documented architecture and the deployed one. Diagrams describe a clean service boundary; production runs three services that call each other directly and share a database. That is not automatically fatal, but it changes your risk model, and it needs to be documented.

Step 2: Audit the codebase and architecture

When you audit a codebase before acquisition, resist the urge to read it line by line. You are sampling for systemic patterns, not hunting individual bugs.

Code quality signals that matter

• Test coverage where it counts. Not a single percentage — look at whether the critical paths (payments, auth, data mutations) are covered and whether tests actually assert behavior.
• Consistency. Mixed paradigms, three HTTP clients, and four ways to talk to the database suggest no ownership or standards.
• Complexity hotspots. Large files and functions that everything depends on are your future refactoring bill.
• Dead code and abandoned experiments. Feature flags that were never cleaned up hint at shipping discipline.

Architecture questions to ask

• Is the system a monolith, and is that a deliberate choice or an accident?
• Where are the coupling points, and what breaks if one of them fails?
• Is data ownership clear, or do multiple services write to the same tables?
• How hard is it to add a new engineer to this system, realistically?

A pragmatic monolith with good tests is a far better asset than a distributed system nobody understands. Judge fitness for the business plan, not fashion.

Step 3: Security and compliance review

Security findings are the ones that can kill a deal outright, so give them their own pass with their own reviewer if possible.

• Secrets management. Search history for committed credentials. Assume anything ever committed is compromised.
• Dependency risk. Known vulnerable packages, unmaintained libraries, and transitive dependencies you have never heard of.
• Authentication and authorization. How sessions work, whether permissions are enforced server-side, and how admin access is granted.
• Data handling. Where personal data lives, how it is encrypted, who can access it, and what the retention policy is.
• Compliance posture. If the business claims SOC 2, GDPR, HIPAA, or PCI alignment, verify what is actually implemented versus aspirational.

Document each issue with an exploitability rating. "A dependency has a known CVE" is not a finding; "this dependency is reachable from the public API and processes untrusted input" is.

Step 4: Scalability, reliability, and operations

This is where you test whether the growth story is technically plausible. Ask for evidence, not assurances.

• Load test results, or a plan to produce them if none exist.
• Database performance: query patterns, indexes, and the largest tables.
• Single points of failure across compute, storage, and third-party APIs.
• Deployment frequency and rollback capability — can they ship on a Friday?
• Backup and disaster recovery, including whether restores have ever been tested.
• Cloud cost trajectory relative to revenue.

Teams often find that the architecture is fine but the operational muscle is thin: no on-call rotation, no runbooks, no monitoring beyond basic uptime. That is a fixable, quantifiable gap — and it belongs in the cost model.

Step 5: Assess the team and knowledge concentration

Code is only half the asset. The other half is the ability to keep changing it.

• Who are the key contributors, and what happens if they leave?
• Is there a bus factor problem — one person who understands the billing system?
• What does the onboarding path look like for a new senior engineer?
• Are code review and release processes real, or ceremonial?
• What is the contractor situation, and is IP properly assigned?

Knowledge concentration is the most under-priced risk in small acquisitions. A codebase that only one person can safely modify is worth materially less than the same code with documentation and a team around it.

Turning findings into a decision

Raw findings are not a deliverable. Convert each one into three things: severity (blocker, high, medium, low), business consequence (what breaks, when, and for whom), and remediation estimate (rough effort and who would do it).

Then sort into four buckets:

1. Deal breakers. Security exposures, IP ownership gaps, or architecture that cannot support the thesis.
2. Reprice items. Real work required, with a defensible cost attached.
3. Conditions. Fix within a defined window post-close, with milestones.
4. Accepted risk. Known, bounded, and consciously owned.

That structure turns a technical report into something a non-technical decision maker can act on. If you want a second opinion on findings before you sign, or you are on the sell side and want to fix problems before they surface in someone else's audit, it is worth talking to our team early rather than mid-negotiation.

Avaton builds and reviews custom software across AI/ML, blockchain, and mobile platforms, and we regularly run this kind of audit for both buyers and founders — you can see the shape of that work in our past projects.

Frequently Asked Questions

How long does a technical due diligence audit take?

For a typical small-to-mid-size product, a focused audit runs one to three weeks depending on scope, codebase size, and how quickly the target provides access and answers. A narrow review of one critical subsystem can be done in days. The timeline usually stretches not because of analysis but because of waiting on repository access, infrastructure credentials, and interviews with key engineers.

What is the difference between a code review and a technical due diligence audit?

A code review evaluates a specific change for correctness and quality. A technical due diligence audit evaluates the whole system against a business thesis: architecture, security, scalability, operations, team, and legal exposure. The audit samples the code as evidence but its output is a risk and cost assessment for a decision maker, not a set of comments on a pull request.

Can we run a technical audit without full source code access?

You can, but your confidence drops sharply. Without repository history you cannot see how the system evolved, whether secrets were committed, or how disciplined the engineering process was. If full access is refused, treat that as a signal in itself and rely more heavily on architecture interviews, infrastructure review, and independent load or penetration testing.

What are the most common deal-breaking findings?

In our experience the recurring blockers are unassigned or contested intellectual property, serious security exposures such as committed credentials or unauthenticated admin surfaces, and architecture that cannot support the growth assumptions in the business plan without a rewrite. Licensing violations in third-party dependencies also appear regularly and can create real legal exposure.

Should a founder run a technical audit before raising or selling?

Yes. A pre-emptive audit lets you fix or document issues on your own timeline instead of defending them under negotiation pressure. Founders who run one typically find that most findings are explainable and fixable, and walking into diligence with a prepared remediation plan builds credibility and protects valuation.

Cover: Photo by Godfrey Atima on Pexels