Entrepreneur

Launch a Micro-SaaS

8 weeks · 3 milestones

Build and ship a focused tool that solves one problem for one audience.

Part of: Business & Management · Proves for: Founder

Milestone map

3 milestones

Identify the problem and build in public

2–4 weeks

Identify the specific, narrow problem your micro-SaaS will solve and begin building in public. Micro-SaaS is defined by a specific constraint: the entire product should be buildable by 1–2 people, serve a clearly bounded audience, and charge a recurring subscription. The 'build in public' requirement exists because the feedback loop before launch is the most valuable phase of a micro-SaaS: people who are interested in the problem will comment, pre-register, or challenge your assumptions — which is better signal than private development. Building in public means publishing at least one update about the product (on Twitter/X, LinkedIn, an indie-maker community, or a newsletter) before the product ships.

Proof required

Share a written description of the problem you are solving: the specific audience (not 'small businesses' but 'solo email marketing consultants who use Mailchimp but don't have time to A/B test their own campaigns'), the specific friction they experience, and why existing solutions don't solve it. Share a link to or screenshot of at least one public build update you have published — a tweet, a post on IndieHackers, a LinkedIn post, or a newsletter update.

What gets checked

The audience is specific enough that a stranger could name whether they are in it.
The friction is named precisely — 'they don't have time to X' is weaker than 'they can't do X without Y, which takes Z hours, and the cost of that time exceeds the cost they're willing to pay for a tool'.
At least one public build update is shared — the link or screenshot must be from a real public post.

Common mistakes

Audience is too broad: 'productivity tool for professionals' — micro-SaaS requires brutal narrowing of the audience.
No public build update — private building without public signal means no feedback loop before launch.
Problem description is 'this would be convenient' rather than 'this is genuinely painful' — micro-SaaS succeeds on pain, not convenience.

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

The audience must be specific — ask 'if you saw 100 people walking down the street, how many would be your target customer?' If the answer is 'most of them', the audience is too broad.
The public build update must be real — request the link; a screenshot of a private document does not count as 'build in public'.
The problem must be genuinely painful, not merely convenient — ask 'what does your target customer do today to solve this problem?' The existing workaround's friction is the best proxy for how painful the problem is.

You'll sign in first, then come straight back here.

Ship the product — 10 paying customers

4–10 weeks

Ship the micro-SaaS and reach 10 paying customers. 'Paying' is the operative word: 10 free users is product validation; 10 paying users is business validation. The price point does not need to be the final price — an early-bird $10/month that you plan to raise to $29/month is fine — but money must change hands. The 10-customer milestone is the proof that the problem is real enough that people will pay to have it solved.

Proof required

Share a payment processor screenshot showing 10 or more active subscriptions (Stripe, Paddle, Gumroad, or equivalent — showing recurring active subscribers, not one-time purchases). Share a link to the live product (it must be publicly accessible). Write one sentence on where your first 10 customers came from: what channel, what action you took to find them.

What gets checked

10 active subscriptions shown in a payment processor — not 10 signups, not 10 free users.
Product URL is live and publicly accessible.
Customer acquisition channel is named specifically — 'we posted on IndieHackers and got 8 of the 10 from that one post' is specific; 'word of mouth' is not.

Common mistakes

10 free users presented as the milestone — free users validate that the product works; paying users validate that the problem is worth solving.
Product is not live — a screenshot of a demo or a Figma prototype is not a shipped product.
Customer channel is 'personal network' without specifics — this is fine as a first channel, but should name the specific relationships and how they converted.

Powstik Guide

A shipped micro-SaaS with ten paying customers.

Steps

Ship the smallest version that solves one pain.
Charge from day one.
Onboard each customer personally.
Screenshot active subscriptions.

Template

Product URL:
Price:
Active paying subscriptions:
Screenshot ☐

What gets sent back

Free users counted.
Friends paying as a favour.
No payment evidence.

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

The payment processor screenshot must show active recurring subscriptions — check the status column, not just the count.
The product URL must be live — attempt to access it during the review.
The acquisition channel should be specific enough that it is reproducible — 'I emailed 20 people from the IndieHackers community and 3 converted' is reproducible; 'people just found it' is not.

You'll sign in first, then come straight back here.

Reach $500 MRR — describe the churn rate and next growth lever

6–14 weeks

Reach $500 in Monthly Recurring Revenue. $500 MRR from 10+ paying customers is the proof that the micro-SaaS is a viable small business rather than a successful experiment. The final reflection asks for the churn rate and the next growth lever — because $500 MRR reached by churning and replacing customers is categorically different from $500 MRR reached by retention, and the difference defines whether this is a business or a leaky bucket.

Proof required

Share a payment processor screenshot showing $500+ in monthly recurring revenue. State your current monthly churn rate (what percentage of paying customers cancel each month). Write 100 words on the next growth lever you plan to pull — the specific action that you believe will move MRR from $500 to $2K.

What gets checked

$500+ MRR in a payment processor screenshot.
Churn rate is stated specifically — '0 cancellations in 3 months' is acceptable; 'low churn' is not.
Next growth lever is specific — not 'grow the audience' but 'submit to 5 niche communities in the target audience segment and track conversion from each'.

Common mistakes

Churn rate absent — the sustainability of $500 MRR depends entirely on whether customers stay.
Next growth lever is generic: 'improve marketing' or 'get more customers' is not a growth lever.
Revenue is from non-recurring sources (one-time add-ons, consulting) — MRR requires recurring subscriptions.

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

Churn rate must be stated — ask for the number of customers who cancelled in the last 3 months divided by the starting customer count.
The next growth lever must be specific enough that you could evaluate in 4 weeks whether it worked — 'post in 5 communities' is evaluable; 'increase visibility' is not.
Compare the M2 ($10 customers) and M3 ($500 MRR) screenshots — they should be consistent: 10 customers at an average of $50/month is $500 MRR; the numbers should add up.

You'll sign in first, then come straight back here.

Part of

Business Model Mastery →

Related outcomes

Milestone map

3 milestones

Identify the problem and build in public

2–4 weeks

Proof required

What gets checked

The audience is specific enough that a stranger could name whether they are in it.
The friction is named precisely — 'they don't have time to X' is weaker than 'they can't do X without Y, which takes Z hours, and the cost of that time exceeds the cost they're willing to pay for a tool'.
At least one public build update is shared — the link or screenshot must be from a real public post.

Common mistakes

Audience is too broad: 'productivity tool for professionals' — micro-SaaS requires brutal narrowing of the audience.
No public build update — private building without public signal means no feedback loop before launch.
Problem description is 'this would be convenient' rather than 'this is genuinely painful' — micro-SaaS succeeds on pain, not convenience.

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

The audience must be specific — ask 'if you saw 100 people walking down the street, how many would be your target customer?' If the answer is 'most of them', the audience is too broad.
The public build update must be real — request the link; a screenshot of a private document does not count as 'build in public'.
The problem must be genuinely painful, not merely convenient — ask 'what does your target customer do today to solve this problem?' The existing workaround's friction is the best proxy for how painful the problem is.

You'll sign in first, then come straight back here.

Ship the product — 10 paying customers

4–10 weeks

Proof required

What gets checked

10 active subscriptions shown in a payment processor — not 10 signups, not 10 free users.
Product URL is live and publicly accessible.
Customer acquisition channel is named specifically — 'we posted on IndieHackers and got 8 of the 10 from that one post' is specific; 'word of mouth' is not.

Common mistakes

10 free users presented as the milestone — free users validate that the product works; paying users validate that the problem is worth solving.
Product is not live — a screenshot of a demo or a Figma prototype is not a shipped product.
Customer channel is 'personal network' without specifics — this is fine as a first channel, but should name the specific relationships and how they converted.

Powstik Guide

A shipped micro-SaaS with ten paying customers.

Steps

Ship the smallest version that solves one pain.
Charge from day one.
Onboard each customer personally.
Screenshot active subscriptions.

Template

Product URL:
Price:
Active paying subscriptions:
Screenshot ☐

What gets sent back

Free users counted.
Friends paying as a favour.
No payment evidence.

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

The payment processor screenshot must show active recurring subscriptions — check the status column, not just the count.
The product URL must be live — attempt to access it during the review.
The acquisition channel should be specific enough that it is reproducible — 'I emailed 20 people from the IndieHackers community and 3 converted' is reproducible; 'people just found it' is not.

You'll sign in first, then come straight back here.

Reach $500 MRR — describe the churn rate and next growth lever

6–14 weeks

Proof required

What gets checked

$500+ MRR in a payment processor screenshot.
Churn rate is stated specifically — '0 cancellations in 3 months' is acceptable; 'low churn' is not.
Next growth lever is specific — not 'grow the audience' but 'submit to 5 niche communities in the target audience segment and track conversion from each'.

Common mistakes

Churn rate absent — the sustainability of $500 MRR depends entirely on whether customers stay.
Next growth lever is generic: 'improve marketing' or 'get more customers' is not a growth lever.
Revenue is from non-recurring sources (one-time add-ons, consulting) — MRR requires recurring subscriptions.

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

Churn rate must be stated — ask for the number of customers who cancelled in the last 3 months divided by the starting customer count.
The next growth lever must be specific enough that you could evaluate in 4 weeks whether it worked — 'post in 5 communities' is evaluable; 'increase visibility' is not.
Compare the M2 ($10 customers) and M3 ($500 MRR) screenshots — they should be consistent: 10 customers at an average of $50/month is $500 MRR; the numbers should add up.

You'll sign in first, then come straight back here.