At some point in a funding round or acquisition, someone will ask to look under the hood. It might be an investor's in-house engineer, an outside firm or a technical advisor. Their job is to find risks that could hurt the business after the money arrives.
Technical due diligence rarely kills a deal on its own. What hurts is surprises: things the reviewer finds that you didn't know or didn't mention. Preparing ahead turns surprises into a list of known issues with a plan.
What reviewers are actually looking for
Reviewers are not grading code style. They're trying to answer a few business questions:
- Does the company actually own its technology and data?
- Can the product scale with the growth in the plan?
- Are there security or compliance risks that could cause a breach, fine or lost customer?
- Can the team keep shipping if a key person leaves?
- How much hidden work stands between today and the roadmap?
Keep those questions in mind as you prepare. Every item below maps to one of them.
Ownership and access
This is the most common and most fixable problem in young companies. Code, domains and cloud accounts are often scattered across personal accounts of founders, freelancers or agencies.
- Move every repository into an organization account owned by the company.
- Make sure cloud hosting, database, domain registrar, app store and payment accounts are company-owned, with at least two admins.
- Collect signed agreements assigning IP to the company from every contractor and agency that wrote code.
- Remove access for people who no longer work with you.
- Store credentials in a shared password manager, not in someone's notes or chat history.
Code and architecture
Expect the reviewer to read a sample of your code and ask how the system fits together. You don't need perfection. You need to show that you understand what you have.
- A short architecture overview: the main components, where data lives and which outside services you depend on.
- A README that lets a new developer run the app locally.
- Automated tests on critical paths like signup, payments and core features, even if coverage is modest.
- A list of known technical debt, with rough priority and what it would take to address.
- A clear deployment process, ideally automated, rather than manual steps one person remembers.
If much of the code was generated with AI tools, say so plainly. Reviewers care more about whether it's been reviewed, tested and secured than how it was written.
Security and data
Security findings are where reviews most often turn up serious issues. Check these before anyone else does.
- No secrets committed in the repository history. If any were, rotate them.
- Access controls on every database table and API, enforced on the server.
- Dependencies reasonably up to date, with no known critical vulnerabilities left unpatched.
- Backups running, with a restore that has been tested.
- Logging and error tracking in place, without passwords or tokens in the logs.
- A basic written record of what personal data you store, where, and why.
If you serve larger customers, have your answers to common security questionnaires ready. Reviewers will often ask for the same things.
Infrastructure, costs and scale
Reviewers want to know whether the plan in your pitch deck is technically realistic. Prepare simple, honest answers:
- Current monthly infrastructure and third-party service costs, broken down by vendor.
- How those costs grow with users, and any steep pricing tiers ahead.
- Known bottlenecks, and what you'd change if usage grew sharply.
- Uptime history and any significant incidents, with what was learned.
- Critical vendors you depend on, and what happens if one fails or raises prices.
Team and process
Investors are buying the team's ability to keep building. Show that knowledge isn't locked in one head.
- Who works on the product, in what role, and whether they're employees or contractors.
- How work is planned, reviewed and shipped.
- How code changes are reviewed before reaching production.
- What happens if your lead developer is unavailable for a month.
Prepare the story, not just the files
Put everything in a simple folder before you're asked: the architecture overview, ownership confirmations, security summary, cost breakdown and known-issues list. Then rehearse explaining it in plain language.
Be candid about weaknesses and pair each one with a plan. "We know this, here's when and how we'll fix it" reads very differently from a reviewer discovering it alone.
Deeraf runs this kind of review for founders before investors do. A Tech Check gives you the findings and a fixed-price plan, and On Call can sit beside you through the diligence calls.