Micro SaaS For Sale: Where to Find, Evaluate, and Buy One

Buying a micro SaaS for sale removes the build risk and leaves the demand risk exactly where it was. The code compiles, billing runs, and customers pay every month, which is worth real money. What none of that tells you is whether independent people still report the problem the product solves, and whether the host platform has started closing the gap itself. A listing describes the last twelve months of revenue. You are buying the next twelve.

Most products that end up listed fail the same check a new idea fails. The complaints that justified the product thinned out, or the platform shipped the missing feature, or competitors arrived and the price collapsed. Our corpus holds 3,261 published pain cards across 75 software marketplaces, and a card gets published only after at least 3 distinct authors describe the same problem. Run a candidate acquisition through that filter before you look at the asking price: is the pain still repeated, is the evidence recent, does anyone in it say they pay.

We do not publish listings, and we have no verified marketplace data, no valuation multiples and no transaction figures. Nothing here is a price benchmark. This is how to evaluate a product you found somewhere else.

Key takeaways

• Buying removes build risk and leaves demand risk untouched, and demand risk is what kills small software products.
• Rank the assets in a listing by durability: renewing customers first, position inside a host marketplace second, the email list third, the code last.
• Re-run the evidence test on the product’s core problem: at least 3 distinct authors, recent dates, an explicit monetization signal. 804 of our 3,261 published cards carry that signal.
• Competitor count on the pain matters more than competitor count in the listing. Shopify card 3705 lists six competing apps. Card 4136 lists none.
• Platform limits are the liability nobody discloses. Asana card 296 documents an operation the host does not expose, and no third party can deliver what an API refuses.
• We do not publish listings and we do not quote multiples, because we have no verified data on either.

What you are actually buying

A listing bundles several assets into one number. They decay at different speeds, so separate them before you value anything.

Renewing customers are the most durable asset and the hardest to verify. What matters is not the subscriber count, it is how long the average paying account has been paying and what it uses the product for. Someone who signed up in a launch push and never logged in again is churn with a delay on it.

A position inside a host marketplace comes second. A Shopify app or an Asana integration buys you distribution a standalone tool has to rent: buyers who arrive with the problem in mind and a payment method the host already holds. Shopify accounts for 298 published pain cards in our corpus and Asana for 134. The position holds while the host’s rules hold, and it is worth nothing the day the app is delisted.

The email list is third. Contacts with no subscription convert at an unknown rate, and sellers present them beside paying accounts as if the two were comparable.

The code is last, and it is the part sellers price highest. A working micro SaaS is often a few thousand lines of glue around one platform API. Pay for it as a time saving, not as intellectual property. The model itself is defined in our micro SaaS guide.

Where people list micro SaaS businesses for sale

Three kinds of venue turn up when people look for micro SaaS platforms and listing sites, and they differ in how much you can verify before money moves.

Public marketplaces for online businesses are the obvious first stop. A micro SaaS business for sale there arrives with a revenue figure, a traffic figure and an asking price, all supplied by the seller. We have no verified data on those venues, so we will not name one, rank them, or quote a typical multiple. A guess about price is the most expensive kind to inherit.

Platform app store transfers are the second route. Inside a host marketplace, the host is a party to your deal: the listing, the reviews and often the billing relationship move under its rules. Read that policy before you agree on a number, because the reviews are frequently the most valuable asset and some hosts do not carry them across.

Direct outreach to a founder is the third route, and most buyers skip it. Founders of small products post where their users complain, so the thread that documents a pain often contains the person who built the fix. A product shopped through a broker has already been seen by everyone. Reddit is the practical hunting ground here, and we cover reading it as a research source in our guide to micro SaaS on Reddit.

The evidence check to run before you pay

Four questions, answerable in an afternoon, all about the problem rather than the product.

Is the problem still repeated? Our publication floor is 3 distinct authors describing the same thing, and cards count authors rather than posts on purpose. Fifty posts from five people is a weaker finding than fifteen from fifteen.

Is the evidence recent? Recent complaints on an old problem mean the vendor has had release cycles to fix it and has not, which is the condition a third party product needs to keep earning. Old complaints and silence since means the host fixed it or the users gave up.

