How Long Does It Take to Build an MVP?

Every published answer to this question is a length measured from an empty folder, and most of them are counted in months. If you are asking because a tool already produced something that runs on your screen, a large part of what those lengths cover has already happened to you, and the number you need is a different number for a different job.

Two finish lines hide inside one question. The first is a version that runs when you click it. The second is a version somebody can pay to use without you standing next to it. Published MVP timelines measure the distance from nothing to the second one.

Seven publishers’ own timeline pages were read for this article, all of them off Google’s first page for how long it takes to build an MVP, an app and a website. Between them they print eighteen separate lengths, counting one for every distinct figure a page puts against a distinct kind of job. Not one of the seven assumes a working first version already exists on the day somebody asks the question, which is why the whole set answers somebody else’s version of it.

Every length on this page was read off the page that publishes it on 1 September 2026, with the publisher named and the date that page carries printed beside the number; nothing here was timed by AxonBuild, and no figure was averaged across two sellers to make a third.

None of the seven is linked here. Four are agencies or dev shops selling the work they are putting a length on, and the other three sell the tools, so each one is named below, address in plain text, unlinked.

Which of the two clocks are you asking about?

Two clocks answer this question and they run in opposite directions. The first is short and getting shorter every year. The second has barely moved, because almost nothing in it is code. Nearly every argument about MVP time is two people quoting different clocks at each other.

Somebody on a founders’ forum asked for it in the plainest possible form: “How long did it take you to build your SaaS from start-to-finish?” Start and finish are the two words carrying the whole question, and neither one means the same event for a person typing into a builder as it did for the agency that wrote the guide ranking above them.

Clock one runs from the idea to something that works. Screens appear, a form saves, you can show it to a friend on your phone. This is the clock the tools compete on, the one every demo video measures, and the one the published figures further down show shrinking.

Clock two runs from that working thing to a product a stranger can pay for while you are asleep. Different people can sign in without seeing each other’s records. Money moves and the receipt is right. When something breaks at two in the morning, it tells somebody, and the somebody it tells can put it back. A demo shows none of it, and none of it got faster because the first version arrived quicker.

The reason the published guides are all months is that they measure both clocks end to end as one line, starting at zero. That is a fair measurement of the question they were written for. It stops being a fair measurement of yours the moment the first clock has already run, because you are standing somewhere in the middle of their number with no way to tell where.

The order those pieces go in is not settled here. This page only says how long the two clocks run.

How long does the first working version take now?

A first working version now takes hours or days for a simple app on the published figures. Base44 publishes hours to days for a simple app built in its own AI builder, against 1 to 3 months for the same simple app coded traditionally, on a page updated 10 August 2026.

Three of the seven publishers print both routes side by side, which matters more than any single number here. A vendor writing about its own speed is the least reliable source imaginable, right up until it also publishes the length of the route it is arguing against, on the same page, in the same table. Base44’s page at base44.com/blog/how-long-does-it-take-to-build-an-app, published 10 May 2026 and last updated 10 August 2026, does exactly that, and it goes one step further: it puts medium-complexity apps at a few days to a couple of weeks in its own builder. The comparison is the vendor’s own, which is what makes it usable.

Network Solutions publishes the same split for websites rather than apps. Its page at networksolutions.com/blog/how-long-does-it-take-to-build-a-website/, dated 10 July 2026, says an AI site builder can generate a new website in 10 minutes and that most users finish in under 2 hours, then puts a custom-designed website at 60 to 200+ hours. Same job, same page, two orders of magnitude apart.

Elementor’s page at elementor.com/blog/how-long-does-it-take-to-build-a-website/, last updated 29 June 2026, is the third. It puts a simple brochure site of one to five pages at 1 to 3 days done yourself with a builder and 1 to 2 weeks done professionally.

Read the three rows together and what they actually show is two different products that have always existed side by side, one generated and one built, with the generated one now arriving quickly enough that people mistake it for the other. What you get out of the tool in an afternoon is real. It runs, it looks right, and for showing somebody the idea it is finished.

