Software technical due diligence is the practice of verifying, with artefacts instead of assurances, that a codebase can be safely owned and changed by people who did not write it. It covers architecture, dependencies, tests, deployment, secrets, security and documentation. The output is a priced risk register rather than a pass or fail grade.
"Maintainable" is an opinion. Every vendor believes their code is maintainable, and most are sincere, because it genuinely is maintainable by them. They know which service to restart when the queue backs up, and which migration must never run twice. None of that is in the repository. It lives in a few heads, and you are not buying those.
So stop asking. Ask for the pack below and read what comes back. The gap between the answer and the artefact is the assessment.
of 947 audited commercial codebases contained open source (Black Duck)
of those codebases carried licence conflicts
in the request pack, sent in one message with a deadline
When do you actually need technical due diligence?
Technical due diligence applies in three moments: you are acquiring a company whose software is the asset, you are changing vendors and inheriting code you did not commission, or the people who built the system are leaving. All three share one feature. The knowledge keeping that software alive is about to walk out of the building.
Acquisitions get the most legal attention and the least engineering time. Lawyers spend six weeks on warranties while an engineer gets a Friday afternoon with a read-only repo. That is how buyers inherit a payments integration nobody can redeploy.
Vendor changes are messier, because the outgoing vendor is your main source of information about themselves. In a competitive process, fold this pack into the brief you send prospective partners, alongside the buying checklist in our guide on how to hire a software development company.
The key-person case is quietest and most urgent. A lead developer resigning with 60 days left is a countdown. Spend week one on the handover, not week eight.
What should you ask for? The request pack
Ask for twelve artefacts: architecture and data model, dependency inventory with licences, test coverage, CI/CD and release process, environments and infrastructure-as-code, secrets and access inventory, monitoring and incident history, security posture, documentation and onboarding time, code ownership, a technical debt register, and IP ownership. Send them in one message with a deadline.
| What you ask for | What a good answer looks like | What the red flag is |
|---|---|---|
| Architecture and data model | A current diagram, plus an ERD from the live schema | A whiteboard photo, or "it's all in the code" |
| Dependency inventory and licences | An SBOM (CycloneDX or SPDX) with versions and licences | package.json as the inventory; no idea whether AGPL ships |
| Test coverage and what's tested | A coverage report plus the critical paths it asserts on | One percentage, or specs skipped in CI for months |
| CI/CD and release process | Pipeline definitions in the repo, deploy frequency, proven rollback steps | Deploys from a laptop; the release process is a person |
| Environments and infrastructure-as-code | Terraform, Pulumi or Ansible in version control, staging rebuilt recently | Hand-configured servers; one box nobody will touch |
| Secrets and access inventory | A managed store like Vault, a rotation date, who holds what | Credentials in the repo, a shared sheet, or chat |
| Monitoring and incident history | Dashboards, alert rules, a year of incidents written up | "We haven't had incidents." Nobody has had no incidents |
| Security posture and open vulnerabilities | A dated scan, a decision against each CVE, last pen-test date | No scan, or criticals open with no owner |
| Documentation and onboarding time | A README that works end to end, plus runbooks | Documentation that describes intent instead of commands |
| Code ownership and bus factor | git shortlog -sn per module, a named second person per area | One author owns billing, auth, or the key integration |
| Technical debt register | A written list with impact and cost, kept before you asked | Written for the first time because you asked |
| IP ownership and third-party licences | Assignment clauses for contractors; licences for fonts, SDKs, APIs | No assignment clause; a design system on a personal account |
Two rows carry more weight. The dependency inventory matters because a large share of what you're buying was written by somebody else. Black Duck's 2026 Open Source Security and Risk Analysis, an audit of 947 commercial codebases, found open source in 98% of them and licence conflicts in 68%, and a licence you cannot honour is a legal problem no refactor fixes. Coverage is the opposite case: the easiest metric to game. Ask what the tests assert rather than how many lines they touch, using the guide in our piece on manual, automated and AI-assisted testing.
Then watch how the pack comes back. A mature team replies in days, because these documents already exist as a by-product of how they work. The others send a deck.
What's the single most revealing thing to ask for?
Ask to watch a developer who has never seen the codebase go from a clean machine to a running local environment, timed, on a shared screen. That one exercise tests documentation, dependency management, secrets handling and tribal knowledge at the same time. Record the elapsed time and every question the developer asks.
I rate this above every document in the pack, because documents describe the system a team wishes it had and this shows the one they have. Watch the interruptions rather than the total. When the developer hits an error and someone says "ah, you need the seed dump from Priya", that is a bus-factor finding. When somebody pastes a .env file into chat to clear a config error, you have learned how secrets are actually handled. A README that stops working at step four means the last person to onboard fixed it locally and never went back.
My bar is two hours from clone to a working app with realistic data. Half a day is survivable. Past a full day, that figure is the onboarding cost for every developer you put on this system.
What do the commit history and issue tracker tell you that the vendor won't?
Version control and the issue tracker record behaviour rather than claims. Commit frequency, author concentration, message quality, revert rate and the age of open bugs describe how the team actually worked. Read them before you read any slide. Start with git shortlog -sn and the twenty oldest open issues.
Patterns show up fast. Huge commits landing late at night before every release mean there is no safe way to ship a small change. One author across the payments module means the bus factor is one, whatever the org chart says.
The issue tracker holds the honest roadmap. Read the bugs open for two years that still attract comments. Those are the problems the team knows about, cannot fix cheaply, and left out of the deck.
One check people skip: the date of the first commit. If a five-year-old product has a repository whose history starts eleven months ago, it was rewritten or re-initialised. Ask why, and keep asking until the answer is specific.
How do you price the risk instead of walking away?
Convert each finding into remediation days, then decide who pays for them. Estimate the engineering effort to reach a safe baseline, add contingency for what the first sprint uncovers, and negotiate the total as a price reduction, an escrow holdback, or work the seller funds before completion. Reserve walking away for findings you cannot cost.
Almost every system fails diligence somewhere. Abandon a deal over test coverage and you will never buy anything. The discipline is arithmetic: no secrets management becomes two weeks to move credentials into a managed store and rotate them, so quote it and put it on the schedule of adjustments. A finding with a number attached works in your favour. One without a number is how deals die quietly.
There is a threshold where the arithmetic flips. When remediation approaches the cost of rebuilding the same capability, you are buying a customer list with a hosting bill. Our comparison of rebuild, refactor and replatform for legacy apps sets out that call, and the answer is usually partial: replace the unowned modules, keep the rest.
Assume the findings will move the price rather than end the deal, and price them yourself before the other side does. Plan for that conversation from day one and your engineers will scope findings instead of complaining.
Who should run it, and why not the incumbent vendor?
An independent reviewer with no stake in the outcome should run technical due diligence. That means an in-house engineer who will not inherit the system, or a third-party consultancy engaged for the review alone. The incumbent vendor cannot audit itself, because every finding is an admission against its own contract and renewal.
The problem is structural rather than moral: a vendor grading their own code, for a client deciding whether to keep them, marks generously without meaning to. The incoming vendor has the mirror problem. If the reviewer also wins the remediation work, every finding becomes a line item on their next invoice, and "rebuild everything" starts to look attractive. Pay a fixed fee for the review, keep it separate from any fix, and require the reviewer to say plainly when nothing needs doing.
Check process maturity on the reviewing side too. Shanti Infosoft is appraised at CMMI Level 5, so our own architecture docs and defect records exist because an appraiser verified them, not because a client asked. Firms that produce these artefacts as routine recognise a real one, and that judgement is most of what you buy in a software consulting engagement.
The technical due-diligence checklist
Work through these twelve steps in order. The early items are cheap and disqualifying: ownership, access, and the timed onboarding test come before any deep code reading. Each step should produce a document or a number you can put in front of a lawyer.
- Confirm who legally owns the code, including every contractor's assignment clause.
- Get read access to the repo, issue tracker and CI logs, not a zip.
- Run the timed clone-to-running-app test with a developer new to the code.
- Request an SBOM with licences; flag anything copyleft that ships to customers.
- Pull
git shortlog -snper module and find every area with one author. - Read the twenty oldest open issues and a year of incident write-ups.
- Check that staging rebuilds from infrastructure code, and when it was last proven.
- Inventory secrets and everyone with production access, including ex-staff.
- Review the latest vulnerability scan and the decision against each critical.
- Ask what the tests assert on the three most business-critical paths.
- Collect the technical debt register and date-check it against the repo.
- Turn every finding into days, price it, take it to the negotiation.
Inheriting a codebase this quarter? Bring the twelve-item pack to a 30-minute call and we will tell you which findings are priceable and which should stop the deal. Book a slot.
Frequently Asked Questions
How long does technical due diligence take?
One to three weeks for a single product: days collecting artefacts, days hands-on, then a written risk register. Slow access stretches it, and the delay is itself a finding.
What if the vendor refuses to hand over the artefacts?
Treat refusal as an answer. Some is fair: live credentials should never move during a review, and redacted copies solve that. Withholding diagrams, dependency lists or CI configuration has no defence.
Can you assess a system without source-code access?
Partially. You can test the running app, review the API, check dependency exposure and interview the team. Internal structure stays invisible, so treat it as a screening pass.
Is high test coverage a good sign?
Only when you know what the tests check. A suite hitting 90% of lines while asserting almost nothing is worse than 40% aimed at checkout, auth and billing. Ask which rules would break the build.
What is an acceptable bus factor?
Two people who can deploy and debug each critical area, one of whom stays after the transaction. One owner on an admin screen is tolerable. On payments or authentication, it needs a costed fix.
Should the seller's team be in the room during the onboarding test?
Yes, and silent. Their instinct to help is what you are measuring. Ask them to note every point where they wanted to intervene, then turn that list into the first month's documentation backlog.
Have a project in mind? Let's scope it together.
You get a named team, written estimates, full code and IP ownership, and 48-hour response times. CMMI Level 5 certified. 700+ projects delivered across the UK, US, UAE, and Australia.
