Guide · Costs & timelines

How long does it take to build an MVP? A week-by-week plan for a 6–10 week build

How long does it take to build an MVP app? A week-by-week plan for a 6–10 week build, what adds weeks, app-store delays, and what to prepare before week one.

By Akash Bansal, founding engineerUpdated 4 November 20267 min read

"How long will it take?" is the second question every founder asks me, right after cost. The answers online run from "two weeks with AI" to "11 months". Both can be true, for different projects. Here's the timeline I plan with, week by week, and the things that actually stretch it.

How long does it take to build an MVP?

A focused MVP takes roughly 6–10 weeks from signed scope to launch when one senior engineer builds it. That's the range I quote for my own MVP builds. Focused means one core workflow, sign-up, payments and a simple admin view, on the web or as one cross-platform mobile app.

For context, Clutch's September 2026 pricing guide puts the average app project at about 11 months (Clutch). That covers full app projects, often with larger teams and scopes, not just MVPs. The lesson isn't that one number is wrong. It's that a timeline means nothing until the scope is written down. The simplest way to write it down is a PRD of two to four pages.

These are starting points for a scoping conversation, not quotes. To add up your own feature list in weeks, use the free app cost calculator; the method behind it shows the weight of each feature. The written plan for your build is what fixes the date.

When does the clock start and stop?

Start the clock when the scope is signed, and stop it when real users can sign up. Founders often count from the first call, and builders often count from the first commit. Agree on the definition before anyone promises a date. My plans also include a short scoping step before the build weeks start, so the plan says what ships in each week before any code is written.

What does a 6-week MVP build look like, week by week?

Here's the shape of a focused six-week build. Each week ends with a working demo you click through yourself, not a status report.

Week 0: scope and plan

We turn the idea into a written plan: who the user is, the one job version one does for them, what's out, the data model and the week-by-week schedule. You get one fixed price at the end of it. This is the cheapest week to change your mind, so it's where most of the cutting happens.

Week 1: foundations

The repository, cloud account and domain are set up in your name. Sign-up and login work. The app deploys automatically to a test address, so from now on every change is something you can click. Your first demo is small but real: you can create an account.

Weeks 2–3: the core workflow

This is the part your users came for: the booking, the order, the report, the match. It gets the most time because it's the part that decides whether the product is useful. The demos here are where your feedback matters most.

Week 3: payments

Checkout, receipts and payment events through a hosted provider. Hosted checkout pages keep this to days rather than weeks, and keep card data off your servers.

Week 4: admin and notifications

An admin view so you can see users, fix data and handle support without an engineer. Transactional emails or push notifications for the moments that matter.

Week 5: testing with real users

A handful of real users try the product while I fix what they break. Monitoring, backups and error tracking go live. If it's a mobile app, the store builds go in for review.

Week 6: launch and handover

Production launch, a walkthrough, and documentation that lets any engineer you hire pick it up. Then we decide together: hand over, or keep building on a retainer.

What makes an MVP take longer than planned?

In my experience, most delays don't come from the code. They come from decisions and waiting. These are the usual causes, roughly in order of how much time they cost:

1. Scope that grows without anything being cut. Every new idea is fine if something of the same size comes out. If nothing comes out, the date moves.
2. Slow feedback. A demo that waits a week for your decision adds a week. Block an hour after each demo.
3. A second type of user. Marketplaces need two of everything: sign-up, screens, notifications and edge cases.
4. Waiting on outside accounts. Payment provider approval, logins for third-party services, content and copy you've promised to supply.
5. App-store setup and review. See the next section; it's the one founders most often forget.

How long do the App Store and Google Play add?

Plan for at least two weeks of store-related lead time on Android, plus review buffer on iOS, and start it in week zero, not week five.

• Apple review: Apple says it typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours (Apple). A rejection means fixing and resubmitting, so leave buffer.
• Apple organization enrollment: to publish under your company's name, Apple requires a D-U-N-S number for your organization (Apple). If you don't have one, request it before the build starts.
• Google Play testing rule: personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers, opted in continuously for at least 14 days, before applying for production (Google). That's two weeks you can't compress, so recruit testers early.

This is one reason I often suggest launching on the web first. A responsive web app reaches phones on day one, with no review queue.

Can AI tools build an MVP faster?

Yes, for the first version of the screens and the obvious code. AI coding tools have made prototypes very fast. They haven't removed the slow parts: deciding what to build, handling the cases the happy path misses, security, data and the weeks of real-user feedback. If you've already built a prototype with an AI tool and it's starting to break, I wrote about that choice in rescue, rebuild or keep prompting.

How do weekly demos keep the timeline honest?

They turn a deadline into fifty small checkpoints. If week three's demo doesn't show a working core workflow, you know in week three, not on launch day. A status report can say "80% done" for a month. A working demo can't hide. That's why every build I run has a demo you click through yourself every week.

What happens after launch week?

The first few weeks after launch are when you learn the most, so plan for them before you start. Real users will find bugs that testing missed, ask for things you didn't expect, and ignore features you were sure they'd love. That isn't the build failing. It's the reason you built an MVP instead of the full product. Deciding what to do with what you learn is the last of the eight steps of building an MVP.

Decide in advance who handles that period. The options are the same as for the build itself: the person who built it on a retainer, your first in-house engineer working from the handover docs, or a planned second phase with a new fixed scope. What you don't want is to discover on launch day that nobody is on call. Every build I do ends with documentation and a walkthrough, so whichever option you choose, the next person starts from a written map rather than guesswork.

What should you prepare before week one?

A checklist to save a week or two:

• A one-paragraph description of your first user and the one job version one does for them.
• Your company email and a password manager to share account access safely.
• Accounts in your name: domain, cloud, code repository, payment provider. I can set these up with you; they should still be yours.
• Apple and Google developer accounts started, with a D-U-N-S number requested if you'll publish as a company.
• A list of 12+ people willing to test, if you're launching on Google Play.
• Any brand assets, copy and legal pages you're supplying.
• One hour a week in your calendar for demos and decisions.

Time and cost move together; the same scope decisions drive both, which I break down in what an MVP app costs in 2026. If you want a week-by-week plan for your own idea, that's the output of my scoping step: a written plan and one fixed price. Here's how a build with me works.