Whatever the tool generated will also need reading and tidying before anybody else works on it. How long a cleanup pass takes on generated code is answered where cleaning up what the tool generated is described, and the figure there is not repeated here.

What the published MVP and app development timelines are measuring

Five of the seven publish an MVP or app development timeline as a length running from nothing to launch. Put them next to each other and the spread is wide, though the column worth reading is the third one: the work each page counts before a line of code gets written.

Netguru’s page at netguru.com/blog/mvp-timeline, updated 25 March 2026, puts a typical MVP at three to four months and complex ones at 12 to 24 months. Codevelo, at codevelo.io/blog/mvp-development-timeline and dated 19 January 2026, publishes 12 to 20+ weeks at its complex MVP tier, and every tier it lists opens with a discovery and requirements period followed by a UX and UI design period before anything gets built. Itransition, at itransition.com/services/application/development/timeline and dated 9 June 2026, widens the question from MVPs to applications generally: 3 to 7 months on average, and 7 to 12+ months for complex apps. Makers Den, at makersden.io/blog/mvp-timeline-guide and dated 23 July 2025, opens with 1 to 6 months, with simpler solutions launching in weeks, and separately says it delivers MVPs between 2 weeks and 2 months itself.

Every one of those numbers is honest about what it covers, and the phase lists on the same pages say so plainly. Nobody is hiding anything. The problem is arithmetic on the reader’s side: if you subtract the discovery, requirements, wireframes and interface design that these lengths contain, and then subtract the part where the screens get built, there is no published figure left for what remains, because none of them ever needed to break it out.

That is also why a two-year-old community thread of people answering from their own projects holds the top organic result on this search, above every agency guide beneath it. When the published sources all measure something slightly beside the question, people go and read strangers instead. None of that thread’s numbers appear here, because a search snippet is not a source anybody fetched.

One seller on the cost search hangs a length off every tier it prices, which at least tells a reader what the money is meant to buy time for.

Anybody searching how long does app development take runs into the same wall from the other side. Itransition’s page answers for applications rather than MVPs and lands on the same shape of number, with the same business analysis, design and planning stages sitting inside it before development starts. The vocabulary changes, the measurement does not.

The phrase rapid MVP development sits in this same category. It is a claim about compressing the first clock, sold by people whose published number covers both of them, which is how two sellers can each be describing their real experience and still quote you lengths that do not overlap.

Why the second clock is the one that runs long

What makes the second clock long is the number of separate, unrelated items left on it, and that list barely shrinks when the app is small. Very little of it is difficult code. Most of it is a queue of small jobs that have nothing to do with each other and cannot be done in one sitting.

Somebody who built a Mac application this way counted both the calendar and the hours:

I spent 4 months, 7 days a week, 12-14 hours a day on my vibe coded app to finally get to a stable 1.0.0 release… it now has users including a few paid users.

What is worth noticing in that account is not the size of the effort but what the effort was spent on. This is a person who already had something that ran, working through the distance between running and released, alone, without a list telling them what was still missing. The version number at the end is doing the work in that sentence: it marks the point where the thing stopped being theirs to babysit and became something other people could depend on.

That distance has a name, and what production ready actually means defines the finish line the second clock runs to. What sits inside that last stretch has been counted item by item, with the denominators printed next to each one, on the page about paying somebody to close it out.

One of those items runs on a calendar rather than on the size of the app, and it is the clearest example of why a small MVP and a large one can carry the same amount of finishing work. Packages age whether or not anybody touches the code. In AxonBuild’s fixed study of 26 real applications audited in June and July 2026, 21 of them third-party, the dependencies and supply chain area came out at an average of 34.5 out of 100 among the 20 applications that could be scored for it, and how those 26 audited applications scored area by area carries the full method and every denominator. A two-screen app and a twenty-screen app both sit on a pile of packages that has been drifting since the day the tool picked them, and the work of catching that pile up is set by how long it has been drifting, not by how many screens sit on top.

