From Idea to MVP in 30 Days: A Week-by-Week Plan

Going from idea to MVP in 30 days is realistic for most software ideas, provided the first ten days are spent on validation and scope rather than code. The plan below splits the month into four weeks: prove the problem, cut the product to one job, build only that job, and put it in front of real users with one number to watch. Most 30-day attempts fail in week one, not week three, because the founder starts building before they know which feature is the product. Where one of our agents does part of the work, we say which one and what it writes into Shared Context.

Why most MVPs take three months instead of one

Most MVPs overrun because the founder builds three features when one would have answered the question. An MVP exists to test a single hypothesis: that a specific person has a specific problem and will change their behaviour to solve it. Every feature beyond the one that tests that hypothesis is cost without information.

The second cause is that validation happens after the build, when it is expensive to act on. A founder who learns in week eight that restaurant managers do not schedule staff on a laptop has to throw away a laptop app.

The third cause is tooling. For an MVP the correct stack is whatever you already know, and if you know nothing, whatever has the most tutorials. Our companion piece on the solo founder tech stack covers the buy-versus-build calls.

Week 1: prove the problem exists before you write code

Week one ends with a written statement of who has the problem, how they solve it today, and what that workaround costs them. If you cannot fill in those three blanks from conversations with real people, you are not ready to build.

Days 1 to 2: write the hypothesis. One paragraph. "A [specific person] doing [specific task] loses [specific cost] because [specific cause]. They currently [workaround]." Vague nouns here ("small businesses", "productivity") mean you have not picked a customer yet.

Days 3 to 6: talk to ten people who match the description. Not friends, not other founders. Ask what they did the last time the problem came up and what it cost them. Do not describe your solution. Our guide on running repeatable customer discovery as a technical founder has the interview script.

Day 7: size it. Estimate how many of these people exist, what they spend on the workaround, and what share you could plausibly take. In Founders360 the Market Researcher does this step: it walks the market from total addressable to serviceable to obtainable and writes each figure into Shared Context, where the Funding Finder later picks it up for the market-size slide without being told. On a fictional test company (ShiftPilot, an AI scheduling tool for restaurants) it walked a $2.8 billion TAM down to a $212.6 million SAM and a $4.3 million obtainable slice. The obtainable number tells you whether the month is chasing a business or a hobby.

If ten conversations produce fewer than five people who recognise the problem without prompting, stop. That is a month saved, not a month failed. Our article on how to validate a startup idea with AI covers what to do with a partial signal.

Week 2: cut the product to one job and write it down

Week two ends with a one-page specification a stranger could build from, and a list of everything you decided not to build. The second list matters more.

Days 8 to 9: pick the one job. From your interviews, choose the single moment where the user's workaround hurts most. Your MVP does that moment and nothing else. If the interviews said scheduling takes three hours every Sunday night, the MVP produces a schedule and does not manage time off, send reminders or touch payroll.

Days 10 to 11: define done. Write the exact input the user provides, the exact output they receive, and the one number that proves it worked. For a scheduling MVP: input is a staff list and availability, output is a week's rota, the number is minutes from upload to a rota the manager accepts without editing.

Days 12 to 13: write the technical spec. Even a solo founder should write this down, because writing exposes the decisions you have been avoiding: where data lives, what happens when the user closes the tab halfway through, what the first screen shows with no data. Founders360's Tech Docs Hub drafts this document from what the Market Researcher and Business Guide have already written into Shared Context, so the spec starts from your actual customer rather than a blank template. If you plan to hire, our piece on technical documentation for startups explains what a first engineer needs from you.

Day 14: run a pre-mortem. Write down why the MVP will have failed in 30 days, then fix the top cause now. The AI Red Team does this adversarially in Founders360: on ShiftPilot its first question named a real incumbent and asked what stops a restaurant clicking that incumbent's auto-fill button instead. That question is worth more in week two than in week eight, which is why your AI co-founder should argue with you.

Week 3: build only what the spec says

Week three is the only week with meaningful code, and it ends with the one job working end to end on a real URL, even if the interface is ugly.

