Home / Fields / Indie software & micro-SaaS
Indie Software & Micro-SaaS: Build Once, Sell Many Times
You build one small, sharp tool that removes a recurring annoyance, and charge for it monthly or once. Software is the highest-leverage field here — and the slowest to first revenue, because the product must exist before anyone can pay.
How the money flows
| Step in the chain | What actually happens |
|---|---|
| You find a paid annoyance | Not an idea — an annoyance people already spend money or hours on. The evidence standard we use site-wide: people complaining in public, existing paid alternatives, and at least a handful of people saying they'd pay. |
| You build the smallest sellable version | One core workflow, accounts, and a payment button. Everything else is a later version pretending to be a requirement. |
| Users pay subscription or one-time | Subscription fits ongoing value (hosting, data, monitoring); one-time fits utilities. Either way the payment rails are the same ones from the payments map. |
| Launch creates the first cohort | A coordinated launch (Product Hunt, communities, your list) turns a finished product into users in a day instead of a trickle — playbook on the launch page. |
| Iteration converts trials into retention | Churn is decided by whether the tool stays inside the user's weekly routine. Updates, changelogs and support replies are the retention engine. |
Who this fits — and who it doesn't
Good fit
You can code (or seriously no-code) a working product, tolerate a build period with zero revenue, and enjoy maintaining something for years. Best paired with a cash field first — software as your only income plan while broke is how good tools die unfinished.
Bad fit
You need revenue this month, or your idea needs a team, a sales force, or regulatory approval. Also a bad fit if you want to build in secret for a year: this field rewards launching embarrassingly early and iterating in public.
Zero to first payment
- Hunt the annoyance, not the idea: spend a week in the communities of one niche (sellers, creators, freelancers) listing repeated complaints and current workarounds.
- Interview the evidence: find at least 10 people with the problem; ask what they use now and what it costs them in time or money. Build only if the workaround is visibly painful.
- Scope v1 to one workflow and write the 'not doing' list next to it. Every feature must argue its way in.
- Build with boring, proven tools and add payments early — a tool that can't charge is a demo, and demos don't validate anything.
- Recruit 5–10 beta users from the same communities; fix onboarding until a stranger can reach the core value without your help.
- Launch properly: two weeks of warm-up, an Upcoming page, a maker comment, and a full launch day — the complete schedule is on the launch playbook.
- Spend the first month on activation and retention, not new features: talk to every churned user, ship the top friction fix weekly, publish the changelog.
Platforms & tools
Build where you like; sell where the buyers are. Payments: cards via the usual processors or a merchant-of-record style store from the stores comparison if you want tax handled for you. Launch: Product Hunt + Indie Hackers. Your own landing page and tooling can live on the setup from the VPS & site page, and free browser utilities to support your workflow are in the toolbox. If you'd rather sell a finished tool once than run a SaaS, the digital products field is the same instinct with less maintenance.
Worked example (illustrative math, not an earnings promise)
Assumptions, stated out loud: a $9/month tool; 50 paying users → 50 × $9 = $450/month gross recurring revenue before payment fees. Assume 5% monthly churn: 50 × 5% = 2.5, i.e. roughly 2–3 users leave monthly, so standing still requires adding about 3 users a month just to hold $450.
One-time comparison on the same audience: a $49 lifetime deal × 50 buyers = $2,450 once — bigger this quarter, zero next quarter unless you keep launching.
Result on these assumptions: $450/month recurring vs $2,450 once on these assumptions. Neither is 'better' in the abstract: subscription wins if the value recurs and churn stays low; one-time wins for utilities people use twice a year. Every input below is an assumption we state out loud, not a market average and not a promise. Change the inputs to your own quotes and fee pages before you rely on any of it.
Week one
- ☐ Spend 5 days listing niche complaints and current workarounds in a document
- ☐ Talk to 10 people with the problem; write down what they pay now (time counts)
- ☐ Write the v1 scope and the explicit not-doing list
- ☐ Pick the boring stack and set up the repo + landing page skeleton
- ☐ Wire payments before polishing anything
- ☐ Recruit the first 5 beta users by name from the communities you studied
How people fail at this
- Building the full vision first. Twelve months of secret building usually produces a beautiful answer to a question nobody asked. Launch the workflow, not the worldview.
- Free forever as a strategy. A free tier can be a funnel, but with no paid tier live, you have a hobby with server costs. Charge from the first public version, even if cheap.
- Feature-chasing after launch. New signups ask for features; retained users pay for reliability. Post-launch, the churn interview beats the feature request every time.
FAQ
Subscription or one-time?
If the tool delivers value every week and costs you money to run (hosting, APIs, data), subscription is honest pricing. If it's a run-it-locally utility, one-time with paid major upgrades respects how it's used.
How small is 'micro'?
Small enough for one person to build, support and explain in one sentence — and aimed at a niche big enough that a tiny slice of it pays your target. The constraint is focus, not ambition.
What if someone copies it?
They copy features, not your user relationships, changelog trust or niche knowledge. Ship faster in your niche and keep talking to users; that's the moat at this scale.