Indiecity

Guide · 17 Aug 2026 · 15 min

Micro SaaS ideas a solo founder can ship in 30 days

Field guide

One problem, one buyer, one month. Not a gallery of invented MRR.

You can open a tab and find fifty micro SaaS ideas before lunch. Most of them list a niche, a stack, and a monthly revenue number nobody can check. That is entertainment. It is not a plan.

In 2026 building is cheap. Tereza Tizkova wrote that you can vibecode your own SaaS instead of paying someone $50 a month for theirs. Pieter Levels said it in June 2026: everyone can build apps with AI. Almost nobody has an audience, the cash for ads, or a free way to get attention. The hard part is not another idea. It is a problem someone will pay you to remove.

This guide is how a solo founder picks one small idea that can ship in 30 days and still be sellable. Indiecity is for one person or a team under twenty. You do not need a venture story. You need a narrow product, a named buyer, and a price.

What micro SaaS means when you are alone

Tyler Tringas used the term for Storemapper: a SaaS aimed at a niche, run by one person or a small team, with small costs, a narrow focus, and no outside funding. Micro is not a cute word for tiny revenue. It is a scope choice. You pick a problem small enough that one person can build, sell, and support it.

Storemapper is the size check. One job: help a merchant put a store locator on a site. One buyer. Recurring software. That is a month-shaped product. If your idea needs a sales team, a mobile app on two stores, and three user roles on day one, it is not a 30-day micro product. It is a company. Cut until one person can own the whole loop: ship, charge, answer email. For the line between this and a hobby repo, read what is a micro SaaS.

Why idea lists fail you

Lists fail for three reasons. First, they invent or borrow revenue figures you cannot verify. Second, they skip the only question that matters for a solo founder: can you reach the buyer this month without ads? Third, they treat ideas like products on a shelf. You pick one, you build it, customers appear. That order fails in 2026, when anyone can ship a clean landing page in a weekend.

In July 2026, Jack Builds wrote on Indie Hackers after four months of solo building. Features, landing page, onboarding. Launch day: zero paying customers, not one signup. He had not talked to a buyer before he shipped. The comments said the same thing: building got easy, finding people who pay did not.

Indie Hackers · u/Jack Builds

I built a SaaS that got 0 paying customers at launch

July 2026. Four months of building. Launch day: zero paying customers. Building was never the hard part.

So you do not start from a list of products. You start from filters that force a sellable idea.

Five filters before you write code

Run every candidate through these. If one filter fails, drop the idea or shrink it until it passes.

  1. Buyer you can name. Write 20 to 30 real people or roles you can actually message. If you only have “marketers” or “founders,” you do not have a buyer yet.
  2. Pain they already pay for. Time, tools, freelancers, or mistakes that cost money. Polite interest is not pain.
  3. Outcome in one sentence. “I send you X so you stop doing Y.” If you need a paragraph, the product is still a platform in your head.
  4. Ship path in 30 days. One core path that works for one user type. No second side of a marketplace. No “and then AI does everything.”
  5. Path to money this month. A price you can say out loud, and a place you can ask. If the only plan is Product Hunt and hope, fail the filter.

The filters are dull. That is the point. They stop you from spending four months building something nobody asked for. A passing idea looks like this: agency account managers lose revision notes in email, they already pay a VA or rebuild a sheet, you can name twenty of them from past jobs, and you can ship a shared checklist with comments in two weeks.

Do not invent ideas. Notice problems

Paul Graham’s rule still holds: the way to get startup ideas is not to sit down and invent them. Look for problems, preferably ones you have yourself. A social network for a broad hobby is the classic trap. A messy workflow one job title complains about every week is closer: few people, deep need.

The way to get startup ideas is not to try to think of startup ideas. It's to look for problems, preferably problems you have yourself.

Look where money and frustration already meet:

  • Your last job: the spreadsheet, the handoff, the report nobody trusted
  • Threads that ask “is there a tool that does X?”
  • One-star reviews that name the missing step, not the missing brand
  • Niche Slack, Discord, or trade forums where people vent in their own words
  • Invoices you already pay for work a thinner product could do

Copy the words they use. Those words become the headline. Do not translate them into startup language. Then cut the product until it fits a month.

Size the product like a month, not a roadmap

Thirty days is a cap on what you build, not a slogan. One user type. One painful step. Login, the core action, a result they can see, a way to pay. That is enough.

Rob Walling’s stair-step method starts the same way: a simple product, often an add-on inside a market that already has buyers (a plugin, an app-store listing, a thin tool next to software they already use). You do not skip to “the platform” because the template looked good on day one.

Cut these on sight:

  • Admin panels for roles that do not buy
  • Mobile apps when a phone browser works
  • Integrations you can replace with a CSV or a manual import for the first ten customers
  • Public feeds, leaderboards, and social layers that do not remove the pain
  • A free plan when you could charge for the outcome

AI helps you write the boring code. It does not choose scope for you. If the model can scaffold five features before lunch, your job is to delete four of them. If you cannot sell the remaining one, it is not an idea yet.

If you cannot sell it, it is not an idea yet