Two pages here already put a length on that catching-up work for a named builder: the time that work takes on a Lovable app, and the same work on an app a different builder produced. The day and week figures I publish for getting one of those apps ready sit on the two pages that publish them, and this page states none of its own.

One seller publishes its whole finishing run as named stages with a length against each, and the page that prices that kind of work reads that publication line by line.

How long does it take to build a website, and why an app is a different job

A website and a software product are two different jobs with two different clocks. The published website numbers are in hours and days because most websites are pages. The published MVP numbers are in months because a product has accounts, money and state.

Asking how long it takes to make a website and how long it takes to make an app is asking two questions, and the published figures for the first one are small. Network Solutions puts a DIY website builder at 10 to 20 hours and a custom-designed website at 60 to 200+ hours, both read on 1 September 2026. Elementor puts a small business site of five to fifteen pages at 1 to 2 weeks done yourself with a builder. Those are honest lengths for the job those pages describe: choose a template, write the copy, place the images, connect a form, publish.

Nothing in that list has to be true twice at once. That is the whole difference. A page renders the same for everybody who loads it, so the question of whether one visitor can see another visitor’s data does not arise. A product is the opposite: almost every hour on the second clock exists because two different people have to get two different correct answers out of the same system.

This is why a project timeline for website development transfers so badly to software. The stages have the same names, the design phase really is a design phase in both, and then one of them ends at publish while the other one is only starting the part nobody quoted. Somebody asking how much time it takes to build an app who gets answered with a website figure will be off by an order of magnitude, and both people in that conversation will think they agreed. How long it takes to develop an application is the question underneath, and it is the one itransition answers in months.

How long it takes to create a website, to code a website and to design one are the same question asked at three points in that list, and all of them sit inside the hours above. How long it takes to code an app does not, because the coding was never the long part.

Some sellers do not describe their cheapest package by what is in it at all. They describe it by how long it runs, which moves the vagueness somewhere the buyer is less likely to look. How sellers a long way from the buyer price that same window is its own subject.

What actually moves the date

Four things move a finish date, and none of them is the number of screens. Each one is here because it forces somebody to do something that cannot be compressed by working harder.

Money is the first one. The moment a real card is charged, the app has to be right about amounts, refunds, failures and duplicates, and it has to stay right when the provider retries a call. There is no partial version of this. Either the receipt is correct or somebody is doing bookkeeping by hand.

Having more than one kind of user is the second. One person logged into their own data is a short job. An owner, a staff member and a customer looking at overlapping records is a different piece of software, and every screen has to be checked from each of them.

Third is real customer data already sitting in the app. Once actual records exist, every change has to survive contact with them, and the safe way to make a change stops being edit and reload. This is the single biggest reason an app that shipped early takes longer to finish than one that did not.

Fourth, and the one people forget, is anybody outside your control who has to say yes. A store reviewer, a payment provider’s checks, a compliance form, a customer’s own procurement person, a first venue agreeing to try it. Their queue is not your queue, and no MVP development sprint touches it. How long a store takes to look at a submission is somebody else’s queue, and it is measured on the page about store review times.

That last one is where a lot of apparently slow projects actually are. One builder described their position like this:

Started in March with zero programming experience. Zero restaurants signed so far … still pre-launch.

What is pending in that sentence is a list of people who have not said yes yet, and the software may well be sitting there finished while they decide. Every week in that state looks exactly like a week of building from the outside, which is how a project can be late and done at the same time.

How to get a date you can trust for your own app

Nobody can give you a real length for your app without looking at it, and the useful skill is telling a length that was measured from one that was rounded. Three questions do most of that work.

Ask what the number starts from. If the answer is a discovery phase and a design phase, the number is a full-build number and does not apply to an app that already runs. Ask what the number ends at: a demo you can show, an app in a store, or an app taking money from strangers. Ask what is in the middle that has not been listed. A length with no list under it is a guess wearing a calendar.

