Is it safe to buy a SaaS business? 5 ways it goes wrong

Buying a SaaS business is safe when the money moves after you verify what you are getting. It is risky when the money moves first. That is the whole answer. Everything below is detail about which parts you can verify, which parts you cannot, and what covers the gap.

On Zero to Hundred the gap is covered by escrow: sales at or above $100 hold the funds and give you a 7-day Dispute Window, and below that a 24-hour report window backed by a hold on the Builder's payout. Most writing on this question walks you through a buying process. This covers what actually goes wrong, because the failure modes are specific and each one has a specific thing that settles it.

What are you actually buying?

Two different purchases hide under the same question, and they carry different risks.

Buying a running business means buying revenue, customers, and the accounts that hold them. Your risk is that the revenue is not real, or that it does not survive the handover.

Buying a codebase means buying working software and the right to use it. Your risk is that the code does not do what the demo did.

The second one is what you buy here. Every listing is license-only: you get the right to use, modify, and deploy the software, and the Builder keeps the copyright. That narrows the risk surface considerably, because software you can run is software you can check. Revenue you are told about is not.

What goes wrong when it goes wrong?

Five failure modes cover almost everything. None of them are exotic, and each has an artifact that settles it before you pay.

Two of these deserve more than a table row, because they surprise people who have done everything else right.

The Stripe account cannot be handed over like a set of keys. Stripe's own documentation on selling a business is explicit that the account itself does not move to whoever bought it. You update the information on the existing account, and Stripe support has to confirm which details change. Read that again as a Buyer: the Seller has to keep cooperating with you after the money has moved. If your deal assumes a clean account handover at close, your deal assumes something Stripe does not offer. (Stripe support)

GitHub redirects are not permanent. When a repository is transferred, GitHub redirects the old URLs, which makes everything look fine. But the docs state that "if you create a new repository or fork at the previous repository location, the redirects to the transferred repository will be permanently deleted." A Seller who later creates a repo at the old path breaks every link you kept. Clone it yourself on day one. (GitHub docs)

How do you verify revenue you cannot see?

Screenshots prove nothing. They are trivial to fake and there is no version of "but the numbers looked real" that gets your money back.

Ask for read-only access to the payment processor instead, and ask for the export rather than the summary view. Then look at three things most Buyers skip: refunds, disputes, and the gap between gross and net. A business with strong gross revenue and a quiet refund problem looks identical to a healthy one until you own it.

If a Seller will not give read-only access, that is your answer. It costs them nothing and it is the single cheapest way to prove a claim they are already making.

What does escrow actually protect you from?

Escrow protects you from paying for something you never receive. On its own, it does not protect you from paying for something that arrives and turns out to be worse than described. That second protection only exists when the escrow has a defined window and defined grounds for using it.

Here is how it works on Zero to Hundred, with the actual numbers:

• Sales at or above $100 go through escrow with a 7-day Dispute Window. The funds sit until that window closes.
• Below $100, the source code is released to you instantly, so there is no evaluation window to wait through. You still have recourse: you have 24 hours from delivery to report misrepresentation or a bug that stops the software working, and the Builder's payout is held for 72 hours so a report filed in time is reviewed before any money reaches them. After 24 hours the sale is final.
• A completed sale carries an 8% platform commission.
• Payments, escrow, and payouts run on Stripe Connect. Sellers sign in through their GitHub account, so a listing is tied to a public commit history you can go and read. That is account linkage, not a government-ID check. Treat it as one signal among several rather than proof of who someone is.

During the window you evaluate the software in a test environment. That is the part doing the real work. Escrow buys you time; the test environment is what you spend it on.

What happens if the software is not what was described?

You open a dispute, and the grounds are fixed. There are four:

1. A broken test environment
2. Misrepresentation
3. A bug that blocks evaluation
4. Other factual grounds

Notice what is absent from that list. Changing your mind is not a dispute. Deciding the software is harder to maintain than you expected is not a dispute. The four grounds are all factual claims that can be checked by someone who was not in the conversation, and that is deliberate. A dispute process that accepts "I don't want it anymore" is a refund policy wearing a costume, and it makes every Builder price defensively against you.

Those four grounds apply to the escrowed tier. A below-$100 report is narrower: it accepts misrepresentation, or a bug that stops the software working. A broken test environment is not on that list, because below the threshold you already have the code.

The full rules live in the Terms of Use, and the disclosures cover what does and does not get verified.

When is buying not safe?

Some risk sits outside anything a marketplace can hold, and you should know which parts those are before you decide.

Under $100 the window is hours, not days. Delivery is instant and your report window is 24 hours, on the two narrower grounds above. That is the right shape for a $30 script and the wrong assumption to carry into a larger deal, where the 7-day evaluation window is what you are paying for.

A license is not a copyright transfer. You can use, modify, and deploy the software. You are not buying the copyright, and you should not plan around reselling it as your own.

Escrow does not underwrite the business. It confirms you received working software that matches its description. It makes no claim about whether the software will keep making money, whether the market is real, or whether you will enjoy maintaining it.

Anything that depends on accounts you cannot inspect is unverified. Customer lists, processor history, ad accounts, domain reputation. If the value of a purchase rests on those, the safety question is about the Seller, not the platform.

What to check before you send money

Run this list. It takes an afternoon and it removes most of what goes wrong.

1. Run the software yourself, in your own environment, doing the thing you are buying it for.
2. Get read-only processor access, and pull the export rather than the dashboard view.
3. Read the refund and dispute history, not just the revenue line.
4. Clone the repository into your own account the day the transfer happens.
5. Write down what is included, by name. Code, domains, accounts, credentials.
6. Confirm whether your purchase sits above or below the escrow threshold, and price the difference in risk.
7. Ask the Seller one question that only someone who built it could answer. The answer tells you more than the listing does.

The honest version of "is it safe to buy a SaaS business" is that safety is not a property of the marketplace. It is a property of the order things happen in. Verify, then pay. Everything on this page is a way of making that order enforceable.

You can browse what Builders have listed or read how listing from anywhere works if you are on the other side of this. Questions about a specific deal go to support.