Software Due Diligence Checklist for an AI-Built App

A software due diligence list arrives at a particular moment. Somebody who is not you, and not whoever helped you build the thing, is about to read your app, and they already have the list in front of them. You do not. That gap closes in an afternoon, because the lists are published and they mostly agree with each other.

A software due diligence checklist is what an outside reviewer asks you to produce or prove before money or a contract moves. Twelve items cover it, and for each one there is something you can settle in about a minute from a browser and an account you already own, though proving an export runs or a restore works takes longer than the glance. The last row is whether the on-screen features are real; the licence question, which nobody applies to AI-written code, gets its own section below.

Every item below was built by taking the areas the ranking due diligence checklists share, read on 26 August 2026, and asking of each one what a person who cannot read code can settle for themselves in about a minute, then setting the answer against what that same item turned out to be in a fixed set of 26 AI-built applications AxonBuild audited in June and July 2026. The licence wording comes from the licence texts and from GitHub’s own documentation on suggestions matching public code, fetched the same day. Nothing here was run against anybody’s app.

Software due diligence, and the three people who send you the list

Three people send this list, and they want the same twelve things for different reasons: an investor’s technical reviewer before a round closes, somebody buying the product or the company, and the vendor review team at a customer large enough to have one. Their forms differ. The underlying questions do not. None of them is shopping for due diligence software, which is the deal-management product category that shares the phrase and is bought by the reviewer’s side, not yours.

Here is the outside view, written in public by an IT provider describing their smaller customers’ AI-built apps:

We are seeing more of our smaller clients with too much time on their hands building base44 apps. They are happy with them … we want to backup the data(files) in base 44 besides the code and have not found a good solution.

The shape of that is the shape of most diligence findings. The apps work, the owners are happy, and the one thing nobody checked is what an outsider asks about first. Here it was the copy of the data, which is item three below.

The counts on this page come from a fixed set: 26 AI-built applications AxonBuild audited in June and July 2026, with a finding ledger kept over the 21 of them somebody other than the founder had built. Of the 26, 22 came out red, which means at least one confirmed critical finding, and none came out green. That is what 26 audited AI-built apps actually contained, sample and method published separately, and it is why a reviewer’s list reads as pessimistic. It is calibrated on codebases like these.

None of the three is doing legal or financial diligence. Company records, shareholdings, signed agreements and the books belong to lawyers and accountants, and the checklists that circulate under those names never reach your code. Somebody outside is going to read this app, and what a reviewer finds when the codebase came out of an AI builder is the wider question this list sits inside.

Read from the buyer’s chair, by somebody about to pay a stranger for a product, the same list gains two questions this one does not carry: is the money real, and can the thing change hands at all. Software product due diligence, meaning the examination of a product rather than a company, sits between the two.

The software due diligence checklist, item by item

The answer to “when do I run this” is the moment before you show the app to anybody who can say no. Somebody put that moment into a post title in August 2026, in a community of people launching side projects:

3 months solo on a study tool while doing my degree. Before I open the waitlist, w…

Before you open the waitlist. Before the term sheet, the vendor form, the acquirer’s reviewer getting access. Running the list afterwards still works, it is just more expensive, because by then every answer is also a signal about how you operate.

The table below is the due diligence software checklist itself, in the order somebody who cannot read code can walk it.

Several of these you can settle from a browser and an email address before anybody asks, and the ten checks worth running on your own app are a procedure with an order to follow rather than a list somebody else holds. What follows here is the other half: the items where owners of AI-built apps consistently answer wrong, and why the wrong answer is convincing.

Item 1 is where most preparation collapses, and the accounts are usually all there. The trouble is that “I have the login” and “the account is in my name” feel identical from the inside and are different facts to a reviewer, who asks for the billing owner rather than the password. It is also a list of its own: every account that has to sit in your name, and the sixty seconds it takes to confirm each.

Item 2 catches the builder platforms. A reviewer asking for the code expects a repository, and a working app inside a hosted builder is not automatically that. Whether the code can leave the tool at all has a different answer per platform, and the week somebody waits for a zip file is a bad time to find out yours.

Item 3 is the one the IT provider above was stuck on. The item is a restore rather than a backup, and the phrasing matters: a reviewer asks for the last date somebody restored data and read it back, not for a screenshot of a backup schedule. Whether a copy of the data has ever been restored has a date as its answer or no answer at all. Two apps in the audited set show why the reviewer bothers: in one a leftover maintenance route meant a single web request could empty the production database, and in the other changes were tried straight against the production database, because no separate environment existed. Both worked fine on the day.