A pretty build with no path to a conversation is a hobby. Before you polish UI, answer three questions on paper:

  1. Who pays? Job title, not a made-up persona.
  2. What do they stop doing when they pay you?
  3. Where can you reach ten of them this month without a budget?

If you cannot answer those, you do not have a micro SaaS idea yet. You have a weekend project. Levels’s point was simple: getting seen is the hard part when everyone can build. Your idea must include how the first buyers hear about you. That usually means rooms you already belong to, a niche you already understand, or a list of names from past work.

When you are ready to ask for money, do not invent a new playbook. Use the same method as how to get your first 10 paying customers without ads: a price, a named list, and a message that asks them to buy. Before you write code, validate the idea.

A 30-day plan that favors selling

  1. Days 1 to 3. Write the offer in one sentence with a price. List 30 names. Write where those people already talk. Kill any idea that fails the five filters.
  2. Days 4 to 7. Talk before you build. Ten short notes or calls about the problem in their words. No pitch deck. Note what they tried last and what broke.
  3. Days 8 to 18. Build only the path that removes the pain you heard. One user type. Payment link live before you call it done.
  4. Days 19 to 25. Send personal notes with the price. Book 15-minute walkthroughs. Ask for payment while they still care.
  5. Days 26 to 30. Ship fixes only for blockers that stopped a paid user. Count paying customers, not features. Rewrite the page with their words.

Keep a simple sheet: names, sent, replied, booked, paid, and the exact phrase they used for the problem. That phrase replaces your clever headline.

Offer line (fill this before you open the editor)
I help [job title] stop [pain in their words] by [one outcome]. It costs [price]. I can start you this week.
Note to someone who has the problem
Hey [name]. You mentioned [messy thing]. I am building a small tool that does [outcome] for [who]. Price is [price]. If that still hurts, can I show you in 15 minutes this week? If not, who should I talk to instead?

What “done in 30 days” actually means

Done is not feature-complete. Done is a live product that can take money for one clear outcome, plus real conversations with the people who should care. Polish only what a buyer needs before they pay.

If day 30 arrives and nobody paid, you still have data. Either the buyer was wrong, the pain was mild, or you never asked. Change one of those. Do not treat a launch post as a substitute for payment. If you are unsure what counts as a yes, read how to tell if people will pay.

What to stop doing

  • Collecting idea lists with fake or unverifiable revenue.
  • Building a platform so the idea feels big enough.
  • Waiting for a unique idea with no competitors.
  • Using a waitlist as proof of demand.
  • Spending the month on branding while the offer has no price.
  • Pitching only in founder rooms when your buyer is not a founder.
  • Starting ads before you know which sentence makes someone pay.

After you pick and ship

The idea is not the win. A paid customer is. Once you have proof that a specific person will pay for a specific outcome, keep talking to the next names. When the story is real and the name is yours, send it to us. When the product is live, put it on the map. You can join Indiecity while you run the month. That gives you people to talk to. It does not pick the idea for you.

Ignore the list of fifty. Pick one problem that passes the filters. Ship the thin version. Ask for the money.

FAQ

Questions people get stuck on

Do I need a unique idea nobody has done?

No. You need a buyer you can name, a problem they already pay time or money for, and a version you can ship in weeks. Competitors often mean the problem is real. Your edge is reach, domain knowledge, or a sharper outcome for one group of people.

What if I only have nights and weekends?

Then the idea must shrink. One outcome. One core path. No multi-role product. Spend week one on the offer and names, not the stack. A smaller product you can sell beats a half-built platform.

Is an AI wrapper a good 30-day idea?

Only if someone will pay for a specific outcome wrapped around the model. Chat with a generic bot is not enough. Name the job (rewrite this invoice follow-up, extract this report field, draft this weekly update for this role). If the buyer cannot say the job in one sentence, the wrapper is a demo, not a product.

Should I sell to consumers or businesses?

For 30 days, businesses are usually easier. You can name the job title, find where they talk, and charge for time saved. Consumers are harder to reach one by one and slower to pay. Either path still needs a price and a direct ask.

What if I cannot code?

In 2026 you can still ship a thin product with AI tools and a simple stack. The constraint is not syntax. It is whether you can talk to buyers and keep the scope small. If you cannot ship a working path in a month, cut features until you can, or pair with someone who can.

How do I know the idea is small enough?

If you cannot describe the first version in one sentence that ends with a price, it is too big. If the first version needs mobile apps, admin for five roles, or a marketplace of two sides, it is too big. One user type. One painful step. One paid result.

Is a waitlist enough validation?

No. Emails are cheap. A waitlist proves curiosity. Money, or a booked call with a price on the table, proves demand. Prefer a payment link or a deposit over a form that collects addresses.

What if ten people already built something like this?

Read their one-star reviews. Talk to people who still complain. A crowded shelf with angry users is often better than an empty shelf with no buyers. Win on a narrower buyer, a clearer outcome, or support that a giant will not give.

When should I drop the idea and pick another?

If you can name 20 real people in the buyer group and none will give you 15 minutes, change the offer or the buyer. Do not spend month two polishing a product nobody asked for. Building more will not fix a dead conversation.

More from the journal