kott®
← Journal

How long an MVP actually takes, and what makes it slip

Most MVPs with accounts and payments take 8 to 16 weeks. Here is where the extra weeks come from, and what to settle before kickoff.

How long does it take to build an MVP? For a product with accounts, payments and a dashboard, plan on 8 to 16 weeks from kickoff to launch, which is two to four months. A lean tool with one workflow and one type of user can ship in 4 to 8. Anything regulated, or heavy on integrations, runs 16 to 24 weeks or more. Those are ranges from published studio guides. Where you land inside them depends on three things you control more than you think.

If you have searched this, you have seen numbers from three days to six months, and some vendors promise 3 to 8 weeks for everything. The short ones come from people selling fast builds, and they assume a single narrow flow with nothing that can go wrong. That can hold for a landing page or a survey tool. It rarely holds for software customers pay for. When someone quotes you a timeline, ask what it assumes. A number with no assumptions attached is a sales line.

The weeks are spread across phases, and the same guides agree on the shape. Discovery takes one to three weeks, design two to four, development six to fourteen, testing one to three, and launch another one to two. Phases overlap, so the sum is not the finish date, but it is a fair picture of where time goes. Skipping discovery does not remove that work. It moves it into development, where each wrong guess costs more.

The first reason an MVP slips is scope. One of those guides puts it plainly: "Can we just add one more feature?" is how a 12-week build becomes a 24-week project. Another says feature creep kills more MVPs than technical problems do. We'd add that an MVP is defined by what you refuse to build. A good studio writes that list down with you before design starts, and says no in writing when something new shows up in week six.

The second reason is waiting on you, and this is the one clients least like to hear. One guide estimates that if you take 48 hours to answer each blocker, and a project has 30 of them, you have added three weeks or more. It does not show its working, so treat the figure as a rough guide, not a law. The direction is right. Another guide notes that if a confirmation takes two days, two days of development capacity sit idle. The fastest builds have a founder who answers within hours, and one person who can say yes or no without a meeting.

The third reason is integrations. They almost always take longer than estimated. Guides give one to two weeks each for payment processors, CRMs and outside APIs. Stripe is usually quicker, around three to five days, while legacy enterprise APIs with thin documentation can eat two to four weeks. Payments and notifications also tend to break late in a build, when the rest of the product is nearly done. Compliance work in fintech or health, and app store review for mobile, add time on top of that.

So before you sign anything, settle four things. Name one owner who answers within a day. Write a short list of what is not in version one. List every integration by name, so none is a surprise in the quote. And ask for a launch date that states its assumption about how fast you will respond. If you want, bring the idea and that not-in-version-one list to a call, and we will tell you which end of the range you are on.

Next readWhat email design costs, and when a template stops paying for itself