How to Find SaaS to Buy Cheap: A Step-by-Step Operator's Guide

Sourcing cheap SaaS acquisitions isn't complicated. It's time-consuming. There's a difference. The methodology is repeatable and learnable — what makes it hard is doing it consistently, systematically, across hundreds of candidates to find the few that pass every filter.

Here are the six steps, in order. Skip any of them and you're guessing.

GitHub's search is the most underutilized acquisition sourcing tool in the indie hacker ecosystem. The search operators let you filter by language, star count, last push date, and topic — combining these gives you a highly targeted set of candidates.

The base query for finding dormant-but-popular projects:

Breaking this down:

• pushed:<2025-01-01 — last push was before 2025, meaning 12+ months of inactivity
• stars:>100 — some community traction (not a pure hobby project)
• language:JavaScript — swap for Python, Ruby, TypeScript as appropriate
• topic:saas — self-tagged SaaS projects; also try topic:subscription, topic:api

Additional operators worth knowing:

The archived:false filter removes repos the founder explicitly archived (often a signal they consider it truly dead). The license:mit or license:apache-2.0 filters ensure you're not looking at proprietary code you'd have licensing issues with post-acquisition.

Run 5–8 variations of this query across different languages and topics. You're generating a candidate list — 200 to 500 repos — that you'll filter aggressively in subsequent steps.

Not every repo with a 12-month gap since the last push is abandoned. Some are intentionally feature-complete. Some are in private development. Some have active users but a lazy maintainer. You need to distinguish real abandonment from intentional dormancy.

Real abandonment looks like this in the commit history:

• Multiple commits per week for 6–18 months, then a hard stop
• Last commit often fixes a bug or updates dependencies — not a "v2.0 relaunch" commit
• Issues section has unanswered bug reports dating back 6+ months
• Pull requests from the community sitting unmerged for 3+ months

Intentional feature-complete dormancy looks like:

• A pinned README that says "this project is complete and no longer actively maintained"
• A regular commit cadence of dependency updates (bots) with no feature work — the founder is still watching
• Issues section has a "won't fix" template being actively applied

GitHub's API makes the commit history trivial to pull:

Look at the last 10 commits. If the last feature commit was 14 months ago and the only recent activity is dependabot PRs being ignored, that's real abandonment.

This is the critical filter. Stars are vanity. Revenue is signal. A 300-star repo with zero monetization is a hobby project. A 90-star repo with $2K MRR is an acquisition.

The monetization signals to check, in priority order:

Stripe in the codebase. Search the repo for stripe — in package.json, in the code itself, in any .env.example files. A Stripe integration means a working payment flow was built. This doesn't guarantee the payment flow is still running, but it means the founder built for revenue.

Gumroad links. Gumroad is the default monetization layer for indie SaaS products. If the README has a Gumroad link, click it. The product page often shows a purchase count in the social proof ("47 people have bought this"). That's real revenue signal. Check the date of the most recent review too — if reviews stopped 18 months ago, revenue probably did too.

GitHub Sponsors button. Check the repo for a FUNDING.yml or Sponsors button. If it's been active 12+ months, some fraction of the community is paying. Floor signal: Sponsors revenue rarely exceeds $500/month. But it proves the audience has a paying segment.

Pricing section in README. Many indie SaaS founders documented their pricing in the README: "This tool offers a hosted version at $X/month." This is a direct revenue indicator — the product was designed to charge. Search the README for words like "plan," "tier," "subscription," "license," "buy," "purchase."

Issue references to paid tiers. Scroll through the last 50 issues. Users of paid tiers tend to file bugs that reference their payment context: "I'm on the Pro plan and I'm seeing..." This is anecdotal but confirms the paid tier existed and had users.

A single viral post can generate 500 stars in 24 hours. Forks are much harder to manufacture — they represent actual intent to use or build on the code. The fork-to-star ratio is your community health metric.

Pull it from the GitHub API:

Interpretation:

• 0.10–0.20: Healthy. The community is actively building on this. High-quality signal.
• 0.05–0.10: Moderate. Some organic use, but possibly viral-moment driven. Look at when the stars arrived.
• Below 0.05: Low. Stars likely came from a viral moment. Community isn't engaged with the code. Proceed with skepticism.
• Above 0.25: High. Either technical/niche (good — means deep engagement) or used as a template repo (bad — forks are clones, not extensions). Read 5 random forks to understand which.

The ratio isn't a hard filter — it's a calibration tool. A 0.08 ratio repo with verified $3K MRR is still worth pursuing. A 0.18 ratio repo with zero monetization signals is not.

This is the step most buyers skip, and it's the step that wastes the most time. Find the founder and confirm reachability before spending 3 hours on deal analysis.

Where to find them:

• README contact info — email, Twitter/X handle, personal website
• Git commit email — run git log --format="%ae" | sort | uniq -c | sort -rn | head -5 on a clone to find the primary committer email
• GitHub profile — most active founders have a bio with contact info or link to their main site
• Gumroad seller page — if they're selling on Gumroad, there's a support email
• LinkedIn — name from GitHub profile → LinkedIn → current company/email format

The outreach message that works:

Key principles: specific, brief, no price in the first message, positions you as a steward not a liquidator. Response rates on this template run 35–50% for genuinely abandoned projects. Founders who have moved on are often relieved someone wants to take care of their creation.

Most founders who've abandoned their projects don't know what their product is worth on the open market. Some dramatically overestimate (sentimental value). Most underestimate (they just want it off their plate). Arriving anchored to market comps gives you a basis for negotiation that isn't "whatever feels right."

The anchoring sources:

Acquire.com public listings — browse the marketplace for products in the same category and revenue range. This is your ceiling. Products on Acquire.com are listed by motivated sellers with broker support, which means multiples skew high (3–6x ARR). Use these as the upside reference, not the norm.

Microns.io — focused specifically on sub-$50K acquisitions. Closer to your target range. The multiples here tend to run 2–4x ARR, which is a more realistic comp for the GitHub-sourced deals you're pursuing.

MicroAcquire sold listings — historical closed deals are the best comp data. Filter for similar revenue range and product category. Actual transaction prices are more useful than asking prices.

The market rate for sub-$10K SaaS:

• Verified recurring revenue: 2–3x annual (divide MRR × 12 × 2–3)
• One-time revenue only: 0.5–1x annual (much harder to value; much riskier)
• Unverified or declining revenue: Below 2x; heavily negotiable

Arrive at the first conversation with a number in mind. Don't lead with it — but if the founder asks "how much are you thinking?", you should have a range ready anchored to verifiable comps, not an arbitrary number.

The Full Pre-Purchase Checklist

The Time Problem

If you do this manually — run the GitHub queries, check commit history, validate monetization signals, calculate fork ratios, find founders, send outreach — you're looking at 4–6 hours per week to evaluate 5–10 candidates. And most of those candidates will fail at step 3 (no monetization) or step 5 (founder unreachable).

The math: to find 1 viable acquisition candidate per week, you need to evaluate 15–20 repos. At 20–30 minutes each through steps 1–4, that's 5–10 hours of sourcing work before you've even sent an email.

This is why ReviveHQ exists. The AI runs this methodology continuously — GitHub's full event stream, Gumroad marketplace data, ProductHunt trends, verified acquisition listings — and delivers pre-filtered, pre-scored candidates. A repo that passes all six filters gets a 0–100 revival score plus a structured analysis: tech stack, estimated rebuild effort, revenue potential, acquisition price range, reason for abandonment.

You still do the founder outreach and revenue verification yourself. That part requires a human. But the sourcing funnel — finding the 15 candidates worth evaluating — happens automatically.

One Final Note on Timing

The supply of genuinely cheap, monetized, abandoned SaaS is a function of when products were built and abandoned. The cohort we're working with now — 2021–2024 products abandoned during the post-COVID normalization, the AI transition, and the no-code/low-code wave — is the richest sourcing environment I expect we'll see for this category.

In two years, many of these products will have been acquired, relaunched, or genuinely lost (founders unavailable, infrastructure gone, domain expired). The manual methodology in this guide works today. The question is whether you're running it systematically or sporadically.

Systematic wins. It always does.