Item 5 is the one AI builders get closest to and still miss. The right answer names a rule that runs on the server and applies to every request, whoever sends it. What stops one signed-in customer reading another’s rows is that server-side rule, and an app that filters the list inside the page instead stops working the moment somebody edits the page.

Item 8 inverts the stereotype. Across the 21 third-party apps in that finding ledger, 6 shipped a live secret. Three of those keys are still in the repository history and cannot be taken back out, and one was handed to every visitor’s browser. The other number matters as much: secrets was the highest-scoring pillar on average, 84 out of 100, across the same set. Most AI-built apps keep keys in the right place, and the failures concentrate in one file. Where a key is supposed to live is a short answer, and it turns item 8 into a check rather than a worry.

Item 11 is the one owners underestimate. Asking who could run this next month is asking whether the app is transferable, which a buyer, an investor and an enterprise customer each care about for their own reasons. What the next person needs on day one is short and unglamorous, and writing it down is most of the work.

Software due diligence questions you will be asked

The published checklists differ in emphasis and agree in substance. Two of the pages ranking for this query on 26 August 2026 were read in full for this article and are named but not linked here, because both companies sell diligence services and this site sells adjacent work. bdemerson.com, dated 21 July 2026, runs eight areas: architecture and scalability, code quality signals without reading every line, key-person risk in the engineering team, release discipline, cloud cost trajectory, security posture, licensing and IP, and data readiness. mascience.com runs twelve, addressed to what it calls the target executive team and deal team, from roadmap and leadership through architecture, infrastructure, product quality, ways of working, support and cybersecurity.

Both assume a company. The materials mascience.com says to prepare include architecture documents, IT documents, lifecycle documents and KPIs, reasonable of a business with an engineering department and odd to put to somebody who built a working product alone in three months.

Here is the same set in the form a one-person company gets asked it. The honest answer is frequently no, and no is fine when it arrives before the reviewer finds out alone.

Vendor reviews, the third asker, narrow this quickly to documents and controls: what a customer’s vendor review asks for when the database is Supabase is usually two specific requests rather than a general enquiry, and the same discipline applies when you are the supplier being asked.

If the person who built it is still reachable, the faster instrument is a short list of things to ask them to show you, and what comes back tells you as much about the builder as about the software.

Software architecture due diligence: the questions about how the app is put together

Software architecture due diligence sounds like the part a non-coder has to skip, and the four questions that matter here are all answerable from behaviour rather than from source code.

Is there a server between the customer and the database? In many AI-built apps the browser talks to the database directly, which is a supported design, and it moves the whole burden of deciding who may see what onto database rules. A reviewer wants to know which arrangement you have, because it changes where everything else has to live.

Where does the app decide what each customer may see? Two possible answers: on the server before the data is sent, or in the page after it arrives. Only one survives contact with somebody who can open developer tools.

What happens to that decision if somebody edits the page in their own browser? The same question again, asked in the way that produces an honest answer. Across the 21 third-party apps in the audit ledger, 10 trusted the browser to enforce something the server never re-checked. Close to half the set, and invisible from the working app.

What falls over first at a hundred users? The reviewer wants a named component rather than a capacity estimate: the database connection limit, the model provider’s rate limit, the single server, the file storage. A reviewer accepts “I do not know” far more readily than a confident wrong answer.

One architecture pattern here is found by reviewers and never by owners, because it looks identical to working code. Controls built and then never connected recur across the audited apps: an empty rate-limit bucket sitting beside the one route that never calls it, a crash handler written and never switched on, a written safety rulebook that no part of the running product reads. The file is in the repository, it reads well, and it never executes. The only thing separating a wired control from an unwired one is running the app and watching the control fire, which is why a reviewer asks you to demonstrate rather than describe.

Open source software due diligence: licences in code you did not write

Every published checklist carries a licensing item, and every one assumes a company with a policy. The clearest statement of the standard version is a Morgan Lewis post by Katrina Slack and Vito Petretti, dated 5 June 2026, setting out six areas of inquiry in open-source diligence: whether the company maintains an open-source software policy, trains employees on appropriate use, contributes to open-source projects, monitors and tracks usage, conducts regular scans, and maintains an approval process for copyleft-licensed software.

Read that as the owner of an app an assistant wrote most of. No policy, no training programme, nobody running scans, no approval process. You also have an exposure none of the six is aimed at: an assistant can reproduce code that already exists somewhere public, and neither of you noticed. As of 26 August 2026, the Morgan Lewis post does not mention AI-generated code or AI coding assistants anywhere.

