The offer arrives with a condition attached to it. Before the money moves, their technical person wants the repository, the deploy configuration, and an hour with whoever built the thing. That is startup technical due diligence, and it is usually the first time your app gets read by somebody with no reason to be generous about what they find.
Technical due diligence is the review an investor, an acquirer or a large customer runs before money moves: someone technical reads the code, the infrastructure and the way you work, then tells whoever hired them what they found. One published version of the process runs to six stages, and the last one belongs to the reviewer.
One owner, weighing publicly whether an AI-built product could carry a real business, listed the doubt in the order it actually arrives in:
I’m skeptical about the challenges around security, scalability, reliability, and moving from a prototype to a real business.
That last clause is the whole event. The three words in front of it are the ones the reviewer will use in their notes, and the reason anybody is reading at all is the clause on the end.
Five of the pages Google returns for this question were read on 26 August 2026 and checked for one thing, which is whether any of them says what a reviewer meets in code a machine wrote, and none of them does. What follows about what gets found is AxonBuild’s fixed study of 26 AI-built applications audited in June and July 2026, read back the other way round: each thing a reviewer asks for, set against how often it was already missing. Nobody’s diligence was sat in on, no reader’s app was examined, and no tool was run for this page.
Those five pages are named here without links, because four of the five sell due diligence, code scanning or security services and one is a project-tools vendor publishing an explainer: techcxo.com/what-is-technical-due-diligence-when-and-how-to-do-it-right/, blog.codacy.com/technical-due-diligence-for-startups, nulab.com/learn/strategy-and-planning/technical-due-diligence/, vaultinum.com/blog/technical-due-diligence-for-startups-and-emerging-companies and snyk.io/articles/what-is-technical-due-diligence-tdd/.
What is technical due diligence, and who actually turns up?
Technical due diligence is somebody else’s technical person reading your product before their side commits money. On a startup it usually covers the code, the infrastructure it runs on, the people who maintain it, and whether the roadmap is buildable. It is commissioned by the party with money at risk, and it is written for them.
Four kinds of people turn up, and they behave differently. An investor’s technical reviewer, often a partner or an adviser doing this alongside three other deals, is looking for reasons the thesis breaks. An acquirer’s reviewer is looking for what they will own on Monday and who has to fix it. An advisory firm hired for the deal works to a fixed method and produces the fullest write-up, which is why firms selling software technical due diligence advertise pillar counts and item counts. And sometimes it is one contractor with a list of questions, hired for a day, who will read the parts they know.
When it happens is more predictable than who does it. The published guides agree on the moments: before a funding round, before a merger or acquisition, before a serious partnership, ahead of a major launch, and during a change big enough that somebody wants a second opinion first. Codacy’s guide, read on 26 August 2026, lists exactly those five moments; every other page read that day names some subset of the same list.
The due diligence a lawyer or an accountant runs on a startup covers incorporation, the cap table, the contracts and the accounts, which is a different job done by different people, and the checklists people search for under that name are not about your code.
Two other things share the name and are worth ruling out quickly. There is a whole property industry that calls a building survey technical due diligence, which is why a search for the phrase can return a page about roofs and drainage. And a spreadsheet that arrives from a big customer asking about your controls is a different envelope, because you are the one filling it in rather than the one being read.
For a startup, software tech due diligence rarely means what the phrase means at enterprise scale. Nobody is auditing a hundred repositories. Somebody is reading one product, quickly, with a specific decision in mind, and forming a view about whether the thing can survive being owned by someone else.
The due diligence process for software, seen from the side being read
The due diligence process for software runs in a sequence that every published version broadly agrees on. Nulab’s guide, read on 26 August 2026, names six stages in order: preparation, formal commencement, examination of documentation, scheduling a meeting, discussion of all issues, and report writing. That sequence is written from the reviewer’s chair. Turned around, it becomes a list of six moments where you either have something to hand over or you do not.
One warning about searching for this. Type the process into Google and page one fills with deal-management software: platforms for tracking requests, storing documents and chasing answers across a transaction. Due diligence in software projects and software you buy to run due diligence are two unrelated things wearing one phrase, and the tools are bought by the other side.
| Step | What the other side does | What they ask you for | Where an AI-built app usually stalls |
|---|---|---|---|
| Preparation | Decides what the review covers and hires whoever is doing it | A short description of what the product is built on and who built it | Nobody can name the stack precisely, because the builder tool chose most of it and never announced the choice |
| Commencement | Sets the window, the contact and the access | Read access to the repository and a working URL for the running product | Access sits inside one personal account, and granting it turns out to mean granting more than reading |
| Documentation | Reads whatever written material exists before touching code | Architecture notes, the deploy configuration, a record of past incidents | There is no written material, because nothing was ever written down for anybody |
| The meeting | Books an hour with whoever built the product | The person who can explain why a decision was made | The person who made the decisions is a chat log, and nobody kept it |
| Follow-ups | Puts specific questions back to you about what the first three turned up | Evidence for one narrow thing at a time | You cannot show the last error a customer hit, because nothing recorded it |
| Their write-up | Summarises for whoever hired them | Nothing further | Out of your hands entirely, which is the honest thing to know about this step |
Due diligence in software projects is often described as an assessment of quality. From this side it behaves more like an inventory. The reviewer is establishing what exists, what can be shown on demand, and what only exists as an assurance from you. Questions about how the software was developed land the same way. The question underneath each one is whether you can produce the thing that proves your answer, and quality is what the reviewer concludes afterwards.
The step that decides the tone of everything after it is the documentation one. A reviewer who receives a deploy configuration, a schema and a note about the two outages you had in June starts from a position of reading a maintained product. A reviewer who receives nothing starts by inferring, and inference is slower, less generous, and lands in the write-up as uncertainty rather than as a finding.
What they will send you, and what it is really asking for
The request usually arrives as one message with four things in it, and the four have different weights.
There is a list of documents. Architecture, infrastructure, security practice, roadmap, sometimes licensing. In AxonBuild’s experience most owners of AI-built products can supply only part of it, and the honest reply to the rest is that it does not exist, which is a better answer than a document written the night before.
There is an access question, and it is the one that generates the most anxiety. What is being asked for is read access to the code and a working URL, not your production database and not your live keys.
There is a call with whoever built it. On a team that call is easy. When a tool wrote most of the code, the person on the call is answering for decisions that have no recorded author, and the useful preparation is being able to say so without apologising for it.
And there are follow-ups, which is where the actual reading shows. A reviewer who comes back with two specific questions about your payment path has read the payment path. A reviewer who comes back with a generic list may have run a scanner and little else.
The list itself, line by line, with what each line is really asking and how to walk it if you cannot read code, is written out separately.
What lands at the end belongs to them. Of the five pages read on 26 August 2026, two describe the process finishing in a written document: Nulab’s stage list ends in report writing, and Snyk’s article describes “a detailed report containing all of the findings of document screening, code review, as well as meetings with the investors, product owners, and technical leaders”. Codacy’s guide, Vaultinum’s page and TechCXO’s page describe the work without naming a written output, and TechCXO’s page tells the reader to maintain detailed records of all findings without naming a document at the end. You may never see any of it.
What a technical reviewer finds in an AI-built codebase
Every count below comes from AxonBuild’s fixed study of 26 AI-built applications audited in June and July 2026, in three cohorts of 11, 10 and 5. The cohort was fixed at the time and is never resized, findings were traced to a file and a line and checked adversarially rather than pattern matched, and the fixed 26-app study, its denominators, and how each figure was produced is published in full elsewhere. The rows run from the things you can still change this week to the one you cannot change at all.
| What they ask for | What it is really testing | How often it was already missing in the study | What you can do about it before they look |
|---|---|---|---|
| Tests, and what runs before a change ships | Whether anything except a customer would notice a change breaking something that used to work | At least 18 of the 21 third-party apps in the study’s findings ledger had no working test anywhere, 17 of them with none at all; the ledger keeps notable findings, so its counts are lower bounds | Write three tests: signup, payment, and the one screen that shows a customer their own data. Three real tests read better than a suite that asserts nothing |
| Framework and dependency versions | Whether anybody has updated the product since the day it was generated | 9 of the 26 applications ran a framework version with a publicly known, reachable remote code execution or authentication bypass, counted across all 26 | Update and read the version numbers that changed. In the study the repair was often a one-line version bump, which is the cheapest repair anywhere in this table |
| Whether one customer can reach another customer’s data | Whether the code checks who owns a row, not only whether somebody is signed in | Authorization averaged 42.1 out of 100 across the 14 third-party applications where the area applied; areas that do not apply are excluded rather than scored as zero | Sign up twice, leave one record in the newer account, and then try to open that record while signed in as the older one. If your database has row rules, what a row-level rule does and does not settle is the part people get wrong |
| The AI feature, and who pays for it | Whether a stranger can spend your model budget without an account | AI and LLM native risk averaged 38.4 out of 100 across the 14 third-party applications that had an AI surface | Put the AI endpoint behind a sign-in and a per-account limit, then check what an account with no payment method can still spend |
| What the model is allowed to treat as an instruction | Whether text a stranger typed can become a command your product obeys | 8 of the 14 third-party applications with an AI surface allowed untrusted text to reach the model as an instruction | Name the one place a user’s words enter your prompt, and say out loud what that text could ask the product to do |
| Where the keys are kept | The stereotype about AI-built code, tested directly | Secrets and credentials came out best of the twelve areas assessed, averaging 84.4 out of 100 across the 21 third-party applications | Search your commit history once for a key you have since replaced. When this one fails it fails badly, because history keeps what you deleted |
| How many problems there are in total | Whether your count is ordinary or alarming | 958 confirmed findings across the 21 third-party applications, about 46 per application, of which 58 were critical | Sort the list you already have by whether a stranger can reach the thing, and stop sorting by how annoying it is |
| How the product compares to others they have read | Whether your gaps are unusual or the middle of the distribution | Scores ran 29 to 81 out of 100 across all 26, mean 52.1 and median 51, with bands of 22 red, 4 amber and none green | Nothing. This row is theirs. Knowing where the middle sits is worth more to you than to them |
Read down the third column and the pattern is absence. Very little of what a reviewer meets in an AI-built product is wrong code; most of it is code that was never written at all, and the likeliest reason is that nobody asked for it. A tool builds the feature you described and stops there, so the test, the alert, the limit and the ownership check you never mentioned do not exist.
That distinction changes how a reviewer writes it up, and it is worth understanding before you read anybody’s notes about your product. A defect is a thing that is wrong, and it gets a severity. An absence is a thing that is not there, and it gets a judgement about the team. Two products with the same score can be written up very differently depending on whether the reviewer decided the gaps mean nobody has got to it yet or nobody knows it should exist.
Whether a list that long is ordinary for a young product or a sign the foundation is wrong is a question about counts rather than about diligence, and it has its own answer.
The row in that table nobody predicts is the one about keys. Secrets is the area people expect AI-built products to fail at, and across those 21 applications it was the strongest of the twelve. The failures are further in, in the parts that have no screen: what happens when something breaks, what happens on the second account, what happens when the bill arrives.
What you can fix before they look, in order
The order below runs from the items that usually cost least to those that cost most, though your own app decides, and each item settles exactly one thing a reviewer would otherwise have to guess at. Nothing here makes a product pass anything, and no seller can promise that either. What it does is remove the specific gaps that make a reviewer write “could not determine” where an answer should be.
- 01 Update your framework and read the version numbers that changed. One afternoon, and it closes the row that was reachable in 9 of the 26 applications in the study. If the update breaks something, that is worth knowing this week rather than during the review.
- 02 Turn on error recording and make one error on purpose. The reviewer will ask where a customer's failure goes. Having a screen with a real recorded error on it answers that question in four seconds, and having nothing answers it differently.
- 03 Open a second account and see whether it can reach anything belonging to the first. This is the single check whose failure changes a reviewer's opinion of everything else, because it is the one that means the code checks whether you are signed in but not whether the thing is yours.
- 04 Write down what the product is built on. Framework, database, hosting, payment provider, the AI model and where the key lives, and who or what wrote the code. One page. It answers the first three questions of the documentation stage and it costs you an hour.
- 05 Put a limit on whatever costs money per request. A sign-in in front of the AI endpoint and a cap per account. In the study this was the area that scored 38.4 out of 100 across the 14 applications with an AI surface, and a limit is a smaller change than it sounds.
- 06 Write three tests that would fail if the product broke. Signup, payment, and one screen showing a customer their own rows. Three is enough to change the answer to the tests question from no to yes, honestly.
- 07 List what you are not going to fix, in your own words, before anybody asks. This is the item people skip and it is worth more than the four above it.
Several of these you can settle yourself first, and the short browser procedure for looking without touching the code is the cheapest hour on this page. If somebody else built this for you and can still be reached, the same ground is covered by asking them for it and grading what comes back, which is cheaper than any preparation you do alone.
Now the honest half. You are not closing all seven. Whichever ones are left, volunteer them. A reviewer who is told “there are no tests on the admin screens and I know it” reads that as a person who understands their own product. The same reviewer who finds it themselves in hour three has learned two things: the gap, and that you either did not know or did not say. The second one is the finding that follows you into the write-up, because it is a statement about you rather than about the code, and no version bump repairs it.
Does being built with AI count against you?
Being built with AI counts against you only where it left a gap. The 26-application study records what code does and does not do, never which tool typed it, and the gaps clustered in one place: the parts of a product that have no screen, because nobody thinks to ask for what they cannot see.
A thread in r/AppBuilding on 22 July 2026 was titled Are they BSing us non-techies?, which is the suspicion running under this whole subject, pointed in the direction the reader usually points it. During diligence it points the other way, and the question becomes whether you are the one being read as unserious.
So the build method earns its place as a prediction rather than as a verdict. It tells a reviewer where to look first, and it tells you the same thing for free: complete where there is something to click, thin behind it. That is more useful than a general worry about quality, because it names the shelf the gaps are sitting on.
What it changes for you is the shape of your answers. On a hand-built product, the reviewer asks why a decision was made and gets a reason. On yours, some decisions have no author. The way through that is to answer for the product as it is now rather than for how it came to be: this is what it does, this is what it does not have, this is what I have decided about that. Owners who try to reconstruct an intention they never had sound evasive, and it is the only part of this where an AI-built product is genuinely at a disadvantage.
One owner who built an early version on a no-code builder, then raised money on it, went straight out looking for somebody to tidy up how the thing was run. That is the ordinary sequence, and it is worth noticing that the money arrived first.
What your own AI assistant can reach inside your business is a separate inventory from the one a reviewer takes of your app, and it is worth taking before anybody asks for it.
The questions preparation cannot settle
Most of what is above is preparation you can do without reading code; updating frameworks, instrumenting errors, writing tests and adding limits are engineering changes that need somebody qualified to make and check them. At some point that runs out, and what is left can only be settled by a person opening the files.
What a reviewer actually does once the access works, and what access they need to do it, runs to a sequence of its own and is set out step by step elsewhere. If you want the same thing done to your product first, on your terms, who sells this reading and what they charge covers the market and the prices, and there is a wide spread between what different sellers mean by the word review.
If what raised the question is what the app is carrying rather than who is about to read it, whether an app like yours needs an outside security review at all is the narrower decision, and it is answered on its own page.
State the limit plainly, because sellers will not. What a reading produces is a picture of the code as it stands this week. Nobody becomes ready for diligence by buying one, nothing gets certified, and the picture stops matching the product after your next three prompts. What it gives you is the ability to answer the follow-up questions with facts instead of impressions, which is the difference between a review that goes quiet for a week and one that comes back with two narrow questions you can answer the same day.
The one thing preparation genuinely buys you is time. Every question you can answer immediately is a day the reviewer does not spend inferring, and inference is where a product gets written up as risky for no better reason than that nobody could tell.
Common questions about technical due diligence
What is technical due diligence?
Technical due diligence is an assessment of a company’s technology commissioned by somebody about to put money in or take the company over. Someone technical reads the code, the infrastructure, the security practice and the team’s ability to keep building, then reports to whoever hired them. On a startup it usually covers one product rather than a portfolio, and the published guides describe stages rather than durations.
Is technical due diligence the same as the due diligence my lawyer is doing?
No. Your lawyer and your accountant are working on incorporation, the cap table, the contracts and the accounts, and none of that touches the code. The two reviews run in parallel on the same deal, they are commissioned by the same party, and they almost never talk to each other. If your investor has asked for both, expect two separate requests from two separate people, and expect the technical one to arrive later and move faster.
Who writes the due diligence report, and will you write mine?
The report is written by the buyer’s or the investor’s technical reviewer, it is their document and not yours, and AxonBuild does not produce one. You may be shown a summary, or you may only ever hear the conclusion in a call. What AxonBuild does instead is change the app: if the review names something in the code that needs fixing, Bilal checks it, quotes the change, builds and tests it, and shows you it working, which is a different thing from a document about your app.
Can I hire someone to prepare me for technical due diligence?
Yes, and three classes of provider do it: advisory firms that also sell diligence to the other side, development shops offering a pre-review pass, and independent reviewers working alone. Prices vary widely enough that comparison matters more than the label on the service, and what to ask for before you buy an outside read covers the questions worth asking of any of them. Be wary of anyone who promises you will pass.
Do I need due diligence software?
Due diligence software is a category of deal-management tools the other side uses to collect and track answers, so the reviewer’s firm buys it and you do not need to. Searching for it returns transaction platforms and document trackers built for buyers and their lawyers. If your reviewer asks you to upload things into a system, you will be given access to theirs.
Do investors run technical due diligence on a pre-seed startup?
Rarely in full. The pages read on 26 August 2026 place technical due diligence around funding rounds, acquisitions, partnerships and major launches, and at the earliest stages it usually shrinks to a conversation and a look at the running product. It gets serious when the cheque gets serious, and it also arrives early and in full when your first enterprise customer is bigger than you are.
Will they be able to tell the app was built with AI tools?
Usually, and early. The signals are ordinary: generated file layouts, comments that describe the line beneath them, two names for the same idea, and features that exist in the code but nothing calls. None of that is a finding on its own. What follows from it is where the reviewer looks next, because the study’s pattern is that generated products are complete where there is a screen and empty where there is not.
How long does technical due diligence take?
The published guides describe stages rather than durations, so any number quoted before somebody has seen your app is a guess. What actually sets the pace is how long access takes to arrange and how many questions you can answer immediately. The reading itself is rarely the slow part; waiting for a repository invitation and a call with the builder usually is.
What happens if they find something serious?
Usually a condition rather than a collapse. The common outcomes are a repair agreed before the money moves, a holdback against fixing it, a lower number, or a delay while somebody checks how far it goes. Deals do die on technical findings, and in AxonBuild’s experience answers that keep changing hurt more than one severe problem does. Fix what you can, say what you have not fixed, and let the finding be about the code.
Built it with AI. Can’t get the last part right?
That’s the normal state of an AI-built app, and it’s fixable. I trace what the app actually does, explain what needs changing, and build it if you want me to.
Talk about your app → 
Free 20-minute video call with Bilal.