Due Diligence When Buying a Software Company Built With AI

Somebody wrote this in public while getting a website ready to hand to a client:

i created a website using lovable and im thinking of selling it to the client but when i download the zip from github and runs npm install and npm run build it doesnt create a dist folder which is kind of needed for hostinger

They are days away from the handover and nobody has ever built the product from the repository. On Acquire.com, Flippa and TrustMRR that situation gets priced, listed and sold, and the buyer usually cannot read the code either.

Due diligence for a software company has a settled shape, and the guides that rank for it are written by brokers and advisers. It stops where the product was built with AI tools, because that is where the mechanics stop being general and start being specific to Lovable, Base44, Replit or Bolt, and those four vendors publish four different answers.

Due diligence on a software company built with AI comes down to four checks a non-coder can run: prove the revenue from inside the payment account, confirm every asset can actually transfer, get each account into your own name, and find out what stops working when the seller’s plan lapses.

Every transfer rule below was read on 26 August 2026 from the documentation of the company that enforces it, one page per rule: each builder’s own project-transfer page, GitHub’s repository transfer page, Supabase’s project transfer page, Stripe’s user roles page and its support page on selling a business, Cloudflare Registrar’s transfer page, Acquire.com’s asset transfer help pages and Escrow.com’s inspection period page. Nothing was bought, no project was transferred, and no live listing was inspected for this page.

What software company due diligence misses when the product was built with AI

This reader is not rare. A post on r/AcquireStartup in July 2026 was titled BUYING startups that meet my criteria, and one on r/sideprojects that week put it in two words: Buying sites. One seller writes publicly that a subscription product they had vibe coded in a week, which reached roughly fifteen hundred dollars a month at its best, went for a five figure sum on a marketplace.

Search buying a software company due diligence and the results are advisers. Software Equity Group, Meridian Trust, Revenera, Black Duck, Devcom, PI Partners, Cyberhusky, MA Science, KMS Technology, DealRoom and Diligent hold the first page between them. Empire Flippers, FE International, SureSwift Capital and Flippa publish the buyer-side version. None is linked here, because all of them sell advisory, review or brokerage work.

Three were read in full on 26 August 2026, named without links for that reason: softwareequity.com/due-diligence, empireflippers.com/saas-due-diligence-for-buyers/ and flippa.com/blog/buying-a-saas-business-the-complete-guide-to-due-diligence/. The same edge shows up in all three. Software Equity Group’s guide is written for the seller preparing to be examined: “For sellers, the objective of due diligence is to get through without any adjustments to the price or terms of the deal.” As of that date it does not discuss AI-generated code, no-code builders, or how a product built with those tools moves to a new owner. In Empire Flippers’ buyer guide, code quality is a passing mention of sloppily written code. Flippa’s own buying guide is the closest page on the internet to this reader, and it is good: it warns that “if the seller cannot prove clean rights, it is better to walk away”, and tells buyers to ask for a “supervised code walkthrough or read-only repo access”. On the technical side that is where it stops.

So the gap is one of mechanism. Every ranked guide tells a buyer to confirm the assets transfer. Not one says what happens when the asset is a Lovable project, a Base44 app, a Replit deployment or a Bolt project, where four vendors document four different rules and two of them stop an ordinary transfer dead. That is the part of due diligence for a software company acquisition nobody has written down.

Four questions decide it. Is the revenue real? Can the product actually be transferred? Whose accounts are these? What stops working when the seller’s plan lapses?

Two neighbouring jobs stay out of frame. What a technical reviewer finds in an AI-built codebase when the company being examined is your own, and what you can fix before they arrive, is this page turned around to face the other way. The item-by-item checklist a reviewer works through, written so somebody who cannot read code can walk it, has its own page.

How long do you actually get to look at the business?

An escrow inspection period runs 1 to 30 calendar days, agreed by both sides before the transaction starts, and the clock begins when you mark the assets received. Agree the technical checks before that clock starts, because a repository nobody has ever built is not something you discover in an afternoon.