A snippet reproduced from a repository with no licence file is under exclusive copyright by default, and nothing about a machine typing it changes that.

The mechanism is documented by the tool vendors themselves. GitHub’s page on managing Copilot policies describes a personal setting to allow or block code suggestions that match publicly available code, and states that when blocking is selected, “GitHub Copilot checks code suggestions with their surrounding code of about 150 characters against public code on GitHub”. A member of an organization on GitHub Enterprise Cloud assigned a seat through that organization cannot change the setting personally, because it is inherited.

GitHub’s code referencing documentation covers what happens when a match is found rather than blocked. Code referencing “identifies and attributes code suggestions by linking them to their original public sources”, and the log entry “includes the URLs of files containing matching code, and the name of the license that applies to that code, if any was found”. The same page states that “typically, matches to public code occur in less than one percent of Copilot suggestions”, with two limits alongside it: “Code you have written, and Copilot suggestions you have altered, are not checked for matches to public code”, and “Code in private GitHub repositories, or code outside of GitHub, is not included in the search process”. A low match rate on unmodified suggestions inside one vendor’s search space is a narrower claim than a clean codebase.

Reproduced code arrives carrying whatever licence it had, which is what makes this a diligence item. The condition labels below come from the Choose a License project, read on 26 August 2026, and the SPDX License List, “a list of commonly found licenses and exceptions used in free and open or collaborative software, data, hardware, or documentation”, at version 3.28.0, released 2026-02-20. The opensource.org licence pages returned an HTTP 403 to an automated read the same day, so nothing here is sourced from them.

The AGPL row is the one people get wrong, so read it in the licence’s own words. GNU’s published text of the AGPL, version 3 dated 19 November 2007, says in section 13 that “your modified version must prominently offer all users interacting with it remotely through a computer network … an opportunity to receive the Corresponding Source of your version”. A hosted product users reach over the internet is the situation that sentence describes.

Three checks settle this item without reading code. Open the dependency file item 9 uses and read the package names; every one is a licence you have accepted. Find whether the public-code setting on the assistant that wrote your app was allow or block, and if the app came out of a hosted builder rather than an editor you control, record that you cannot determine it. Then ask what decides whether the AGPL row applies: do customers reach this app over a network. For a web product that is yes, whether or not anybody thought about licences while building it.

Of the pages ranking for this query on 26 August 2026 that were read in full here, exactly one connects the licensing item to code a machine wrote: bdemerson.com, on 21 July 2026, which says to ask about AI-generated code provenance and policy, because buyers’ counsel has started asking whether the codebase contains code nobody can claim authorship of. One clause is the whole of the published coverage. What the assistant’s public-code setting does and does not check is the mechanism underneath it.

Three failures the published checklists have no row for

The finding ledger recorded 958 confirmed findings over the 21 third-party apps in that study, about 46 apiece, and 58 of the 958 were critical. Confirmed there means somebody went looking for a reason each finding was wrong and did not find one. Read those the way a reviewer does: 46 findings per app is not a verdict, and the 58 is the group that moves a price. An owner who treats a long list as a failing grade spends their preparation week on the wrong nine items.

Three of the patterns underneath that number sit beneath the twelve items above and rarely reach a published checklist at all.

Open doors and open taps. Across the same 21 apps, 11 ran an endpoint that did privileged work for a caller who was never signed in, and 13 put no ceiling on the endpoint that cost them the most per call. Neither is a defect in the ordinary sense. The app works, the feature works, and the exposure appears when somebody finds the address and calls it in a loop.

AI features are their own surface. Of the 14 third-party apps carrying an AI feature, 8 had a live prompt-injection path, meaning a stranger’s typing could become part of what the model was told to do. One was a compliance tool a visitor could talk into declaring things compliant, which belongs to a family the corpus turned up more than once: features presented as real that are not. Another app shipped fabricated results as product data alongside timestamps showing the wrong time. Item 12 is on the list because a reviewer picks the feature your landing page leads with and follows one record through it, which costs them four minutes.

Personal data in the wrong place, which vendor reviews ask about directly, turned up in at least 5 of the 21 apps in the ledger. The count says at least because that ledger keeps the notable findings rather than all 958, so the figure is a floor.

When an item fails, and what the reviewer does with it

Failing an item is the normal outcome, including for companies with engineering departments. Of the 26 apps in the audited set, none came out green, and the four that avoided a red rating still carried findings. A reviewer who receives twelve clean answers from a solo-built product usually concludes that the answers are optimistic rather than that the app is exceptional.

