How long to build an MVP: realistic timelines and what slows them down

The short answer

These are orientation figures for a focused team building one product, not promises. At EVA-X our median MVP takes about four weeks; a simple prototype in AI Build can be faster, and a platform with several roles takes longer.

Look at the right-hand column. It explains why two MVPs with the same amount of code can launch a month apart: one waits for a payment provider, the other doesn’t. Build time and time to launch are different numbers, and a plan needs both.

Where the weeks actually go

1. Scoping: from idea to an agreed list of modules

A few days to two weeks. This is where the product is split into modules, the core flow is written down, and the “nice to have” list moves out of version one. A first estimate can take seconds — ours takes about 15 — but agreeing the scope takes as long as the answers to the team’s questions take. The fastest projects are the ones where one person can answer those questions the same day.

2. Contract and first payment

Usually a few days, and easy to forget, but nothing starts before it: in our contracts the timeline begins once the contract is signed and the first payment arrives. If your company needs a week for internal approval, put that week in the plan.

3. Design

One to three weeks, often overlapping with the start of development. A product built from a proven component system needs wireframes and a few key screens; a product that competes on experience needs a full visual design before the screens are built. If you already have a brand style, design moves faster; if it has to be created from scratch, plan separate time for it.

4. Building in modules

The bulk of the calendar. Good teams don’t build “the whole MVP” and show it at the end. They deliver module by module — sign-up, the core flow, payments, the admin — and each one arrives for review as soon as it is ready. That way problems show up in week two, not in week eight.

5. Review and fixes

Every module needs your review. With us you have 7 calendar days to accept a module or send it back with a reasoned list of fixes; if you do neither, the module is deemed accepted. A client who reviews within a day or two can take a week or more off the calendar compared with one who uses the full window every time.

6. Launch

Domains, production hosting, analytics, the payment provider switched from test to live mode, store submission for mobile apps. Store review for a first release usually adds a few days, and sometimes more if the reviewers have questions. Don’t forget the legal pages: app stores and payment providers won’t let a product through without terms and a privacy policy.

What makes MVPs late

Code is rarely the main reason. The usual suspects:

• Scope that grows during the build. Every “small” addition shifts the modules after it. Keep a list for version two and add to that instead.
• Slow decisions. A question that waits a week for an answer costs a week. Name one person who decides, and give them time for the project.
• Third parties. Payment provider onboarding can take days or weeks. App store developer accounts for organisations need company verification — Apple, for example, asks for a D-U-N-S number, as its enrollment page explains. Partner APIs need keys and test environments that someone else controls.
• Content and data that aren’t ready. Product texts, prices, legal pages, the catalogue to import. Developers can’t invent them.
• Unclear acceptance. If “done” was never defined, every review becomes a negotiation. Agree what each module must do before it is built.

How to get to launch faster

Much of what speeds up an MVP sits on the client’s side of the table:

• Register accounts early and in your company’s name: domain, hosting, payment provider, Apple and Google developer accounts.
• Start payment provider onboarding in week one, not in the week before launch.
• Appoint one decision-maker who answers within a day.
• Prepare content in parallel: texts, prices, images, terms and a privacy policy.
• Review each module as soon as it arrives.
• Keep a “version two” list and say no to additions during the build.
• Agree acceptance criteria for each module before work starts.

How the platform changes the calendar

• Web app. The shortest path: no store review, and updates go live the moment they are deployed.
• Mobile app. Add developer account setup, store listing materials — screenshots, descriptions, privacy details — and review for the first release; plan a buffer of about a week. Later, with React Native and Expo, many fixes can ship over the air without waiting for a new review. The mobile calendar in full is in how long mobile app development takes.
• Telegram Mini App. No store review and no install, but a bot to set up, Telegram’s own rules for payments, and testing inside the Telegram apps.
• Web plus mobile. If you need both, consider launching the web first and the app a few weeks later on the same backend. Real users test the core flow sooner, and the app benefits from what they find.

Signs that a proposed timeline is unrealistic

• One delivery at the very end, with nothing to review before it.
• No time set aside for your reviews and the fixes that follow.
• No line for payment provider onboarding, store accounts or store review.
• A fixed date combined with a scope that is still open.
• A plan that assumes instant answers from your side, but never asks who will give them.

A good plan is boring to read: modules, dates, who does what, and buffers where third parties are involved.

Does AI make MVPs faster?

It makes writing routine code faster: screens, forms, standard integrations. It does not speed up decisions, payment provider onboarding, store review or your content. That is why the build formats differ in pace as well as price: AI Build is the fastest path for prototypes and internal tools, AI + DEV balances pace with engineers owning the architecture and QA, and DEV takes the time senior engineers need for systems that cannot afford to fail. More in AI Build, AI + DEV or DEV.

A realistic six-week plan

Take a hypothetical single-flow web MVP: a booking tool for independent tutors, where students book and pay for lessons and tutors manage their schedules.

A plan like this holds only if the right-hand column holds. When such a plan slips, look at the right-hand column first.

The same plan with mobile apps

Say the tutors also want iOS and Android apps in the first release. The product moves into the multi-role or mobile row, and the plan changes in predictable places:

• Week 0: the Apple and Google developer accounts are registered in your company’s name; organisation verification runs in the background.
• Weeks 1–6: the same modules, now with app screens, push notifications in place of some emails, and testing on real devices.
• Weeks 7–8: store listing materials, the first submission, answers to the reviewers’ questions.
• About a week of buffer for a rejection or a question about payments, sign-in or privacy.

For this hypothetical version, eight to ten weeks is a realistic plan, inside the six-to-twelve-week band. Launching the web version first and the apps a few weeks later on the same backend gets real users into the core flow sooner.

Speed versus what you can’t skip

There is a version of “fast” that costs more later. Skipping tests on payments, leaving access rules for “after launch” or launching without analytics saves days now and loses weeks after the first incident. A fast MVP is narrow, not careless: it does fewer things, and does them properly. If the deadline is fixed — an investor meeting, a trade show, a season — cut scope, not quality, and say so at the start, so the plan is built around the date.

How we fix the timeline

The timeline is part of the estimate and of the contract, next to the price. It starts when the contract is signed and the first payment arrives, and it moves only through an approved change request or for reasons the contract names, such as delays on the client’s side. You see every module’s progress in your cabinet as it moves. To plan the budget alongside the calendar, read how much an MVP costs; to keep the scoping step short, read how to write a brief a studio can price. More on our approach: MVP development.