Technical due diligence rarely kills a round. It re-prices one, and it does so at the worst possible moment: after the term sheet exists, when the fund has already decided it wants in and you have already stopped shopping. Reviewers examine code quality, architecture limits, security basics, dependency licences, CI/CD and backups, test placement, bus-factor risk and IP assignment, and every gap found at that stage is a discount request you cannot easily refuse.
So the goal of founder-side preparation is not a clean bill of health. It is the absence of surprises. A reviewer who finds three known issues that you have already documented, priced and scheduled is a very different conversation from a reviewer who finds three issues you did not know about.
Diligence happens in a window where your options have collapsed. You have signalled commitment, other conversations have gone quiet, and the round has a date attached to it. A finding that would have cost two engineer-weeks to fix in March becomes a valuation argument in June.
The asymmetry is worse than it looks, because the reviewer is not obliged to be fair. They write what they find, in the language of risk, to an audience that reads risk memos for a living. "No automated tests around billing" is a true sentence that lands very differently in a diligence report than in your own backlog.
Code quality and maintainability. Not style. Reviewers look for signals that a new engineer could be productive: consistent structure, functions that do one thing, and a name-to-behaviour match. The recurring red flag is a single file of several thousand lines that everything routes through, because it tells the reviewer that change is expensive and risky.
Architecture and scalability. The question is rarely "can this handle a million users". It is "what breaks first, and does the team know". A reviewer who asks about your largest table, your slowest endpoint and your background job queue is testing whether anyone has looked.
Security basics. Authentication and authorisation logic, secrets handling, input validation on anything user-supplied, and how personal data is stored and deleted. In practice the recurring failures are secrets committed to git history, authorisation checked at the UI layer but not the API layer, and an admin endpoint that was never meant to ship. The specific failures that recur in AI-assisted code are listed in what breaks first in AI-built apps.
Dependency and open-source licence risk. Two separate questions. Are your dependencies patched, and are you legally allowed to ship them? A copyleft licence inside a proprietary codebase is one of the few technical findings that can genuinely delay a close, because fixing it means removing or replacing code rather than writing a ticket.
Infrastructure and CI/CD. Can you deploy without a specific person present? Is there a rollback? Do you have backups, and has anyone restored from one? An untested backup is not a backup, and reviewers know to ask.
Test coverage. The percentage matters less than the placement. Ninety percent coverage of your utility functions and zero around payments reads worse than a modest number concentrated on the paths where money and data move.
Key-person and bus-factor risk. If one engineer is the only person who understands the payment integration, that is a finding. Investors are underwriting a team's ability to keep shipping, and concentration of knowledge is a direct threat to that.
Engineering process. Code review, branching, issue tracking, how incidents get handled. Reviewers use process as a proxy for whether the team can absorb the headcount the round is meant to fund.
IP ownership and contractor hygiene. This is a legal finding with a technical trail. Every contributor in your git history should have a signed agreement assigning the work. Freelancers, agencies, an early co-founder who left, a friend who helped over a weekend: if the paperwork is missing, the commit log will show it.
Reviewers have started asking where the code came from, and the question is getting sharper. The concern is not that you used an assistant. It is that AI-assisted code tends to arrive faster than the review capacity around it, so the failure pattern is volume without ownership: large diffs that no human read closely, duplicated logic across files that should share it, and dependencies added because they appeared in a suggestion rather than because someone chose them.
The related worry is provenance of the output itself, and whether generated code carries licence obligations. Nobody has a settled answer yet. What you can do is have a policy, apply it, and be able to describe it: what tools the team uses, what gets reviewed by a human, and what is never generated (auth, payments, anything touching personal data is a reasonable line).
Work through this in the weeks before you start raising, not during.
Two firms can quote similar numbers for very different work. Interview-led diligence talks to your team, reads your documentation, and forms a judgement about process and capability. Code-led diligence reads the repository. Both are legitimate. They surface different findings, and interview-led work will not find the secret in your git history.
The published market runs from under $100 for an async written opinion to five figures for diligence-grade work. We keep the current figures in how much a code audit costs and in our fixed-price audit comparison.
Read those as a scale of depth, not a scale of quality. A 72-hour engagement with a line-count cap is a scan, and a good one is worth having. A two-week engagement is a different instrument. Ask any provider one question: how many hours of senior engineering time are in this, and how much of it is spent reading code? The answer explains the price better than the deliverable list does. What belongs in the report itself is a separate test, and the one most buyers skip. We wrote up how diligence-style review differs from a code audit in technical due diligence versus a code audit.
Our Tech Audit is $4,999, code-led and founder-side, scoped to one primary codebase and its deployment configuration, and run before you raise so findings reach you rather than a partner meeting.
It is not independent diligence for a fund. If an investor asks for a technical reviewer, we are the wrong choice: we are engaged by you, we report to you, and a reviewer with that relationship cannot give a fund the independence it is paying for. Firms whose entire business is investor-side diligence exist for that job, and hiring one is the correct answer.
The two are complements. Founder-side preparation is what you do so that investor-side diligence finds nothing you have not already priced.
How long before a round should we prepare?
Six to eight weeks is comfortable. It leaves time to fix what is cheap, document what is not, and chase missing contractor paperwork, which is the item most likely to take longer than expected.
What access will the reviewer want?
Typically read access to the repository, your CI configuration, an architecture overview, and time with one or two engineers. Some will want a cloud console walkthrough. Prepare a read-only path for each rather than improvising access under time pressure.
Will AI-generated code count against us?
Not by itself. What counts against you is code nobody on the team can explain. If your engineers can walk a reviewer through any file and say why it is written that way, the origin of the first draft stops being interesting.
Should we fix everything before diligence?
No. Fix what is cheap or dangerous, document the rest with a cost and a reason. A known-issues register signals engineering judgement, and it removes the reviewer's ability to present a finding as a discovery.
Can you be the independent reviewer for our investor?
No. We work for founders, which disqualifies us from that role. We will happily hand over our findings so the fund's reviewer can start from something rather than nothing.
What if a real problem surfaces during the round?
Get it in front of the investor before the reviewer does, with a cost and a plan attached. Self-reported problems get treated as roadmap. Discovered problems get treated as risk, and risk moves price. If the finding is severe enough that fixing it means starting over, that is a separate decision, and we have written about when an audit points at a rebuild.
Written by
Founder & CEO
Founder & CEO of Robust Devs. Leads delivery and works directly with every client, across AI marketing, healthtech, and fintech builds, and has done since 2019.
AI-built apps break first at authorisation, database access rules, leaked secrets and unverified payment webhooks, not at the feature they were built to demo. They fail at the thing nobody demonstrate
A code audit report earns its fee when it contains four things: an executive summary the person paying can act on, findings ranked by severity that cite specific files and lines, an architecture asses
A code audit for an early-stage startup costs somewhere between $49 and $15,000. That spread is not vendor margin. It is how many hours a senior engineer spends inside your system, and whether a perso
Tactical writing for founders building AI products. Browse the archive for more field notes like this one.
Browse all articlesIf you are building in this space, book a call or get in touch.
Schedule a meeting