Escrow.com’s inspection period FAQ states the range plainly: inspection periods “are 1 - 30 calendar days and must be agreed upon by all parties at the initiation of the transaction”, and the clock starts when “the Buyer marks the merchandise or service as ‘Received’ or when Escrow.com verifies or receives confirmation that the merchandise, domain, or service has been delivered”. The default runs against you: “If the Buyer does not take any action within the Inspection Period, at the end of the agreed-upon Inspection Period, Escrow.com will release the funds to the Seller.”

Silence is acceptance. A buyer who spends four days of a seven day window waiting for a seller to answer about repository access has spent most of their leverage.

Acquire.com’s asset transfer help page sets the order of events, telling sellers not to start transferring assets until “Escrow.com or E-Commerce Law Group has verified the buyer’s funds”. Funds go in first, then the assets move, then the buyer approves the release. Acquire.com’s asset transfer plan page describes the document the seller works from, which “ensures the buyer receives the correct assets at closing” and helps them “keep track of each asset, who you’re transferring it to, and when and how you plan to transfer it”.

Read that plan early, and read what is missing. As of 26 August 2026 it names intellectual property, websites, domain names, customer data, social accounts, contracts and product stock. It does not mention code repositories or payment processors, and it does not state an inspection period. Those are yours to add by name.

Flippa’s help centre could not be read for this page. support.flippa.com returned HTTP 403 to an unauthenticated request on 26 August 2026, through an ordinary browser user agent, so nothing about Flippa’s verification process is claimed here in either direction.

The person who runs one of these marketplaces says it has moved over a hundred companies with no staff behind it, which tells you how little sits between a listing and a wire transfer. Spend the window on the two things nobody can do for you later: getting a build to run and an account into your name.

Is the revenue real?

Screenshots are not evidence. Stripe publishes a View Only role that sees payments, balance, payouts, transfers, disputes, customers and financial reports and exports in bulk, and cannot refund, pay out, create API keys or change the team. Ask the seller for that role by name.

The seller’s side of a listing sounds like this, and this one is real:

I’m not a developer - I built the entire thing using AI tools. The app is complete, polished, and production-ready.

“Production-ready” is a feeling. The revenue number beside it is checkable, and there is a named, minimum-privilege way to ask.

Stripe’s user roles page describes the View Only role as being “for people who need to view payments, balance, and connected accounts, but can’t edit any of them”, and lists what it can do: view disputes, payments, products, customers, balance, transfers, payouts, events and logs, plus “Create, view, and download financial reports” and “Bulk exports of payments, customers, and products”. The same page lists what it cannot do, and that list is why a seller can say yes: no resolving disputes, no creating or refunding payments, no paying the balance out to a bank account, no bank details, no API keys, no team changes, no changing the account owner.

A seller who refuses read-only access to the account holding the revenue they want paid for is telling you something. One who agrees hands you an afternoon of real work:

Export as you go: a screen share ends, a file does not. The cancellation row is where AI-built products fail more often than the dashboard suggests: Stripe cancels the subscription, the app never gets the message, and you inherit customers who stopped paying and kept using the thing. That failure has a shape worth reading first, in a cancelled subscription that never stopped the access, and its mirror image, paid features reaching people who never paid, is what happens when the entitlement check lives in the browser. Both make a revenue number look better than the business is.

Watch the age of the thing, too. A post on r/SaaS in August 2026 was titled $2.4K ARR after just 14 days. Should I scale or sell?, and a listing on r/saasforsale in July 2026 read:

[FOR SALE] WaitlistMaker | 62 users | $35 MRR | 2 paying customers | Full project …

Sixty-two users and two paying customers is verifiable in ten minutes inside Stripe. Fourteen days of history is not a trend, and no checking turns it into one.

Can the product actually be transferred to you?

