Quick answer: you can build a useful MVP in about 12 weeks by choosing one user, one painful problem and one core journey. Spend weeks 1 and 2 on discovery, weeks 3 to 10 building in two week cycles with demos, weeks 11 and 12 on testing and launch. Everything that does not serve the core journey goes on a later list.

Founders usually arrive with a long list. Accounts, dashboards, notifications, an admin area, referral codes, a mobile app, an analytics suite. Every item sounds reasonable. Together they make a product that takes a year, costs far too much and teaches you nothing until the money is gone.

A minimum viable product is not a bad version of your dream. It is the smallest thing that lets a real person get real value, so you can find out whether the dream is worth building. Here is how we approach it.

Before week 1: decide what you are testing

Write one sentence in this form: "We believe that [type of person] will [do something specific] because [problem], and we will know it is true when [measurable result]." If you cannot write that sentence, you are not ready to build. You are ready to talk to customers.

Weeks 1 and 2: discovery and design

  • Interview five to ten people from your target group. Ask how they solve the problem today, not whether they would like your idea.
  • Map the single core journey from first touch to value, in the fewest steps.
  • Sketch the screens on paper or in a design tool and test them with users before any code exists.
  • Choose the technology for speed and for the next two years, not for fashion. Boring, well supported tools win here.
  • Agree the success measure and the date you will review it.

Weeks 3 to 10: build in two week cycles

Break the work into four cycles. Each ends with a working demo you can click through, not a slide deck.

  1. Cycle one: foundations. Sign in, the data model and the first version of the core journey.
  2. Cycle two: the core journey, end to end. The thing users came for works, even if it is plain.
  3. Cycle three: the support pieces. Payments if you charge from day one, emails, a basic admin view so you can see what is happening.
  4. Cycle four: polish and safety. Error handling, performance, security checks and analytics that answer your success question.

Demo every two weeks to a handful of real users. Their reactions steer the next cycle better than any plan.

Weeks 11 and 12: test, fix, launch small

  • Test the money paths first: sign up, pay, receive what was promised.
  • Fix what blocks users. Park what only bothers you.
  • Launch to a small, friendly group before the public.
  • Make sure you can watch what happens: errors, sign ups, drop offs and support requests.

The cut list: what we usually move to later

  • A native mobile app, if a responsive web app can prove the idea.
  • Multiple user roles and detailed permissions, beyond one admin and one user.
  • Advanced reporting and dashboards.
  • Social login, referral programs and gamification.
  • Complex integrations. Use a manual process or a simple export at first.
  • Pixel perfect custom animation.

Cutting is not a sign of low ambition. It is how you protect your runway while you learn what to build next.

What not to cut

  • Security basics. Hashed passwords, validated input and backups. Fixing a breach costs far more than preventing it.
  • Analytics that answer your question. A launch without measurement is a guess.
  • A clean foundation. Cheap shortcuts in structure become expensive rewrites after your first customers arrive.

How much should you expect to invest?

It depends on complexity, team and integrations. A focused MVP generally sits at the lower end of custom development budgets. Our cost guide lays out the factors, and you can run the quick estimator on our custom software development page for a directional range.

After launch: the part founders skip

Week 13 is where the real work starts. Read the numbers, call the users who left, and choose the next two week cycle from evidence. Many successful products look quite different from the first MVP, which is exactly why it should be small.

If you would like a technical partner for this journey, from requirements to deployment to running in the market, read about how we work with founders.

Frequently Asked Questions

How long does it take to build an MVP?

For a focused product, around 8 to 14 weeks is realistic with a small experienced team. Complex integrations, regulation or heavy design needs can extend that.

What features should an MVP include?

Only what is needed for one type of user to complete one valuable journey, plus basic security and measurement. Everything else belongs on a later list.

Should my MVP be a web app or a mobile app?

Start with whichever your users already use for this task. A responsive web app is often the fastest way to test, and you can add a mobile app when the idea is proven.

How do I know if my MVP is successful?

Decide the measure before you build. It might be the number of people who finish the core journey, repeat usage in the second week, or willingness to pay. Review it on a set date.