What to check when acquiring a micro SaaS — the specific risks of solo-founder codebases, operator-dependent systems, and sub-$10K MRR products that look simple but hide fragile infrastructure.
Micro SaaS acquisitions are attractive because the businesses are simple, the code is (usually) small, and the deal size is manageable. The risk is that simplicity is an illusion — what looks like a clean product often has a spider web of informal dependencies that only the founder knows about.
A micro SaaS doing $3K MRR is not a small version of a VC-backed startup. It's a different animal entirely. The evaluation framework for large software acquisitions applies in principle but needs to be recalibrated for the realities of solo-founder products.
This guide covers what to look for specifically when the codebase was written by one person, operated by one person, and is about to be handed to someone entirely new.
Most micro SaaS products have:
All of these are handoff risks. None of them show up in the financial due diligence.
In micro SaaS, the bus factor is always 1. The question isn't whether it's a risk — it is — the question is whether the risk is transferable.
What you need to verify:
Can a new operator run this without the founder?
Spend at least half a day doing a simulated handoff — have the founder walk you through every operational task as if you're taking over tomorrow. What comes up that wasn't in the documentation?
Solo founders optimize for cost and convenience. This creates a specific set of risks:
| Common setup | Risk | What to check |
|---|---|---|
| Hosted on Vercel/Railway personal account | Access transfers when account transfers, but billing history may be lost | Confirm transfer process with vendor before close |
| Database on Supabase free tier | Free tier has limits and can be deleted if inactive | Check tier, usage, and upgrade path |
| Emails via personal Gmail SMTP | Not reliable at scale, tied to personal account | Check how transactional emails are sent |
| Domain registered personally | Transfer requires registrar process | Initiate before close, not after |
| API keys in environment variables | Fine if documented, risky if undocumented | List all third-party services and their purpose |
| Stripe in personal account | Transferable but requires Stripe support process | Start transfer process early |
The most dangerous dependency: a third-party integration that the founder has a personal relationship with — a beta API, a special rate, a vendor contact who handles issues informally. These evaporate at handoff.
Don't apply enterprise-grade code quality standards to a solo-founder product. A micro SaaS that generates $5K MRR consistently is working. The bar is different:
What actually matters:
What you can tolerate:
What you cannot tolerate:
Revenue figures in micro SaaS acquisitions are often presented as stable when the underlying churn is masked by new signups. The business looks flat but is actually churning through customers.
What to check:
Ask for a full Stripe export or at least a cohort retention chart. This is non-negotiable.
Every micro SaaS acquisition should include a structured handoff period — typically 30–90 days where the founder is available for questions. Negotiate this explicitly:
Document the answers. Founders who say "I'll always be available" often aren't after the first month.
Micro SaaS deals are typically priced at 3–5x ARR. Technical findings should adjust this:
| Finding | Adjustment |
|---|---|
| No runbook, undocumented operations | 0.5–1x reduction |
| Critical vendor dependency (personal account) | Escrow holdback until transferred |
| Active churn-causing bugs | Quantify lost ARR and deduct |
| No database backups | ₹1L–₹3L remediation, deduct |
| Dependency on founder's personal integrations | Risk premium or seller-supported transition period |
| Clean, documented, transferable system | Pay full multiple |
Acquiring a micro SaaS and want a fast, independent review before you close? Contact us — we do focused micro SaaS technical assessments in 1–2 days with a written report covering transferability, churn risks, and infrastructure dependencies.
If this guide resonated with your situation, let's talk. We offer a free 30-minute discovery call — no pitch, just honest advice on your specific project.
Your developer went silent. Your project is half-built. You don't know what state the code is in. This is the step-by-step guide to recovering your project and getting back on track.
10 min readRescuing SoftwareHow enterprise buyers should evaluate SaaS vendor security — what certifications actually mean, what to look for in security questionnaires, data residency requirements, incident response, and the contract clauses that protect you.
11 min read