Is there an explicit monetization signal? Somewhere in the evidence, someone should say they pay, would pay, or already moved to a paid tool. 804 of our 3,261 published cards carry one, so roughly three quarters do not. A product built on a pain without that signal can have revenue today and no route to more.

Is the competition already crowding the pain? Competitor pressure shows up on the pain first and in the revenue line about a year later.

Pain card	Posts	Distinct authors	Competitors on the card	Weekly interest
Shopify chargebacks and pre-order stock, 3705	118	107	6	up 231%
Shopify profit reconciliation and COGS, 4136	43	41	none found	not reported
QuickBooks Online payroll errors, 4329	30	28	not listed	up 305%
Asana retroactive custom fields, 296	11	11	not listed	not reported

Card 3705 lists six paid or freemium Shopify apps on the same problem, including OrderPoint, Stockcast and Purchase Order Hero, so a product for sale there needs a specific refusal it beats. Card 4136 has 41 independent authors and no direct competitor found: more room, less proof anyone will pay. Run these counts on the pain card index, and see how it works for what the pipeline verifies and what it leaves to you.

Platform risk is the biggest hidden liability

A micro SaaS usually exists because a host platform will not do one specific thing. That refusal is the product’s reason to exist and the failure point you inherit.

Asana card 296 is a documented platform limit with 11 distinct authors on it: “there does not appear to be an easy way to apply that new field retroactively to projects that already exist … there is no easy way to see which projects it has not been added to” (source). A tool that solves that has a real job, and its whole valuation rests on Asana leaving the gap open and still exposing the API calls the workaround needs.

Two failure modes follow. The host closes the gap in a release and your revenue becomes a legacy base that churns. Or the host restricts the API and the product stops working while you own it. Before you pay, read a year of the platform’s changelog and check whether the product uses a stable documented endpoint or a clever route around one. Per marketplace views such as Shopify show which limits keep generating complaints.

A due diligence checklist

1. Count distinct authors on the problem the product solves. Fewer than three independent voices in recent evidence means you are buying revenue, not a market.
2. Read the newest complaints rather than the loudest, and confirm people still described the problem this quarter.
3. Match the monetization signal against the product’s price. If the evidence shows people paying a fraction of what it charges, the ceiling is lower than the listing implies.
4. Read twelve months of the host’s developer changelog and list every change touching the endpoints this product depends on.
5. Install every competitor named on the pain and write down what each refuses to do. That list is your differentiation, or your reason to walk.
6. Price the cost of delivery. Support is where a one person business stops being passive, and freelance rates in the paid demand catalogue are a fair proxy: an Asana workspace audit cluster starts at $283, while a cluster promising an Asana or Trello fix within 24 hours starts at $23 across 42 buyer reviews.
7. Verify revenue at the payment processor, on a live screen share, on transactions rather than dashboards.
8. Get in writing exactly what transfers: the app listing, the reviews, the domain, the billing relationship, the host developer account.
9. Agree how long the seller stays reachable, and what happens if the host blocks the change of ownership.
10. Decide the churn you will absorb in the first ninety days and price against that, not last year’s revenue.

Definitions for the card terms above, including opportunity type and monetization signal, are on the glossary page.

When building is the better deal

Buying makes sense when the product owns a position you cannot recreate: an app listing with years of reviews, customers in a niche you already serve, or an integration approved by a host that has since tightened its rules. You are paying to skip a queue.

Building makes sense more often than buyers expect, for one reason. The scarce input is not code, it is a problem worth solving, and the research that tells you whether a listed product is worth buying also tells you what to build instead. Our build guide is the closest thing we publish to a micro SaaS tutorial, and it starts from that same evidence: what micro SaaS ideas are and how to build one. For worked candidates, micro SaaS examples goes card by card.

Buying costs money up front and reduces execution risk. Building costs months and reduces problem risk. Only one of those is fatal, because a product nobody needs cannot be fixed with better code.

Judging any micro SaaS for sale

A micro SaaS for sale is a claim that a problem was worth paying for. Your job is to test whether it still is, using author counts, dates, monetization signals and the host’s changelog. Run that check before you negotiate, because it moves your price further than any spreadsheet will.

Start with the problem the product depends on. Open the pain card index, find the pain it serves, and see whether independent people are still writing about it this month.