How to Build an MVP in 30 Days: A Week-by-Week Roadmap
7 min read ยท 2026-10-08
To build an MVP in 30 days, pick one core job your user needs done, cut every feature that does not serve it, choose a stack you already know or a no-code tool, build in weekly increments, and put the product in front of real users by the end of week three. The goal is learning whether people use it, not shipping a polished product.
This roadmap splits the month into five phases: scoping, design, core build, launch to early users, and measurement. It works for technical founders coding the product, non-technical founders using no-code tools, and small teams running a dedicated sprint.
The roadmap at a glance
Goal: Ship a working minimum viable product to real users within thirty days and collect evidence about whether it solves their problem. Duration: 30 days
Scope Definition (Days 1-3)
Reduce the product to one core job and a single success metric.
- Write the one job your user hires the product to do in a single sentence.
- List every feature idea, then cut anything not required to complete that job.
- Define the success metric, such as users completing the core action twice in a week.
- Line up five to ten early users who agreed to try the product in week four.
- Write a short spec with user stories, out-of-scope items and the launch date.
Milestone: A one-page spec with a fixed feature list, success metric and committed test users.
Design and Stack (Days 4-7)
Decide how the product looks and what it will be built with.
- Sketch the core user flow in Figma, Excalidraw or on paper with five screens or fewer.
- Click through the prototype with two target users and fix confusing steps.
- Choose a stack you know, such as Next.js with Supabase, Rails, or Bubble for no-code.
- Use managed services for auth, payments and email like Clerk, Stripe and Resend.
- Set up the repository, hosting on Vercel or Render, and a staging environment.
Milestone: A tested clickable prototype and a deployed hello-world app on your chosen stack.
Core Build (Days 8-20)
Build the core workflow end to end and deploy it continuously.
- Build the core happy path first, from signup to completing the main job.
- Deploy to staging every day so progress is always visible and testable.
- Use UI kits like shadcn/ui or Tailwind UI to avoid custom design work.
- Handle only the most likely errors and leave edge cases for later.
- Hold a short review every three days to cut anything that threatens the date.
Milestone: A test user can sign up and complete the core job on the production URL.
Early User Launch (Days 21-25)
Get the MVP into the hands of real users and watch them use it.
- Add product analytics events with PostHog, Mixpanel or Amplitude for each core step.
- Onboard early users personally through short video calls or screen shares.
- Watch users complete the core job and note every point of confusion.
- Set up a feedback channel such as a shared Slack, Discord or email thread.
- Fix critical bugs within a day and batch smaller issues for later.
Milestone: At least five real users have completed the core job on their own.
Measure and Decide (Days 26-30)
Evaluate results against the success metric and choose the next step.
- Compare user behavior against the success metric defined on day one.
- Interview users about what they would miss if the product disappeared.
- Sort feedback into core problems, nice-to-haves and requests from the wrong audience.
- Decide whether to iterate, expand to more users, change direction or stop.
- Write a short retrospective and plan the next thirty-day cycle.
Milestone: A documented go, iterate or pivot decision backed by usage data and interviews.
Scoping Ruthlessly
Thirty days is only enough if the scope is brutally small. Start with the core job, then ask of every feature: can a user get the main value without this? If yes, it goes on the later list. Settings pages, admin dashboards, team accounts, notifications, integrations and onboarding tours almost always belong there for a first release.
A helpful technique is to write the launch announcement on day one. If the announcement only needs one or two sentences to explain the benefit, the scope is about right. If it needs a feature list, cut further. Fix the date and let scope flex, never the other way around.
- Keep: signup, the core workflow, a way to see results, basic error messages.
- Fake or manual: billing, reporting, data imports, customer support workflows.
- Cut: roles and permissions, themes, mobile apps, multi-language support.
Picking a Stack for Speed
The best MVP stack is the one you can ship fastest with, not the one that scales to millions of users. A familiar framework with a managed backend beats a new technology you want to learn. Popular fast combinations include Next.js with Supabase or Firebase, Ruby on Rails with Postgres, or Laravel. Each gives you authentication, a database and deployment with minimal setup.
Non-technical founders can build credible MVPs with Bubble, Softr, Glide, FlutterFlow or Webflow combined with Airtable and Zapier or Make. These tools handle many marketplace, directory, internal tool and workflow products. If your core value relies on AI, call model APIs directly instead of training custom models during the first month.
Running the Build Sprint
Treat the build as a sequence of thin, end-to-end slices. A rough version of the full user journey working on day ten is more valuable than a beautiful signup page with nothing behind it. Once the full path works, improve the weakest step, then the next. This approach keeps the product shippable at all times.
Protect focus. Block long uninterrupted work sessions, keep meetings to a short daily check-in if you are a team, and use a simple board with no more than three items in progress. When something takes twice as long as expected, decide immediately whether to simplify it, fake it manually, or drop it.
Deploy daily. Continuous deployment to a real URL forces small, working increments and makes it easy to show progress to early users.
Measuring Whether the MVP Works
Decide before you launch what success looks like, so you cannot rationalize weak results afterward. Good MVP metrics measure behavior that signals value: users completing the core action, coming back within a week, inviting a colleague, or agreeing to pay. Signups alone tell you that your pitch works, not that your product does.
Pair numbers with conversations. With a small group of users, qualitative insight often matters more than analytics. Ask what they were trying to do, what almost made them quit, and what they used before. The Sean Ellis question, how they would feel if they could no longer use the product, is a useful prompt for gauging how much they care.
Adapting the Plan to Your Situation
Solo technical founders should lean heavily on templates, boilerplates and managed services, and keep the design deliberately plain. Non-technical founders can follow the same timeline with no-code tools, or run a concierge MVP where they deliver the outcome manually behind a simple interface.
Teams inside larger companies face different constraints: approvals, security reviews and existing systems. Run the MVP as an isolated experiment with a small set of internal or pilot users, agree on the success metric with stakeholders upfront, and avoid integrating deeply with core systems until the idea proves itself.
Common mistakes to avoid
- Letting scope grow during the build blows the deadline, so keep a later list and fix the launch date.
- Choosing an unfamiliar tech stack slows every task, so build with the tools you already know.
- Building custom auth, payments or email wastes days, so use managed services for commodity features.
- Polishing the UI before the core flow works delays learning, so ship the rough end-to-end path first.
- Launching without analytics leaves you guessing, so instrument every core step before users arrive.
- Treating signups as success hides weak engagement, so measure repeat use of the core action.
Frequently asked questions
Is 30 days really enough to build an MVP?
Yes, for most software ideas, if the scope is limited to one core job and you use familiar tools and managed services. Products that require hardware, regulatory approval, complex data pipelines or deep integrations usually take longer. In those cases, use the thirty days to build a concierge or prototype version that tests demand.
What should an MVP include?
An MVP should include only what a user needs to experience the core value: a way to sign up or start, the main workflow, and a way to see the result. Everything else, such as settings, admin tools, team features and integrations, can wait until real usage shows which additions matter most.
Can I build an MVP without coding?
Yes. Tools like Bubble, Softr, Glide, FlutterFlow and Webflow, combined with Airtable and Zapier or Make, can produce functional MVPs for many marketplace, directory, booking and workflow products. You can also run a concierge MVP where you deliver results manually. Move to custom code when no-code limits block the core experience.
How many users do I need to test an MVP?
A handful of well-matched users is enough to learn whether the core flow works and whether people care. Five to ten engaged early adopters from your target audience will reveal most usability problems and value signals. Recruit them before you start building so they are ready to try the product as soon as it ships.
What do I do after my MVP launches?
Compare usage against the success metric you set at the start, interview users, and decide whether to iterate, expand, pivot or stop. If users repeatedly complete the core job, invest in improving retention and onboarding. If they do not, revisit your problem assumptions before adding features. Then plan your next build cycle.