Four builders, four answers. Base44 gates an outside-workspace transfer behind Enterprise and approved Partner status, Lovable requires the new owner to be a full member of the seller’s workspace, Replit documents no transfer between individual accounts, and Bolt moves the project while removing the GitHub link.

Working out what the product on a listing was actually built with, before any of the four questions here, has its own visible tells, and it decides which row below you land on. Here is what each vendor’s documentation said on 26 August 2026, and it is the part of a software company due diligence checklist that exists nowhere else.

Two of those rows change what you are buying. On an ordinary Base44 plan the app cannot be handed to anybody outside the seller’s workspace, so you have to be let into that workspace first. Base44’s page on managing workspace apps documents both paths and puts the plan gate on only one of them. On Replit there is no transfer to ask for; what you are buying is a fork. Lovable’s FAQ answers the ownership question bluntly, “You as the creator do!”. Owning the code and being able to move the project are different questions.

Underneath the builder sit the database and the repository, and the order they move in is the reverse of most people’s instinct. Supabase’s project transfers page lists what has to be true before a project can move between organisations: “You need to be the owner of the source organization”, “You need to be at least a member of the target organization you want to move the project to”, and “No active GitHub integration connection”. So the GitHub link comes off first. Bolt’s manage your projects page says the same thing from its side, that “the Supabase settings transfer with the project, but Bolt can’t transfer the account itself”, so the Supabase project needs moving separately before the Bolt project does.

The repository carries a passenger. GitHub’s transferring a repository page states that when a repository is transferred between two personal accounts, “the original repository owner and collaborators are automatically added as collaborators to the new repository”, and that a private repository moved to a GitHub Free user or organisation account “will lose access to features like protected branches and GitHub Pages”.

After a transfer between personal accounts, the seller is still a collaborator on your repository until you remove them. GitHub adds them automatically and nobody sends you a reminder.

Add that to whatever software acquisition due diligence checklist you are working from, in this order: GitHub integration off, Supabase project moved, repository transferred, seller removed the same day.

Whose accounts are these, and whose name is on the card

Two assets do not move when the project does, and both run on somebody else’s clock. The domain strands more deals than anything else here, for reasons that have nothing to do with either party. Three separate things can move: control of the registrar account, the registrant record, and the domain itself to another registrar, and only the last is bound by the rules below. Cloudflare Registrar’s transfer page sets out three ICANN rules that all have to be true before a domain will move: it was registered more than 60 days ago, it has not been transferred in the last 60, and the registrant name, organisation and email have not changed in that window. What a change to those fields does, in the page’s own phrase, is “trigger a 60-day transfer lock”. It puts the work at about 30 minutes and the waiting at up to 10 days. Sellers update that email while tidying up before a listing, so ask when the registrant record last changed.

The payment account is the one most often got wrong. Stripe’s support page on transferring an account after a business sale tells the existing owner to start by “reaching out to Stripe Support to confirm which, if not all, of the following information will be changing”. Stripe’s user roles page decides who can start that conversation, because changing the account owner sits in the Administrator role’s list of things it cannot do, noted there as something only the owner can do. So a seller offering to make you an admin and let you take it from there is describing something Stripe says an Administrator cannot do. As of 26 August 2026 that support page does not say what happens to payment history, live subscriptions or saved cards, and the gap is not filled here.

Then there are the metered accounts, the ones with a card attached: a builder subscription, a database plan, an email sender, a storage bucket, an error tracker, an AI provider key, a registrar. If any stays on the seller’s card after closing, they can turn it off, and they will eventually stop paying. Neither happens out of malice; both happen when a card expires on an unwatched account.

Which of these accounts must end up in your name, and the one-minute check that settles each, is the same list read from the owner’s side rather than the buyer’s. The buying side adds one step: move each account before the inspection window closes, because after it closes your only leverage is a conversation.

What stops working when the seller’s plan lapses

This is the fourth question and the one no ranking guide asks. On several of these builders the product is a tenant inside an account the seller pays for, and the day that payment stops is a date you do not control.

