Published due diligence checklists for buying a business are mostly legal and financial; FindLaw’s has no code, repository or hosting check. For a SaaS, code is much of the deal: the buyer’s reviewer clones the GitHub repository, runs the tests and reads the license report. Due diligence of code when selling a business is being ready for that read.
What due diligence of code when selling a business actually is
Due diligence of code when selling a business is a technical reviewer, hired by the buyer, reading the repository and how the app runs to price rework and find surprises. The reviewer asks for a predictable set of things, and a seller who has them ready sets the terms of the conversation.
It is the exit version of what a developer handoff looks like. The same repository, accounts and documents change hands, except that a stranger reads them first and tells the buyer what they are worth.
When a buyer wants to review code before buying, give read-only access with an end date. In a GitHub organization, add the reviewer as an outside collaborator, a person who is not a member of your organization but has access to one or more of its repositories, and give them the Read role, the first of the organization repository roles, which GitHub lists from least access to most. GitHub describes Read as “Recommended for non-code contributors who want to view or discuss your project”, which is the reviewer’s whole job. GitHub’s outside collaborator docs mention no expiry for that access, so my working rule is to agree an end date in writing and remove the reviewer on that day.
Two conditions come with it, both in GitHub’s words. On a repository owned by a personal account, “In a private repository, repository owners can only grant write access to collaborators”, so a founder whose code sits in a personal account moves it into an organization first, which is GitHub’s own suggestion for finer access. And “Unless you are on a free plan, adding an outside collaborator to a private repository will use one of your paid licenses.”
Removing the reviewer deletes their forks of a private repository, but “the person will still retain any local clones of your repository.” So the end date limits access, not copies. What a buyer may do with a copy belongs in the sale contract, and that is a question for your lawyer.
To prepare for technical DD ahead of an exit, run the reviewer’s list on your own app first; the self-review section further down sets it out in order.
Three nearby topics stay out of this page: the definition of due diligence as a general business term, startup technical due diligence as investors and acquirers run it, and due diligence when buying an AI-built app, the buyer’s side of this same read.
Why it matters for the price
A buyer’s reviewer is pricing rework. In my reading, every gap they write down becomes a cost the buyer expects to carry after closing, and that cost comes off the price or moves into the terms.
The numbers from my own audits show what a reviewer is likely to meet in an AI-built codebase. At least 23 of the 26 audited apps had zero working automated tests. At least 17 of the 21 third-party apps had no deploy gate, and so did all 5 founder apps (my own): every push ships straight to production with nothing checking it first. And 22 of the 26 audited apps had at least one confirmed-critical finding. Those 26 are the apps I audited in June and July 2026, 21 chosen from outside plus 5 of mine, so they are a selected set and not a rate for AI-built apps in general.
The flags a reviewer marks against findings like these, and how each reads to the person paying, are what investors look for in code.
Some problems start before a sale and stay hidden after it. A regulator’s record shows the far end of that: the ICO’s penalty notice to Marriott, dated 30 October 2020, records that Starwood’s IT systems were compromised in 2014, that Marriott acquired Starwood in 2016, and that Marriott did not detect the attack at any time between acquiring Starwood and September 2018. That was a hotel group’s acquisition, far larger than any SaaS sale, and the full account sits with the reviewer’s flags above.
The lesson I take from it, as my opinion: what a buyer cannot read before the sale, it inherits. A seller who hands over evidence answers the question the buyer cannot answer alone in the time it has.
What the buyer’s reviewer will ask for, in order
A buyer’s technical reviewer asks for eight things, in my working order: read-only repository access, the readiness report and evidence pack, the architecture diagram, the ownership inventory, the license report, running costs by provider, the incident and uptime record, and a walkthrough with whoever knows the code best.
The list runs from the request that usually arrives first to the one that closes the review. On the technical side, due diligence for the sale of a business comes down to these eight. None of them needs production data or live keys; the reviewer reads code and documents.
- 01 Read-only repository access. Good looks like: the reviewer holds the Read role on an organization repository as an outside collaborator, with an end date agreed in writing.
- 02 The readiness report and evidence pack. Good looks like: one document that says what was checked, how, and with what result, with the proof linked rather than described.
- 03 The architecture diagram. Good looks like: one page that matches what is actually deployed, showing the running parts, where data moves, where sign-in is enforced and which outside services the app calls.
- 04 The ownership inventory. Good looks like: every account, from the domain registrar and the repository to hosting, database, payments and email, owned by the company, with the person who holds admin named.
- 05 The license report. Good looks like: every dependency listed with its license, copyleft and unlicensed packages flagged, and each flag resolved or approved.
- 06 Running costs by provider. Good looks like: a monthly figure per service, taken from the invoices, with the plan tier named.
- 07 The incident history and uptime record. Good looks like: each outage or security event with its date, cause and fix, plus whatever uptime your monitoring recorded.
- 08 A walkthrough with whoever knows the code best. Good looks like: an hour with the person who can explain why it was built this way, recorded so the answers outlive the call.
Four of these are topics in their own right: request 2 is technical documentation for investors, request 3 starts from how to create an architecture diagram, request 4 from owning an app someone else built, and request 5 from license scanning.
Grouped by area instead of by order, my mapping is: code quality is request 1, security sits in the pack at request 2, IP ownership is request 4, open-source licenses are request 5, and infrastructure is request 7. The general shape of a reviewer’s request, and what each part of it is really asking, is the section “What they will send you, and what it is really asking for” in the startup technical due diligence article; this list is the sale version of it, request by request.
Due diligence when someone buys the business: the technical half of the checklist
A general due diligence checklist for buying a business covers the company’s records: its standing, finances, assets, contracts, staff, taxes and disputes. FindLaw’s runs from organization and good standing to articles and publicity and never mentions source code, a repository, hosting or dependencies. Xero’s business purchase due diligence checklist gives technology one checklist line, “Examine technology systems, data security practices, and software scalability”, with no code, repository or hosting check behind it.
When the business runs on software, due diligence before buying it needs the eight requests above as well. For anyone purchasing a business like that, they are the missing pages of the due diligence checklist. A buyer choosing which documents to request should take the financial and legal records from the general list, then ask for read access to the repository and the seven items that follow it.
From the seller’s side, expect questions FindLaw’s list never raises. My list of the ones that catch sellers out: a secret still sitting in git history, a provider account in a contractor’s name, and a copyleft package inside the shipped product. The buyer’s own checklist for an AI-built app, from revenue to account transfer, is the buying article named in the first section.
Proprietary technology: what a buyer means, and what you must show you own
Proprietary technology, for a SaaS being sold, means the code, data and configuration the company owns outright and can prove it owns. The proof is four documents: the repository in the company’s name, the license report, the account inventory, and signed assignments from every contractor who wrote code.
The proprietary technology meaning in a legal dictionary is wider. lsd.law calls it “a form of intellectual property encompassing a body of knowledge or know-how that is owned or controlled by an individual or entity.” A buyer of a small SaaS, as I see it, cares about the narrower, practical version: can you show that what they are paying for belongs to the company?
Three of the four documents are requests 1, 5 and 4 above. The fourth is the one founders forget, and a legal checklist asks for it in its own words: FindLaw’s intellectual property list includes “Any work-for-hire agreements” and “Copies of all consulting agreements, agreements regarding inventions, and licenses or assignments of intellectual property to or from the Company”. Every freelancer or agency that wrote code for you should appear in that pile.
Who owns code that an AI tool wrote is a separate question, answered under who owns the code you paid for; I take no copyright position here. Patents are a different question again, and nothing on this page says whether any part of an app could be patented.
Angel, private equity and M&A: how the review changes with the buyer
An angel investment due diligence checklist puts company paperwork first. Hustle Fund tells angels that at pre-seed they should “start with formation and governing documents, the cap table, outstanding securities, financing documents, founder equity and vesting records, IP assignments, basic cash and runway data, and any material contracts or disputes”, and it lists “A line-by-line code audit when the technology is not the core risk” among the things early-stage diligence rarely benefits from. My reading of that: an angel’s technical read is often a demo and a handful of questions.
I’d expect technical due diligence for private equity to be run by a reviewer the fund hires, working through something close to the eight requests and writing up what they find for the fund.
M&A technical due diligence adds integration questions: can the app run in the acquirer’s cloud, behind its identity provider, under its security rules? A technical due diligence consultant often runs it for the acquirer. M&A technology due diligence, worked from a checklist, is, as I read it, the same eight requests at more depth, with those integration questions added. Whatever the buyer type, the reviewer marks the same flags, the ones the price section points to.
How to check your own app before the buyer does
Checking your own app before the buyer does takes the reviewer’s list and runs it on yourself, months ahead: fix the flags a reviewer marks first, build the evidence pack, move every account into the company’s name, clear every license flag, write the runbooks, and time a stranger’s first question.
For a micro SaaS, my working rule is to be exit ready about 12 months before you expect to sell, and this is the checklist I’d work through, each item with the evidence it leaves behind.
- 01 Fix the flags a reviewer marks first. Evidence: each flag closed, with the commit or the setting that closed it.
- 02 Build the evidence pack. Evidence: one readiness report with the proof for each check linked inside it.
- 03 Move every account into the company's name. Evidence: the ownership inventory, with no personal or contractor account left as owner.
- 04 Run the license scan and resolve every flag. Evidence: a license report with no open flags.
- 05 Write the runbooks and record a walkthrough of the code. Evidence: a runbook for each routine job, and a recording a new engineer can follow.
- 06 Put your support terms, and any SLA you promised customers, in writing. Evidence: the signed or published terms, matching what the app actually monitors.
Item 1 works from the reviewer’s flags in the price section, and items 2 to 4 follow the request pages named after the list of eight. Item 5 starts from how to write technical documentation for a vibe-coded app. For item 6, my working rule is to promise in writing only the response times and uptime your monitoring can show. If you also have time for code fixes, the cheapest-first order for an AI-built app is “What you can fix before they look, in order” in the startup technical due diligence article; this list is the exit pack, and it leaves those fixes there.
Then run the stranger test. Hand the pack to someone who has never seen the app and write down the first question they ask. It is a fair guess at the reviewer’s first question too, and you have months to answer it instead of a week.
Where the sprint does this
Requests 2, 3 and 5 on the reviewer’s list are Production Hardening Sprint deliverables. The technical due diligence pack (13.6) bundles the readiness report, architecture diagram, data model, security checklist, and capacity statement into one PDF. The system architecture diagram (13.2) shows the deployed components, data flows, authentication boundaries, and third-party integrations. The open-source license audit (10.11) inventories the licenses of every dependency, flags copyleft or unlicensed packages, and replaces or approves each one. Formal third-party certifications and independent audit opinions are separate from these engineering deliverables. How each one is verified is in the published scope of the sprint.
Common questions about selling a software business
What is due diligence when selling a business?
Due diligence when selling a business is the buyer’s check of your company before it pays: financial, legal, commercial and, for a software company, technical. The technical half is the eight requests above, starting with read-only access to the repository.
How to prepare for due diligence?
Run the buyer’s technical list against your own app first, in the self-review order, so every request already has its evidence when it arrives. The financial and legal halves need your accountant and your lawyer; the technical half needs whoever knows the code.
What are common due diligence mistakes?
The common ones on the seller’s side are four, in my list: no evidence pack, so every answer is a promise; accounts still in a contractor’s name; a dependency tree nobody has scanned for licenses; and nobody who can walk the reviewer through the code.
What due diligence is needed when buying a business?
A business purchase needs financial, legal, commercial and technical due diligence. When the business runs on software, the technical part is the eight requests on this page, and the buyer’s full list for an AI-built app is the buying article named near the top.
What are examples of proprietary technology?
For a SaaS, the examples are the code, the data model and the configuration the company owns. A buyer will want that ownership proven on paper: the repository and accounts in the company’s name, a clean license report, and signed assignments from the contractors who wrote the code.
Owning an app means being able to run it, change it and recover it without guessing. The sprint below leaves you with the runbooks and documentation to do that.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase