The data room contains 63 files. Source-code access is still “coming tomorrow.” The architecture slide says the platform is cloud native, secure, and ready to scale.
Technical due diligence begins where those adjectives stop. Which repository proves the product is owned? Which test proves the load claim? Which incident record shows how the system recovers? Which dependency or service can block the first 100-day plan?
We’re gmware, a custom software development firm in Austin, Texas, with engineering centers in Bangalore and Mohali, India. We build and modernize software, so our bias is simple: every material technology claim should lead to evidence and a business consequence. A thick report with no deal linkage is expensive filing.
This is an engineering review method, not legal, tax, accounting, investment, or valuation advice. Those conclusions stay with the qualified people engaged for the transaction.
Translate the deal thesis into testable claims
Do not start with a generic list of code-quality checks. Start with the reason the deal exists.
An acquirer may believe the product can enter a regulated market within a year. An investor may believe revenue can double without rebuilding the platform. A buyer may expect the engineering team and intellectual property to transfer cleanly. Each belief creates a different review.
Write the claims before opening the repository:
| Deal claim | Evidence that could support it | Evidence that could break it | Decision affected |
|---|---|---|---|
| The platform can handle planned growth | Traffic history, capacity tests, bottleneck analysis, scaling runbook | No representative test, single-node state, hard service quotas | Integration budget and timing |
| The buyer receives the working product | Repository ownership, contributor agreements, licenses, cloud-account control | Personal accounts, missing assignments, unknown copied code | Closing condition and legal review |
| Releases can continue after close | Build definition, deployment history, environment inventory, rollback proof | Manual laptop builds, one-person secrets, undocumented production access | Retention and transition plan |
| Security work is managed | Threat model, control tests, vulnerability handling, incident record | Unowned findings, exposed credentials, unsupported components | Remediation reserve and risk acceptance |
| The team can execute the roadmap | Ownership map, cycle evidence, hiring plan, technical constraints | Knowledge trapped with one person, chronic unplanned work | Staffing and first 100-day plan |
That last column prevents the report from turning into a linter transcript. If a finding cannot alter a decision, priority, term, reserve, or integration sequence, ask why it is in the executive section.
Establish provenance before quality
Beautiful code is worthless to a buyer who cannot prove the company controls it.
Trace the product from customer-facing service to repositories, build inputs, artifact registries, cloud accounts, domains, data stores, and third-party services. Record who controls each one today and what must transfer. Sample commit history and contributor relationships. Inventory open-source and commercial dependencies, then send license and ownership questions to counsel.
An automated inventory helps, but it is not proof of completeness. GitHub’s current documentation says its dependency graph can be exported as an SPDX-compatible software bill of materials. Treat that export as one input. Compare it with lock files, container images, build scripts, vendored code, browser assets, and services purchased outside the repository.
NIST’s July 2026 Cybersecurity Supply Chain Risk Management Due Diligence Assessment Quick-Start Guide is scoped to ICT suppliers rather than M&A software review. Its evidence habit still travels well: investigate pertinent information so an acquisition or existing-system decision is informed, and examine provenance, resilience, foundational cyber practices, and supply-chain tiers. Do not present the guide as a universal transaction checklist.
Reproduce one release
Ask the target team to build and release a representative version in a controlled environment. Watch the path. Where do credentials come from? Which step depends on one engineer’s laptop? Can the team name the deployed commit? What evidence shows database changes ran? How is rollback decided and tested?
This exercise compresses weeks of interviews into a few hours. It also distinguishes stale documentation from working operations.
Capture the release as a chain:
- approved change and review evidence
- reproducible build inputs and artifact identity
- security and quality gates that actually ran
- deployment authorization and environment change
- health evidence, rollback boundary, and accountable operator
Five links are useful here because the chain fails at its weakest handoff. A mature-looking CI screen does not compensate for a database change copied from chat, nor does a signed artifact help if nobody can tie it to production.
The NIST Secure Software Development Framework supplies a common vocabulary for secure development practices and explicitly notes that purchasers can use it in acquisition conversations with suppliers. Use it to form evidence questions. Do not claim SSDF alignment because a scanner passed.
Separate exposure from repair cost
Technical severity and deal effect are different axes.
A severe vulnerability behind an isolated, disabled component may have a direct repair. A modest architectural constraint in the transaction’s main growth path may require a long rewrite. The report should state both the exposure and the work needed to change it.
Use four fields for every material finding:
| Field | Required answer |
|---|---|
| Observed condition | What the reviewer saw, with repository, environment, version, and date |
| Consequence | Which failure or deal assumption the condition affects |
| Repair path | The smallest credible change, dependencies, and proof needed |
| Estimate basis | Comparable work units, unknowns, owner, and confidence level |
Do not convert a scanner’s severity label straight into a dollar reserve. Verify reachability, deployment, exploit evidence, compensating controls, and business exposure. CISA describes its Known Exploited Vulnerabilities Catalog as an authoritative source for vulnerabilities exploited in the wild and recommends using it as an input to prioritization. It is an input, not the whole priority model.
If a web application is in scope, the OWASP Application Security Verification Standard can provide testable control requirements and a consistent reference format. Choose the relevant requirements and version. A due diligence reviewer who writes “fails OWASP” without a version, requirement, test, and affected boundary has not produced a reproducible finding.
Test the operating claims, not just the code
Repositories reveal design. Operations reveal consequences.
Inspect a sample of incidents, support escalations, failed deployments, recovery tests, and capacity events. Tie each event to the code and architecture in force at the time. Ask how long detection took, who decided the response, what customer effect occurred, which correction landed, and whether the same failure returned.
Then check concentration. Which engineer can deploy, rotate a credential, explain the billing engine, or recover the primary database? A bus-factor spreadsheet based on file ownership is only a lead. Interview the supposed backup and ask that person to walk the runbook.
Metrics need denominators and definitions. “99.99% uptime” is not testable until the report identifies the service boundary, observation point, time window, exclusions, and raw evidence. “Handles ten times traffic” needs a workload shape, environment, failure threshold, and date. Treat screenshots of dashboard percentages as clues, not conclusions.
Our technical debt cost guide explains why a debt list needs an affected flow and cost mechanism. For a system already near its limits, the legacy modernization assessment shows how to separate stabilization, targeted replacement, and a rewrite.
Make access limits impossible to miss
Every review has blind spots. Name them near the verdict.
If production logs were unavailable, say which operating claims could not be checked. If the team supplied a code snapshot rather than repository history, ownership and delivery conclusions are limited. If load tests used synthetic traffic, state how it differed from the claimed workload. If the buyer barred employee interviews, flag the knowledge-concentration assessment.
Use confidence labels only after defining them. “High confidence” might mean two independent evidence sources plus direct reproduction. “Low confidence” might mean an interview statement with no system access. Put the definition in the report.
Silence is worse than a caveat. A reader will otherwise treat an untested area as a passed area.
What the buyer should receive
The final packet needs two reading paths.
The decision path is short: claims tested, findings that change the transaction or integration plan, open conditions, repair sequence, and explicit limits. The engineering path holds evidence references, reproduction steps, affected versions, detailed findings, and follow-up tests.
Include an evidence index the buyer controls. Links into the reviewer’s private workspace will expire at exactly the wrong time. Sensitive materials should remain under the deal’s access, retention, and disclosure rules.
The report should also distinguish pre-close conditions from first 30-day containment, first 100-day work, and longer modernization. Not every weakness must be repaired before close. Every accepted weakness needs an owner and a date.
How gmware scopes a technical review
We start with the business claims, then choose the smallest technical scope that can test them. Product engineering questions map to our product development practice. Security control tests map to cybersecurity engineering. Systems that need a repair sequence rather than a transaction review belong with legacy application modernization.
Sometimes a focused architecture or code review is enough. If no acquisition, investment, or partnership decision depends on the broader work, do not buy a transaction-sized report.
Send us the deal thesis and the date that cannot move. We’ll return the evidence access we need, the questions we can answer, and the limits we expect before proposing a review. Reach out.