Replit’s account and access page states, while explaining why accounts cannot be handed over directly, that subscriptions do not transfer and the new owner needs their own. That sentence carries an em dash in the original so it is described here rather than pasted. The seller’s plan is not part of what you are buying, and whatever it pays for stops being paid for.

Base44’s page on managing workspace apps is the same shape from another angle: an inside-workspace transfer moves ownership of the app while the app stays in that workspace, and the workspace belongs to whoever pays for it. Lovable’s full-workspace-member requirement has the same consequence, unless the buyer is the one paying for the workspace after closing.

One owner asking about this publicly framed it as a running cost, wondering whether they would also have to pay somebody to oversee the thing on top of the subscription. On these platforms the subscription is often what keeps the product reachable.

So the buyer’s real defence is a copy. Before the money moves, get the code and the data out to somewhere you pay for, and confirm the code builds from that copy on a machine that is not the seller’s. That is exactly what the seller at the top of this page could not do, and they built it.

The mechanics differ per tool, and whether the code can leave the builder at all, tool by tool is a dated matrix of what each hands over. The five reasons people leave a builder is worth reading before you buy something that stays where it is, because a buyer who plans to move it later is buying a job as well as a business.

What reading the code before you wire the money shows you, and what it does not

An m&a software due diligence checklist is built around documents: contracts, financials, licences, IP assignments. None of it opens the code, and for a product one person built with AI tools the code is where the surprises are.

In AxonBuild’s fixed study of 26 AI-built applications audited in June and July 2026, counted from that study’s findings ledger, nine of the 26 were running a framework release with a published hole a stranger could reach, remote code execution or an authentication bypass, and closing it usually meant one version number. The method and every denominator behind that number sit with what 26 audited AI-built apps actually contained. Of the 14 third-party applications in the same study that had an AI feature at all, 8 had a live path for a stranger’s text to reach the model’s instructions, counted from the same ledger.

Numbers like those read as a reason to walk away from every AI-built product on a marketplace, which is the wrong lesson. The seller’s version of the same product is also real:

I made a whole polished bug free iphone app for my business that would have taken at least 3-4 months with 2 developers that would have cost $50k.

Both descriptions can be true at once. The thing works, customers pay, and it has a known hole in a dependency that takes ten minutes to close. What a buyer needs is the difference between a list and a decision.

The audit’s own scoring rule, from the method behind AxonBuild’s fixed June to July 2026 study, draws that line: any single confirmed critical forces a red band regardless of the score, because the band is a risk posture and the score measures how much work the remediation is. A red band can therefore mean one version bump on an otherwise clean product, and an amber band can mean no exploitable holes at all and a long list of small unfinished things. Both reads are intentional, and neither is a price.

A red band can mean one version bump. An amber band can mean a long list of small unfinished things and nothing a stranger can exploit. The band is a posture, not a valuation.

A reading is a photograph of the code on the day it is taken. It settles nothing about the price, nothing about whether the customers renew, and nothing about how the next version gets written. It cannot confirm the revenue either, which is why that is the first of the four questions and not this one.

What you get is somebody opening the thing on the product itself, with you watching. No document changes hands. Under a seven day clock that is the only version worth anything, because a list of severities you cannot evaluate is a longer listing.

Who reads code you did not write covers the market and the published prices, and the day after, when the product is yours and nobody is left to explain it is the week that follows a purchase like this.

Checking an app somebody built for you, when you paid for it and the person who wrote it still answers your messages, runs on a different set of requests. This is the version where the seller has been paid and has no reason to answer anything.

Common questions about buying an AI-built app

What does due diligence mean when you are buying a software company from one person?

It means checking four things yourself instead of accepting them from a listing: that the revenue exists inside the payment account and not only in a screenshot, that every asset can technically transfer to you, that each account ends up in your name, and that nothing stops working when the seller’s subscriptions lapse. A due diligence checklist for a software company with one owner is shorter than an enterprise one and has different hard parts. There is no finance team to interview, just one person, their accounts and their code.