Days 15 to 17: the walking skeleton. Build the thinnest possible path from input to output. No authentication, no settings, no empty states. If the output is a rota, hard-code the staff list and produce a rota. Deploy it on day 17 even though nobody can use it yet: deployment problems found on day 17 cost an hour, and the same problems found on day 29 cost the launch.

Days 18 to 20: make the real input work. Replace the hard-coded data with what the user actually provides. This is where most of the unknowns live: file formats, missing fields, people who enter times as "9ish". Handle the three most common cases and reject the rest with a clear message.

Day 21: the honest cut. List every feature you added that was not in the spec. Remove them. Two rules protect the week: no new tools after day 15, and no refactoring, because MVP code is disposable either way.

Week 4: put it in front of real users and measure one number

Week four ends with at least five of the people you interviewed in week one having used the MVP for its one job, and a single number that says whether it worked.

Days 22 to 23: recruit from your interviews. The ten people from week one are your first users. Message each one personally and ask for fifteen minutes. A founder who skipped week one has nobody to message now, which is the real reason the interviews come first.

Days 24 to 27: watch them use it. Sit with them, on a call or in person. Do not explain the product; watch where they hesitate. Record the one number you defined on day 10. Fix only what blocks the one job.

Days 28 to 29: decide. If the manager accepted the rota without editing in under ten minutes, the hypothesis held. If they spent forty minutes fixing it, it did not hold as stated, and the interviews will tell you which assumption broke.

Day 30: write it up. One page: what you believed, what you built, what happened, what you will do next. This is the start of your investor narrative and your first hire's onboarding. In Founders360 the Business Guide keeps this running record and the Command Center shows what each agent has written so far, so the write-up is mostly assembled from what the month already produced.

What to do on day 31 depending on the result

Day 31 has three possible outcomes and each has a clear next step.

| Result on day 30 | What it means | Next 30 days | |---|---|---| | Users completed the job and asked to keep using it | The problem and the solution both hold | Charge money; see our guide on pricing a first SaaS product with no customers | | Users completed the job but did not return | The problem holds, the solution is not painful enough to replace | Interview the non-returners; change the job, not the code | | Users could not complete the job | The solution missed, or the problem was mis-stated | Return to week one with the new interview data |

An MVP with five real users and one measured number is also a stronger pre-seed story than a polished product with none. Founders arrive at Founders360 wanting money (the Funding Finder is our most-used agent), and the ones who raise can name the number that moved. For a blunt read on the pitch before an investor gives you one, the Skeptical VC is free, needs no login, and ends with a verdict naming what to fix.

Frequently Asked Questions

Can a non-technical founder build an MVP in 30 days?

Yes, if the one job can be done with no-code tools, a spreadsheet, or a manual process behind a simple form. Many strong MVPs are a landing page, a form, and a founder doing the work by hand for the first ten users.

How many features should a 30-day MVP have?

One. The MVP does the single job that the week one interviews identified as the most painful moment, and nothing else. Write the excluded features down so the discipline is visibly deliberate.

What if I cannot find ten people to interview in week one?

Then you have found the most important result of the month early: you cannot yet reach your customer. Work on that before building anything. A product for people you cannot find is a product you cannot sell.

Should I charge for the MVP?

Ask for money on day 28 if the one job worked. A verbal yes costs the user nothing; a payment, even a small one, is the only signal that separates politeness from demand.

How does Founders360 fit into a 30-day MVP plan?

Three agents map to the first two weeks. The Market Researcher sizes the market on day 7 and writes the figures into Shared Context. The Business Guide keeps the running plan and the day 30 write-up. The Tech Docs Hub drafts the technical spec on days 12 and 13 from what the other two recorded. All three are on our agents page; the Market Researcher and Business Guide are free forever.

This week: write the hypothesis and book five conversations

Do not open an editor. Write the one-paragraph hypothesis from day 1, with a specific person, task, cost and workaround. Then message five people who match the description and ask for fifteen minutes about the last time the problem came up. If five say yes, the month has started. If none do, you have learned the first thing it was going to teach you, at no cost.