Then ask for the list before the date. Somebody who has read the code can name the specific things standing between the app and a paying customer, and a count of those things is something you can act on whether or not anybody attaches weeks to it. A date with no list underneath cannot be checked, cannot be argued with, and cannot be partly delivered. The item-by-item contents of that last stretch are counted on the page about paying somebody to finish it, and are not re-listed here.

What that same work costs is a separate number with a separate answer, and no length on this page has a price attached to it. If what you actually want is somebody to carry it the rest of the way, hiring somebody to finish a half-built app covers how that purchase is shaped.

Everything filed under the MVP heading, from what the word is supposed to mean to what having one finished is worth buying, sits together in one place.

The work I do is on apps people have already built with AI tools, which on a timeline question means the first useful thing to buy is not a schedule but one item off the list crossed out. No turnaround is published here, and none of that is an answer to how long an MVP takes.

Common questions about MVP timelines

What is an MVP timeline?

An MVP timeline is a published estimate of how long it takes to get from an idea to a first version real people can use. Every one read for this page measures from nothing: netguru puts a typical MVP at three to four months and itransition puts an average application at 3 to 7 months, both read on 1 September 2026. The word timeline hides where the clock starts, which is the part that decides whether the number applies to you.

How long should an MVP take to build?

Long enough to answer one real question about whether people want it, and no longer. The published answers read on 1 September 2026 run from Makers Den’s 1 to 6 months, with simpler solutions launching in weeks, up to netguru’s 12 to 24 months for complex ones, and itransition puts complex applications at 7 to 12+ months. If your own version is running past those without a paying user, the thing taking the time is usually not the building.

Can you build an MVP in a week?

A version that runs, often yes. Base44 publishes hours to days for a simple app built in its own AI builder and a few days to a couple of weeks for a medium one, read on 1 September 2026. A version a stranger can pay for in a week is a different claim, and it only holds when the accounts, the money and the support path are things you are buying rather than building.

Why are there no prices on this page?

Every length here was read off a timeline page, and none of those pages’ money claims were fetched or checked for this article, so repeating one would be somebody else’s summary of a third party rather than a source.

The other half of this question is what the work costs, and the two answers move together, because the number changes once most of the thing already exists.

How long does it take to code an app?

Less time than any published total suggests, because writing the code is the part the tools have actually shortened. Base44 puts a simple app at hours to days in its own AI builder against 1 to 3 months for the same app coded traditionally, read on 1 September 2026. Base44 does not say where either figure’s finish line sits, so read both as reaching a working version at most. What sits after that, and sets your real date, is a queue of small unrelated jobs that no builder shortened at all.

The order the work goes in, once the first version is out of the tool, is a plan of its own.

How long does the launch itself take?

Launching is its own sequence of steps rather than a day, and what happens after the app is live walks through it in order, including the part where the first week decides what you fix next. The clock that starts on launch day and stops when somebody pays is a third clock, and it is measured on its own page.

How long does it take to build a website compared with an app?

A website is measured in hours and days, an app in months, and the gap is real rather than an accident of who publishes which guide. Network Solutions puts a DIY website builder at 10 to 20 hours and a custom-designed website at 60 to 200+ hours, while itransition puts an average application at 3 to 7 months, all read on 1 September 2026. A page has to be right once; a product has to be right for several different people at the same time.

Does an AI builder make the whole thing faster, or only the first part?

Only the first part, on the published evidence, and the vendors say so themselves. Base44 puts a simple app at hours to days in its own builder against 1 to 3 months coded traditionally, read 1 September 2026, and every figure it publishes about that speed describes getting to a working version. Nothing on any of the seven pages read for this article claims the accounts, money and reliability work got shorter, which is an absence of a claim rather than proof it did not. Much of that work is waiting on other people, such as store review, a payment provider’s checks or a customer’s data, and no code tool shortens a wait.