Do I need a due diligence report before I buy?

A due diligence report is the document your own reviewer writes for you, and whether you need one depends on the size of the cheque and who is asking to see it. AxonBuild does not produce one. If you want an outside look at the code before you buy, agree its scope and the evidence you expect with whoever you commission, and ask them to show each weakness on the product itself rather than describe it. If an investor or lender needs a written document, commission it from a reviewer who writes those.

How do I verify the revenue on a listing without taking the seller’s word for it?

Ask for Stripe’s View Only role on the account that holds the revenue. Stripe’s user roles page documents it as read-only across payments, balance, payouts, transfers, disputes and customers, with financial reports and bulk exports included, and no ability to refund, pay out, create API keys or change the team. Then compare payouts against charges rather than gross volume, check the refund and dispute rate, count active paying subscriptions rather than accounts, and export the numbers before the call ends.

What if the seller built it on Lovable, Base44, Replit or Bolt and cannot transfer the project?

Then you are buying the code and the data, not the project, and the deal has to be written that way. Base44 has two paths and only one of them is likely to be open: its page on managing workspace apps says a handover inside the seller’s workspace carries no plan requirement, but you have to be admitted to that workspace as a collaborator and member with an editor role or higher first, while a transfer to somebody outside the workspace is available for Enterprise workspaces and approved Base44 Partners. Replit’s account and access page documents no individual-to-individual transfer and points at share and fork instead. Where no path is open to you: export the code and the database, confirm the export builds and runs somewhere you pay for, and agree the price on that basis before the funds go into escrow.

Can I see the code before I pay?

Usually yes, under read-only access, and the ranked buyer guides already tell sellers to expect the request. What sellers refuse is a full copy of the repository before payment, which is reasonable: the code is most of what they are selling. A supervised walkthrough on the seller’s screen is the normal middle ground; read permission on the repository itself normally allows a clone or download, so a seller who grants it has in practice handed over a copy, and the contract is what limits what you may do with it. If the seller refuses any code access at all, you are buying revenue and a brand, and should price it as though the code has to be rebuilt.

Does the seller still have access after the sale?

On GitHub, yes, unless you remove them. GitHub’s transferring a repository page states that when a repository is transferred between two personal accounts, the original owner and collaborators are automatically added as collaborators on the new repository. Nobody prompts you, so removing them is a day-one task. The same applies elsewhere: the builder workspace, the database organisation, the email sender and the error tracker all keep whatever team members they had.

What happens to the domain after the sale?

A transfer to another registrar moves on ICANN’s clock, not yours; changing the registrant record or handing over the registrar account are separate routes with their own rules, so check which one you are being offered. Cloudflare Registrar’s transfer page sets three conditions: 60 days since the domain was registered, 60 days since any previous transfer, and no change to the registrant name, organisation or email inside that window, which the page says triggers a 60-day transfer lock. The transfer takes about 30 minutes of work and up to 10 days of waiting. Ask when the registrant record last changed before agreeing a closing date, because a seller who updated their own email while preparing to list has locked the domain.

Should I walk away if a review finds a long list of problems?

Not on the length of the list. In the study behind the numbers on this page, the scoring rule treats a single confirmed critical as enough to force a red band regardless of the score, because the band describes risk posture while the score describes how much remediation work there is. A red band can be one version bump on a clean product; an amber band can be a long list of small unfinished things with nothing exploitable in it. Ask which findings are reachable by somebody with no account, and price the rest as work.

What does a look before buying cost?

There is no published price for looking at somebody else’s product before you buy it, and this page will not invent one. What AxonBuild offers is a free 20-minute video call with Bilal about an app you are working on, and a fixed quote after he checks the code if you want a change made, paid after you see it working. A look at a product you do not own yet is a different question, so raise it on the call rather than assuming it is covered.