AI Micro-SaaS
Build one small paid tool that solves one narrow problem, then let it run.
Product metrics
Signups, revenue and churn
| Event | Plan | Source | MRR change |
|---|---|---|---|
| Converted | Starter | Organic search | +€19 |
| Upgraded | Starter to Pro | In-app | +€30 |
| Converted | Pro | Referral | +€49 |
| Churned | Starter | — | -€19 |
| Trial started | — | Organic search | — |
| Converted | Starter | Product Hunt | +€19 |
Example figures. These amounts show how the workflow behaves — they are not earnings, not ours and not anyone else's. Nobody made this money.
Open full screen · recording mode — sized for vertical video.
Read this before the opportunity
This one demonstrates far better than it performs. Its content score is 7.7 against a business score of 5.3 — a gap of 2.4 points. That pattern is exactly what the get-rich-with-AI industry is built on: strategies that look spectacular in a short video and disappoint in practice.
A recurring revenue counter that climbs is a strong, honest visual.
Follow these prompts to start building your income stream
6 steps. Paste each prompt into Claude, use what comes out, move to the next. The last one ends in something live — not in a plan to make something live.
- 01
Pick the job and the one task
Free sampleOne profession, one task, and a scope that fits in two weeks.
In this step you make the decision that determines whether this ships. Micro SaaS dies from scope, not from competition: the version you can finish is worth more than the version you can imagine. You end with a one-line product definition and an explicit list of what it does not do.
1 — Find the taskI want to build a small paid tool for one profession. Professions I have real contact with: [YOUR PROFESSIONS] What I can build: [YOUR STACK] For each profession, list three recurring tasks that: - happen weekly or more often, - are currently done in a spreadsheet, a document or by hand, - have an output someone else reads, - and are annoying enough to pay to remove. Per task: who does it, what it costs them in time, what they use today, why that is bad, and what makes it hard for a big platform to bother solving. Then pick the three most promising and say what would make each one fail.
2 — Write the scopeDefine v1 of a tool that does [TASK] for [PROFESSION]. Write: 1. The product in one sentence, as the user would describe it to a colleague. 2. The single flow it supports, screen by screen, in the order the user moves. 3. What is explicitly not in v1 — at least eight things people will ask for, including the obvious ones. 4. The data model, kept to the minimum that supports the flow. 5. What "finished" means for v1, as a list I can check off. 6. An estimate in evenings, assuming I work on this after a day job, and where that estimate is most likely wrong. Cut anything that is not needed to do [TASK] once, well.
Claude. Ask it to challenge the scope: the first version is always too big.
- [YOUR PROFESSIONS]
- Where you know someone who does the work. You need five conversations later, and strangers do not answer.
- [YOUR STACK]
- What you can actually ship with, including 'I use Claude Code and know some TypeScript'.
- [TASK]
- One task, not a category.
Then: Send the one-sentence description to two people in that profession. If they answer with a question about what it does, the sentence is not clear enough yet.
- 02
Put the landing page up first
In the packageA live page describing the tool, with a way to sign up.
In this step you find out whether anyone cares, before you spend six weekends. The page also does something useful for you: writing it forces the product to be describable. If the description is hard to write, the product is still too vague to build.
- 03
Talk to ten users, cut the scope
In the packageTen conversations, and a scope that survived them.
In this step you spend a week listening instead of building. The point is not validation — it is finding the one detail that makes your flow wrong, which is always cheaper to find now. You end with a shorter build and more confidence that it is the right one.
- 04
Build it with Claude Code
In the packageA working tool that does the one task, start to finish.
In this step you build. The trick is to keep the model working from a written spec instead of a chat: a spec you can point at keeps the scope from drifting while you build. You end with something a real user could use for the task, even if it is plain.
- 05
Set the price, take payments
In the packageA pricing page live, checkout working, free tier with a limit.
In this step the tool becomes a product. Pricing a micro SaaS is mostly about limits: what the free tier allows, and where it stops. Both protect you from a cost problem later and give the user a reason to upgrade that is not a nag.
- 06
Launch in one community
In the packageThe tool in front of the people from step 3, and the first paying users.
In this step you launch narrowly on purpose. One community where your profession already talks beats a broad announcement nobody sees. You end with real users, real complaints, and the first money.
5 of the 6 steps are in AI Money
The sample above is a real step, not a teaser — it is the same depth as the rest. The package adds the other 5 for this strategy, and the same treatment for the other eleven.
Your first 7 days
- 1Name the profession and the single recurring task your tool removes.
- 2Find the community where those people already talk and read it for a week.
- 3Write the landing page and the price before writing any code.
- 4Get five people from that community to say what they would pay and why.
Your first 30 days
- 1Ship the narrowest version that solves the task end to end.
- 2Put billing, authentication and rate limits in before the first external user.
- 3Run a security pass on authorisation, key handling and user input.
- 4Charge the first five users real money, even at a discount.
What you need
core means you cannot skip it. The rest only if you need it.
- Claude CodecoreBuild and maintain the application
- Cursorfree planAlternative development environment
- Supabasecorefree planDatabase, auth and storage in one
- Stripecorefree planSubscriptions, invoices and tax
- OpenRouterfree planModel access without vendor lock-in
- PostHogfree planSee what users actually do before guessing
- Langfusefree planTrace and cost-control model calls
Want the research?— what it is, what it costs, and how we scored it
What you can actually watch
Signups arriving, revenue ticking up, error rate staying flat.
What it is
One small paid tool that solves one narrow problem for one profession, built with AI-assisted development and usually with a language model in the core.
Why this opportunity
This has the best recurring economics in its family — scalability 8 of 10 and subscription revenue that compounds — and, unlike template or prompt products, a defensible core: code, maintenance, data and the customer relationship are not raw AI output, so the copyright problem that undermines generated products barely touches it.
Who this is for
For someone who is already inside the profession they are building for, and who accepts that payments, authentication, abuse prevention and support are the job rather than a detail. Not a first business for someone who has never sold anything.
The business model
Monthly subscription, self-service, usually with usage limits. Note the structural difference from classic SaaS: model costs are a variable cost per user, so unlimited plans are dangerous — our research calls this the most common pricing mistake in the category.
How money is made
Recurring subscription revenue minus hosting and model usage. Margin is high but structurally lower than classic SaaS, because every heavy user costs you money every month.
Who pays
A specific profession with one recurring problem — the narrower the better. A tool for "marketers" is a worse business than a tool for compliance officers at insurance brokers.
Finding customers
Communities, professional content, and the app marketplaces of larger platforms. Distribution has to exist before you build; the research is explicit that without a channel, "never" is a realistic outcome.
Delivery
Self-service: signup, use, billing, support. Everything automates except support, which is where you learn what to build next.
Where AI actually helps
Very high in building — that is the entire reason this category is now reachable by individuals — and very high in operation after launch, except support. It does nothing for distribution.
Skills you need
Medium to high. Building is fast now; payments, auth, abuse prevention and support are not. Security is the underestimated risk: fast AI-built applications rarely get a review while touching customer and payment data, and the common failures are unglamorous — missing authorisation checks on API endpoints, keys in the frontend, prompt injection through user input.
What it costs to start
Low: hosting plus model costs. Budget the model spend as a per-user variable from day one, and price so that a heavy user cannot cost more than they pay.
How to price it
Per seat or per usage tier, charged from day one rather than after a free phase. Avoid unlimited plans entirely; cap usage and charge for overage.
Common mistakes
Building before securing a channel. Unlimited pricing against metered model costs. Skipping the security pass — with paying customers, a leak is a notifiable incident, not a learning moment. And solving a problem you have only read about.
Scaling
Scalability 8 against demand 5. Building is easy, which is exactly why competition scored 9 — distribution is the whole game and most of these fail there, not in the code.
The version that holds up
Build an internal tool for one client first, get paid for it, and only productise what several clients demonstrably ask for. That order inverts the usual failure: demand first, product second.
Time to first revenue
2–9 months
Two to nine months to the first paying subscriber, assuming (a) you build for a group you are part of, (b) you charge from day one rather than after a free phase, and (c) you have a distribution channel before you start building. Without a channel, "never" is a realistic outcome — building is not the bottleneck, being found is.
How it scored
Ten axes, scored. Risk scored 6 out of 10, where higher is worse.
The state of this market
Scalability 8 out of 10 against demand of 5. Building is now easy, which is exactly why competition scored 9 — distribution is the entire game, and most of these fail there rather than in the code.
Not sure this one fits you?
Answer a few questions about budget, time and skills and see which of the eighteen match your situation — and which to avoid.
Run the Opportunity Finder