How to build an MVP comes down to one rule: fix the calendar, flex the scope. Write down one hypothesis, pick the cheapest kind of MVP that can test it, cut every feature that does not serve it, and plan the weeks backwards from a launch date. Eight weeks is a planning frame, not a prediction. This guide gives the workflow in order, with a week-by-week plan and the decision you make at the end.
Before you learn how to build an MVP: what it is
Atlassian credits Eric Ries with the definition: the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort. The goal is learning, not a smaller version of everything. Two neighbours get confused with it. ScienceSoft describes a proof of concept as a small project that checks a technical idea is feasible, a prototype as an interactive picture of the design, and an MVP as a working product with just enough functionality to release to real users. WeWeb compresses it: a proof of concept validates technology, a prototype validates design, an MVP validates the business idea.
Step 1: Write one hypothesis
Before any scope, write one sentence that can turn out wrong. For example: “Dispatchers at small courier firms will switch from spreadsheets to a shared board if it takes under a minute to assign a job.” The example is invented, to show the shape. It names a user, a behaviour and a test.
Atlassian’s version of this step is to identify the customer pain points first, through surveys and one-to-one interviews, and then to check what competitors already offer. WeWeb adds a useful discipline: solve one significant pain point completely rather than several partially.
How to build an MVP starts here. If you cannot write the sentence, you are not ready to build. Spend the first week on conversations instead.
Step 2: Choose the cheapest MVP that can test it
How to build an MVP does not always mean writing code. WeWeb lists several types, and the choice should follow the hypothesis.
| MVP type | What it is | Use when |
|---|---|---|
| Landing page | A page describing the product, with a sign-up measured | You need to test demand |
| Concierge | You deliver the service by hand to early customers | You need to learn what customers actually need |
| Wizard of Oz | The product looks automated, a person does the work behind it | You need to test the experience before building the engine |
| Prototype | A clickable mockup | You need feedback on flows |
| Single-feature | One core feature, nothing else | The hypothesis is about one job |
| Working application | A coded product with the core flow | The hypothesis needs real use, real data, real accounts |
If a concierge or Wizard of Oz test can answer the question in two weeks, do that first. You may not need to build anything yet. We are a software studio and we say so.
Step 3: Cut the feature list until it fits the calendar
How to build an MVP that fits the calendar is mostly a question of cutting. Take every feature on your list and ask one question: does the first test fail without it? WeWeb recommends a MoSCoW pass (Must, Should, Could, Won’t) and cutting everything that is not a Must. Every feature adds complexity and delays the moment you learn something.
A working cut looks like this:
| Feature | Serves the hypothesis? | Decision |
|---|---|---|
| Account sign-up and login | Yes, users need their own data | Must |
| Create and assign a job | Yes, it is the behaviour being tested | Must |
| Email notification on assignment | Helps, not required for the test | Could, manual at first |
| Reports and charts | No | Won’t, for now |
| Admin panel for roles | No, one role is enough | Won’t, for now |
Then apply the calendar test. Add up what the Musts need and compare it with the weeks you have. If it does not fit, cut scope again. Moving the date is the failure mode this workflow exists to prevent. WeWeb suggests aiming for one to three months (elsewhere on the same page it gives one to four as typical) and treating anything longer as a sign the scope is not minimal. That is one vendor’s view, not a standard, but the logic is sound: a long timeline usually means the scope grew.
Step 4: Write acceptance criteria for each Must
A feature is done when a check passes, not when someone says so. Write each as something you can run yourself: “A signed-in user creates a job, assigns it to a driver, and the driver sees it on the next page load.” Short criteria are better than a long specification.
Knowing how to build an MVP includes knowing how it will be judged. Add one more item that is easy to forget: how you will measure the hypothesis. Name the event (job assigned, sign-up completed) and where it is recorded. WeWeb advises actionable metrics over vanity metrics such as raw page views.
Step 5: Choose the build path
WeWeb, which sells a no-code tool, gives criteria for choosing between no-code and custom development. No-code fits when your team has no developers, when you need to validate before a full build, and when the product is a web app, internal tool or portal where time to first user matters most. Custom fits when your competitive advantage is a proprietary algorithm or technical innovation, or when your team has capacity and the MVP is complex enough to justify it.
Read that as a vendor’s view and decide on your own constraints. Questions that protect you, whichever path you take:
- Does the code live in a repository your organization owns?
- Can the product be moved or extended if you outgrow the first tool?
- Is the data model sound enough to keep, or is this a throwaway?
SCNSoft makes a related point: if the MVP will be improved in iterations rather than rebuilt, its architecture should keep the full product in mind. Decide at the start whether this is a throwaway or a foundation. Our article on when custom software beats off-the-shelf covers the build-versus-buy question in more detail.
How long does it take to build an MVP?
It depends on scope, the build path and how fast decisions are made on your side. ScienceSoft describes discovery and planning as a stage in its own right, and treats a proof of concept or prototype as optional. WeWeb’s guide is to aim for one to three months.
Our plan below uses eight weeks, because it forces scope decisions early. It assumes one core flow, one user role, a small team and one named decision-maker who answers within days. Change any of those and the date moves.
The eight-week plan: how to build an MVP with decision gates
| Weeks | Focus | You hold at the end | Gate |
|---|---|---|---|
| 1 | Hypothesis, interviews, MVP type, feature cut | Written hypothesis, feature table, acceptance criteria | Does the first test fit in the remaining weeks? |
| 2 | Design | Clickable prototype tested with a few real users | Do users complete the core flow without help? |
| 3 to 6 | Build in increments | A running build on staging after each increment, with a demo | Is the core flow working end to end by the end of week 6? |
| 7 | Test and prepare release | Test report, known issues list, production environment in your accounts | Are the Must acceptance criteria all passing? |
| 8 | Launch to a small group and measure | Analytics recording the event you named | Persevere, change direction or stop? |
The phases follow the common SDLC stages that AWS lists: plan, design, implement, test, deploy and maintain. The gates are what makes it an MVP and not merely a small project. Each one is a point at which you may cut scope, change course or stop. A “failed” test is an answer. WeWeb notes that the cost of abandoning an idea after an MVP is far smaller than after a full product.
If you are building a mobile app, add store requirements to week 7. For example, Google requires new personal developer accounts to complete a closed test, with at least 12 testers opted in for 14 continuous days, before production access, according to the Play Console help pages (checked October 14, 2026). That alone can exceed your calendar, so check it in week 1.
What happens after week 8
How to build an MVP is only half the question; the other half is what you do with the result. An MVP has three possible outcomes: the hypothesis held, it did not, or the result is unclear. Decide in advance what each means. If it held, plan the next increment from what users did, not from the original wish list. If it did not, pivot or stop, and treat that as the successful outcome of a cheap test. If it is unclear, change one thing and test again.
However you build an MVP, keep the learning: user quotes, event data and the list of features users asked for that you cut. They are the input to the next scope.
Send the brief, get a written scope
techcraftz puts scope, milestones and the estimate in writing before the first line of code, then hands over the code, the accounts and the keys. If you want help with how to build an MVP for your product, see our MVP development page. If your MVP is the start of a subscription product, the SaaS development page covers the longer path, and the page for startups explains how we work with early-stage teams. Get a written scope, or read more about techcraftz.
Last checked: October 14, 2026. Platform requirements change; verify before you plan a launch.
Talk to us about your project
Tell us what you need. We help you scope the build, the milestones and a realistic estimate.
View services
