People type this question into Google hoping for a number. Three weeks. Six weeks. A quarter. There is no honest average. Solo founders sell different things to different buyers. What you need is a decision rule: when to stop building and ask for money.
In 2026 that rule points to days, not months. AI writes the boring parts. You can ship a thin path this week. The long MVP is usually you being scared, with a project plan on top. Indiecity is for one person or a team under twenty. You do not get more time because you are alone. You get less time.
The decision rule
An MVP is done when three things are true at once:
- One real person can get the outcome you plan to charge for (even if you do part of it by hand).
- You can say the price out loud without a pitch deck.
- You have names of people who already feel the pain, and you will ask them this week.
If any of those is missing, you are not refining an MVP. You are either still guessing the problem or delaying the ask. Ticket count is not the test. The test is whether someone can get the outcome and whether you asked them to pay.
Done is not “the roadmap is empty.” Done is “I can deliver this outcome for one buyer and invoice them.” Everything else is a later version.
What happens if you wait
In July 2026, Jack Builds wrote on Indie Hackers after four months of solo building. He coded the features. He polished the landing page. He set up onboarding. Launch day: zero paying customers, not one signup. He had never talked to a potential customer before he shipped.
Indie Hackers · u/Jack Builds
I built a SaaS that got 0 paying customers at launchJuly 2026. Four months of building. Launch day: zero paying customers. He never talked to a buyer before he shipped.
His first ten customers came later, when he looked for people already searching, not from feature 47 on the roadmap. Four months of polish did not make the launch safer. It bought silence. Building felt safe. Asking did not.
If you are already deep in a long build and have not asked anyone, stop the feature branch. Write the offer. Name thirty people. Send ten notes. The months you already spent do not get more valuable by adding another month. Building got cheaper this year. That is why the window is days.
Why 2026 is days, not months
Building got cheap. Tereza Tizkova wrote in 2026 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, ad money, or a free way to get attention.
When shipping is easy, spending months on an unreleased MVP is the expensive choice. Lookalike products show up in the feed every week. Your edge is not a perfect v1. Your edge is a specific buyer, a clear outcome, and the nerve to ask before the page is beautiful.
So set a short build window on purpose. A weekend for a path that works. A few days to put a price on a page. Then conversations. If the outcome needs real complexity (regulated data, hardware, multi-party workflows), the thin path is still the part you can do with help for one customer while you learn. Months of solo polish without an ask is the same trap, now that everyone else can ship too.
What belongs in the first version
Only the steps that create the outcome you will charge for. One happy path. One way to start. One way for money to move. You can still do the work: you import the file, you run the report, you hop on a call while software does the boring half.
- The core outcome, delivered end to end for one person
- A price you can say on a call
- A way to take payment (link, invoice, transfer)
- A place to write down what buyers say in their own words
- Enough reliability that you are not lying about what works today
You do not need SSO, a full admin console, five pricing tiers, dark mode, or a blog. You do not need a launch date on Product Hunt. You need proof that someone will pay for the outcome. Build the thinnest version you can charge for, then stop.
What to cut without guilt
- Features you invented because a competitor has them
- Onboarding tours for people who have not paid
- Edge cases nobody named in a real conversation
- A second persona “while you are at it”
- A waitlist in front of something you could sell this week
- Another week of design after the path already works
If a piece of work does not help one named person get the outcome or help you ask them, it is not MVP work. It is comfort work. Put it on a list. Open the list only after someone pays.
A one-week plan
- Day 1. Write the outcome in one sentence. Write the price. Write 30 names of people who might have the pain.
- Days 2 to 4. Build only the path that delivers that outcome. Use your hands where code is slow. Stop when one person could finish it with you.
- Day 5. Put the offer on a page. Payment link live. No waitlist.
- Days 6 to 7. Send personal notes. Book 15-minute calls. Ask for the money when the pain is real.
If someone pays, you have an MVP that matters. If they almost pay, write down the exact objection and fix that, not a random feature. If nobody will take a call, your buyer or your problem is wrong. Either way you learn in a week instead of in a quarter.
Hey [name]. You mentioned [pain in their words]. I can do [outcome] this week for [price]. I will do [the manual or thin step] myself if the product is still rough. Want 15 minutes, or should I leave you alone?
How you get from “someone might pay” to ten people who did is a separate job. How to get your first 10 paying customers without ads is the playbook for the notes, the call, and the ask. Ship the thin path first. Then run that sequence. Do not reverse the order.
How you know to stop building
You can demo the outcome without apologizing for five missing screens. You can take payment today. You have ten people left on the list you have not contacted. That is when you stop coding and start asking.
Busy work looks productive. Refactoring the folder structure. Rewriting the landing page for the third time. Adding a dashboard widget because it looked cool in someone else’s launch. That is how Jack Builds spent four months. It feels like progress. It does not move money.
You can't wait for users to come to you. You have to go out and get them.
An MVP that never leaves your laptop is not minimum and it is not viable. It is a private project. Go get the users.
What to stop doing
- Hunting for a national average of weeks to MVP.
- Treating launch day as the first time you talk to a buyer.
- Building for four months before a single sales conversation.
- Using “not ready yet” when you mean “scared to ask.”
- Adding features so you can avoid writing ten names.
- Confusing a polished page with a paid customer.
Then ship the ask
How long should a solo founder spend on an MVP? Until one person can get the outcome and you can ask for money. In 2026 that should be days for most software products. Months without an ask is how you get a polished launch and zero customers. That is a long lesson you could have learned in week one.
When someone pays and you want to put your name on how you got there, send us the story. When the product is real, put it on the map. You can join Indiecity while you run the week. None of that replaces the thin path or the ask.
Build the path. Put a price on it. Send the notes.
FAQ
Questions people get stuck on
Is there a standard number of weeks for an MVP?
No. Averages hide the real rule. You stop when one person can get the outcome you charge for, and you can ask them to pay. That might be a weekend. It might be two weeks. Months without a single ask is not careful. It is hiding.
What if my product needs more than a weekend to work?
Ship a thinner path. Manual steps, a spreadsheet, a form that emails you, a Zoom walkthrough with a script. The MVP is the outcome, not your architecture. If you cannot deliver the outcome with help for one buyer this week, you do not know the problem well enough yet.
Doesn't a half-baked product hurt my reputation?
Selling a broken promise hurts your reputation. Selling a small, clear outcome and delivering it does not. Tell people what works today and what does not. Early buyers who pay for a specific pain care about that pain, not about your brand deck.
Should I wait until the landing page looks finished?
No. A page with a price, a sentence about the outcome, and a way to pay is enough to start conversations. Jack Builds spent four months building and still got zero paying customers on launch day. Pretty is not proof. Payment is.
When do I add the next feature?
After someone paid and asked for it, or after three people who almost paid named the same missing piece. Do not add features to feel productive. Write the names of people you still have not asked.
What if I am building for consumers, not businesses?
The rule stays the same. Days to a path someone can use, then a real ask. Consumer sales are slower to name one by one, so the thin path matters more. Do not spend months in the editor hoping a launch post replaces conversations.
Is a waitlist an MVP?
No. A waitlist is a list of people who have not paid. If you can deliver something this week, charge for it. If you cannot, run learning calls first and write down what they already do. Do not hide behind a form while you invent screens.
How does AI change the timeline in 2026?
You can build a usable path in days that used to take months. That does not give you permission to polish for longer. It shortens the build window. Ask for money sooner, not later, because everyone else can ship a lookalike too.
What if nobody pays after I ship the thin version?
That is the point of a short MVP. You learn in days, not after four months. Change the offer, the buyer, or the outcome. Do not add feature 47. Talk to the next ten people who already have the pain.