A long list of items is not a verdict, and the reviewer is reading it for the two that change the price.

So the work splits three ways, and the split is more useful than the list.

Fix before the review anything cheap and visible from outside: the unauthenticated route, the missing rate limit, the key in the browser, the account still in somebody else’s name. These are hours, and every one found by the reviewer instead of by you costs more than it should.

Disclose instead of fixing anything structural. No separate environment, no automated tests, one person who knows how it works. A permission rule that lives only in the page is the exception: that is an open exposure, so restrict the route or fix it first and disclose what remains. Say what you would do about it and roughly when. A software technical due diligence checklist has no column for “the owner told us first”, but it changes how the rest of the answers are read.

Leave alone anything that is a preference rather than a risk. Reviewers have opinions about frameworks and folder layouts, and those do not change a price.

Every item above is answerable from behaviour, accounts and documentation, and none of it substitutes for somebody reading the code. What happens once somebody does open the code, stage by stage, and what access that takes, starts where this list stops. The twelve are worth walking first because you can answer them without buying anybody’s time, and answering them changes what the reading is for.

Common questions about software due diligence

What is a software due diligence report, and who writes it?

A due diligence report is the document written by the technical reviewer the buyer, the investor or the customer hired, addressed to whoever hired them. It records what they asked for, what they received and how they graded it, and you may never see the full version. AxonBuild does not produce one. Anyone offering to write your due diligence report is offering to write the other side’s document, which the other side will not accept.

Is there a software due diligence report template or an excel checklist I can download?

No, and there is nothing to download here. The format belongs to whoever runs the review, so a software due diligence template you fill in ahead of time will not match the spreadsheet that arrives. The table above is the same content in the order you can walk it, which is the part that transfers. Copy the three columns into whatever you already use; a software due diligence checklist in excel is a fine place to keep your answers, it is just not something anybody can hand you in advance.

Who does software due diligence work?

Three classes of firm. Specialist technical diligence consultancies work for investors and acquirers. Software composition analysis vendors sell licence and dependency scanning as a product. General advisory and M&A firms fold a technical section into a wider process. All three appear on this query’s search results, and none is aimed at a founder preparing to be examined. Who sells the reading, and what they charge for it is a separate market. AxonBuild does not sell diligence preparation and does not produce that document. What it does is change the app. If the review turns up something in the code that needs fixing, show Bilal on a free 20-minute video call, and he will quote the change after checking the app. You pay after you see it working.

How long does software due diligence usually take?

The pace is set by how fast you answer, not by how big the app is. Neither of the two checklist pages read in full for this article says how long a review takes; the one duration either of them gives is mascience.com’s single day for working out which materials are missing. Neither is written for an app this size. The shape is predictable: a first request arriving as a list, a gap while you assemble answers, a call with whoever built it, and follow-ups. What stretches the calendar is the items you have to go and discover, which is the argument for walking the twelve first.

Will a reviewer hold it against me that AI wrote the code?

Not by itself, and saying so is not reassurance. The build method does not get recorded; the absences do. What being AI-built predicts is which parts of the twelve are empty rather than wrong: the recording of errors, the separate environment, the rate limits, the dependency updates. A reviewer who knows the pattern checks those first and reads a good answer there as a strong signal, because it means somebody went looking.

What if my app lives inside a builder and there is no repository to hand over?

Then item 2 becomes the first question rather than the second, and what the reviewer asks changes from “show me the code” to “show me what happens if this platform goes away”. Base44, Lovable and the other hosted builders each publish their own export path and the answers differ. Run yours before you are asked, keep the output somewhere you control, and be able to say what came out and what did not. A due diligence checklist for a software project living inside a builder is the same twelve items with more of the answers written by the platform.

Do I have to fix every item before the review?

No, and trying to is the common mistake. Fix what is cheap and externally visible, disclose what is structural, leave the preferences alone. Twelve items with three known gaps you named yourself reads better than twelve where the reviewer finds two you did not mention. The exception is item 1: an account not in your name is worth resolving before any conversation, because it is the only item that can stop a deal on its own.

Is this the same as the security questionnaire a big customer sent me?

Related, and a different job. A spreadsheet of questions sent by one large customer is the same subject read from the customer’s side, and what you can answer honestly today and what you have to change first is a different sequence from this one. Diligence is somebody deciding whether to take a position in your business; a vendor questionnaire is somebody deciding whether to buy from you, and it arrives with named controls and its own vocabulary. When the request is specifically for a named security assessment rather than a general review, that is a narrower question with its own answer.