Buying a small SaaS product has never been more accessible. Marketplaces list running businesses with revenue, customers, and a working product, and for the price of a used car, you can own software that earns while you sleep.
That is the pitch, anyway. The reality depends almost entirely on what is inside the codebase, the one part of the deal the listing cannot show you. Revenue can be verified from payment records. Traffic can be verified from analytics. The code is where surprises hide, because it is the asset the seller knows best and the buyer usually cannot read.
Here is what to check before the wire goes out, whether you check it yourself or have someone do it for you.
1. Does the Code Match the Story?
Every listing tells a story: a polished product, a clean handover, easy growth from here. The codebase tells its own version, and the two do not always agree.
A product can demo beautifully and still be a prototype underneath, the kind of code that works for the current handful of customers and falls over at ten times that. Nothing about the demo reveals this. The tell is in the code: how errors are handled, whether there are tests, how data is structured, whether the parts fit together deliberately or by accident.
You are not buying the demo. You are buying the ability to run and grow what is behind it.
2. Can It Run Without the Seller?
This is the question that catches the most buyers. A small SaaS is usually one person's product, and that person has been quietly holding it together in ways no document records.
Look for the dependencies that walk out the door with the seller:
- Services registered under the seller's personal accounts: hosting, domains, email delivery, payment processing.
- Undocumented deployment steps that live only in the seller's head.
- Third-party integrations on the seller's personal API keys.
- Code that only makes sense with the seller's explanation attached.
None of these are deal-breakers by themselves. All of them are negotiation points, and every one you discover after closing becomes your problem instead of the seller's.
3. What Are You Legally Inheriting?
Code carries obligations that transfer with it. Two matter most for small deals.
Licenses. Most software is built on open-source components, and most open-source licenses are friendly to commercial use, but not all. A component with a restrictive license buried in the dependency tree can put obligations on the whole product. This is invisible in a demo and takes minutes to check in the code.
Customer data. The moment the deal closes, how the product stores and handles customer data becomes your responsibility, including anything careless the previous owner did. Passwords stored wrong, personal data kept where it should not be, no way to delete a user who asks: these become your liabilities at the price of one signature.
4. What Does It Actually Cost to Run?
The listing shows revenue. Ask harder questions about the other side of the ledger:
- What are the real monthly infrastructure costs, and do they grow per customer?
- Which paid services does the product depend on, and what happens when their prices change?
- How many hours a month does keeping it running actually take? (Sellers underestimate this honestly: the work became invisible to them years ago.)
A product netting a healthy margin at the seller's costs can net much less at yours, especially if the seller was doing skilled maintenance work they never priced.
5. What Will Your Plans Cost?
Almost no one buys a small SaaS to leave it exactly as it is. There is a roadmap in your head: the feature that wins the next tier of customers, the integration that opens a new market.
Price that roadmap before you buy, not after. The same feature can be a week's work on a well-structured codebase and a rebuild-sized project on a tangled one. Two listings with identical revenue can differ enormously in what your plans will cost on top of the purchase price, and that difference belongs in your offer.
The Uncomfortable Truth About Doing This Yourself
If you can read code, everything above is checkable in a focused day or two. If you cannot, you are in the strange position of buying an asset you cannot inspect, like buying a house where only the seller has been inside.
The standard answer is an independent inspection. That is exactly what our pre-acquisition code audit is: we read the codebase the way the seller hopes nobody will, and within 72 hours you get a written report: what is actually there, where the security gaps are, what liabilities are hiding, and what running and extending it will really cost, in fixed price bands. It is priced from $950, quoted up front for your specific deal.
Whether the audit is ours or someone else's, the principle stands: the code is the asset. Read it, or have it read, before you buy it.