Technical Due Diligence for Custom Software: What Investors and Buyers Should Actually Check
Solid technical due diligence verifies you own the code and accounts, the system is buildable and operable by someone other than the original vendor, and security and compliance claims hold up under evidence—not under slide decks.
Whether you are a founder raising a round, a corporate venture team backing a build, or a procurement group about to renew a seven-figure statement of work, technical due diligence answers one blunt question: if the team in front of us disappeared tomorrow, could we still ship and run this product? The mistake is treating diligence as a code review beauty contest. The win is a short list of verifiable facts: repository and cloud access, IP assignment, dependency and secret hygiene, deployment path, on-call reality, and whether documentation lives in repos or in someone's head. This guide walks through what to request, what good answers look like, and where buyers get surprised. It reflects how Baaz prepares engineering artefacts for serious buyers and how we advise clients evaluating partners—without turning diligence into a months-long paper chase.
Why diligence is a continuity exercise, not a scorecard
A codebase can look messy yet be salvageable; it can look polished yet hide deployment fragility or licensing landmines. Diligence should reduce continuity risk: ownership, operability, and truth about production.
If you only skim architecture diagrams, you learn how vendors sell. If you verify access, runbooks, and incident history, you learn how they ship.
Ownership and IP: what must be in writing
Confirm contracts assign work product to your entity, including contributions from subcontractors. Beware "license to use" language that does not convey ownership of custom code.
List third-party and open-source components with licenses compatible with your commercial plans. GPL-style obligations in the wrong layer can constrain distribution models.
Capture who holds domain names, app store accounts, analytics properties, and DNS—these are often forgotten until a breakup.
Access you should demand (and test)
Read access to source control with history, not a ZIP export. You want to see branching, review culture, and release tags—not a sanitized snapshot.
Access to cloud accounts or a documented handover path: which accounts own production, who can create IAM users, and whether MFA is enforced.
CI/CD pipelines: can a neutral engineer run a build and deploy to a non-production environment following written steps? If the answer is "only Raj knows," you have a bus-factor problem.
Security and data handling: evidence, not adjectives
Request recent dependency scan results, penetration test summaries if applicable, and how secrets are stored (never committed in git). Ask for subprocessors and data-flow diagrams for personal or regulated data.
Verify backup and restore were tested on a schedule you find credible—not assumed. Untested backups are wishes.
Check authentication and authorisation boundaries: admin APIs, tenant isolation tests, and audit logs for sensitive actions.
Architecture and technical debt: questions that surface truth
Ask for a current architecture diagram and a list of known technical debt with business impact—not a generic "we have some debt" shrug.
Identify single points of failure: one server, one founder with root, one opaque integration. Ask what happens when that dependency fails.
Understand data migration and schema evolution: how are database changes shipped safely? Missing migration discipline predicts production incidents.
Delivery hygiene: how you know the team can keep shipping
Look for automated tests on critical paths, PR reviews, and trunk-based or short-lived branch habits. Absence does not always doom a project, but it raises the cost of every future hire.
Inspect observability: structured logs, metrics, tracing hooks, and alerting tied to user-impacting symptoms—not only CPU graphs.
Review incident history for the last six to twelve months: frequency, severity, time to restore, and post-incident changes. Mature teams learn in public; opaque teams repeat failures quietly.
Vendor-specific diligence: continuity if you switch partners
Ask how knowledge is documented for handover: runbooks, environment inventory, architecture decision records, and backlog hygiene.
Clarify escrow or exit terms if the vendor hosts critical artefacts. Escrow is rarely exercised, but forcing the conversation surfaces who actually holds the keys.
For fixed-scope contracts, verify milestone definitions map to deployable increments—not document deliverables that never touched production.
Red flags that deserve a pause
You cannot get independent git access after an NDA. Serious builders do not hide the repository from paying owners.
No staging environment or staging diverges wildly from production. You will pay for that gap in incidents.
Undocumented environment variables and "tribal" deploy steps. That is operational debt compounding weekly.
Inability to explain who is on call and how outages are declared. If production matters, someone answers the pager.
A practical half-day diligence agenda
Morning: legal/IP pass with counsel, repository access verification, dependency and license export. Afternoon: walkthrough of deploy pipeline, staging demo, incident and backlog review with engineering leads.
End with a written findings list: blockers, mitigations, and costed remediation options. Numbers beat vibes when boards ask what you learned.
Explore Product Strategy, Custom Software, and AI Development. If a build has stalled, see software project rescue. When you are ready to talk, get in touch.