[Image placeholder — hero] Replace with
from-side-project-to-micro-product-hero.webpwhen ready.Graveyard of unfinished side projects vs one tiny shop with an “open” sign.
Field notes, not financial advice. Most products make little money; plan for that and treat wins as upside.
TL;DR
- Building is cheap now. Distribution isn’t. Assistants like Cursor can get you a working v1 in days. They won’t get you customers.
- Narrow wins. One job, one type of user, one clear payoff.
- Charge from day one. Free users tell you what’s nice. Paying users tell you what’s needed.
- Ship ugly, fix what customers complain about.
- Pick a problem you’ll still care about in a year. Products are slow.
Step 1: Find the problem (not the idea)
Ideas are cheap. Look for pain that people already spend money or time on.
| Where to look | What to notice |
|---|---|
| Your own job | The spreadsheet you rebuild every month |
| Forums & communities | ”Is there a tool that…?” posts |
| Existing clunky tools | One-star reviews that ask for the same thing |
| Your service work | Tasks you do for every client the same way |
Best source: repeated service work. If you’ve done the same job for five clients, you already know the spec, the buyer, and the price. That’s where the services path leads.
Step 2: Shrink it
| Too big | Micro-product |
|---|---|
| ”AI assistant for small businesses" | "Turns supplier PDF invoices into a clean CSV" |
| "Learning platform" | "Flashcards from your own lecture notes, in Japanese" |
| "Marketing suite" | "Rewrites one product page for three marketplaces” |
Test: can you explain it in one sentence and demo it in 30 seconds? If not, cut.
Step 3: Build v1 in a week or two
- Boring stack. Whatever you ship fastest in. Hosted services over self-managed servers.
- AI assistant for the grunt work: scaffolding, forms, tests, glue code. You own the architecture and the edge cases.
- Must-haves only: the core job, sign-in if needed, payment, a way to contact you.
- Skip: dashboards, teams, settings pages, dark mode (fine, maybe dark mode).
- Add AI features only where they do the core job. “Now with AI” is not a feature.
Watch your costs. If each use calls a paid model, know your per-use cost before you set a price.
Step 4: Price it
| Model | Good for |
|---|---|
| One-time purchase | Templates, small utilities, no ongoing costs |
| Subscription | Tools used every week or month, with ongoing costs |
| Usage-based / credits | Heavy model-API costs per use |
Price on the value of the job (“saves two hours a month”) rather than your build time. You can almost always lower a price. Raising it is harder.
Step 5: The first ten customers
- Hand-sell. Message the people from Step 1 who described the pain. Offer a demo.
- Build in public. Short posts about what you’re building and why; people buy from people.
- Go where the buyers are, not where builders hang out. Your market isn’t other indie hackers (unless it is).
- Do things that don’t scale: onboard every user yourself, fix their bug the same day.
- Ask every user: “What almost stopped you from paying?”
Kill or keep
After a few months, be honest:
| Signal | Do |
|---|---|
| Paying users, and they’re asking for more | Keep. Double down on the one feature they use. |
| Users, but no one pays | Wrong price, wrong buyer, or not painful enough. Change one thing. |
| No users after real effort | Kill it. Write down what you learned. Next problem. |
A dead project with notes is a lesson. A dead project with no notes is just a tombstone.
30 days
| Week | Do this |
|---|---|
| 1 | Find one problem. Talk to five people who have it. |
| 2 | Build the core job. Nothing else. |
| 3 | Add payment. Ship. Show those five people. |
| 4 | Fix the top complaint. Find five more. |
Bigger picture: Making Money with AI: A Realistic Map.
Build small. Charge early. Keep moving. 🐾