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. The rest of this post covers which parts you can verify, which parts you cannot, and what covers the gap.

On Zero to Hundred the gap is covered on both sides of the payment: every listing carries a working demo you check first, and every sale gives you a 24-hour report window backed by a 72-hour hold on the Builder's payout. This post covers the 5 failure modes and the specific thing that settles each one.

What are you 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, because you can run the software and check it. You cannot check revenue someone tells you about.

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 3 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 the marketplace protect you from?

A marketplace 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 there is a defined window and defined grounds for using it.

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

• Every listing carries a working demo. You evaluate running software before you pay, and that is the part doing the real work.
• Every sale is final, at every price. The source code is delivered the moment you pay, so there is no window to wait through before you get it.
• You have 24 hours from delivery to report misrepresentation or a bug that stops the software working. That is your filing deadline.
• The Builder's payout is held for 72 hours, which is deliberately longer, so a report filed late in the window is still reviewed before any money reaches them.
• A completed sale carries a commission on the Builder's side: 25% on a marketplace sale, or 8% plus $0.50 on a sale they brought themselves from a link they shared.
• Payments and payouts run on Stripe Connect. A Builder can connect GitHub, and when they do, the listing is tied to a public commit history you can go and read. That links an account. It does not check a government ID. Treat it as one signal among several.

The demo is what you spend your evaluation on, and you spend it before the money moves rather than after.

What happens if the software is not what was described?

You file a report, and the grounds are fixed. There are 3:

1. Misrepresentation
2. A bug that stops it working
3. Other factual grounds

Changing your mind is not a report. Deciding the software is harder to maintain than you expected is not a report. The 3 grounds are all factual claims that can be checked by someone who was not in the conversation, and that is deliberate. A process that accepted "I don't want it anymore" would work as a refund policy, and every Builder would price for it.

The same 3 grounds apply at every price. A limitation the Builder disclosed in the listing is not valid grounds, which is why reading the listing closely is part of the evaluation rather than a formality.

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.

The report window is 24 hours. It applies at every price, and delivery is instant. That puts the weight on the demo: the checking you might expect to do after paying has to happen before you pay.

A license keeps the copyright with the Builder. 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.

The marketplace 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.

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 as well as 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. Work the demo hard before you pay. Delivery is immediate and your report window is 24 hours, so the evaluation has to happen first.
7. Ask the Seller one question that only someone who built it could answer. The answer tells you more than the listing does.

Whether it is safe to buy a SaaS business depends on 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. If you are buying to stop your team from rebuilding software that already exists, buy software instead of building it is the case for it. If you are still working out whether a marketplace like this fits what you are trying to do, who ends up buying and selling here covers all 3 sides. Questions about a specific deal go to support.