My MVP Is 80 Percent Done: What That Number Is Reporting

An MVP that is 80 percent done is a piece of software in its first version, already built and already running, whose owner believes it is nearly finished. One owner in a public builder community described where theirs had reached:

I’m basically trying to improve extraction of payroll and I’m having trouble getting the program to correctly extract all the information during a page break and also just general row ownership. It works well but its not perfect. I have no programming background.

The 80 percent figure is a report about elapsed time, not about remaining work. It gets produced at the moment the visible part of the app stops changing. The oldest name for the same feeling is a maxim from 1985 in which two nineties add up to one project.

Read that quote again for the order of the sentences. The job is named precisely: payroll rows, page breaks, which row belongs to which record. Then comes the verdict, which is that the thing works and is not finished. Then the reason it stays that way. Nobody in that position is short of detail about their own app. What they are short of is a way to turn the detail into an amount, and a fraction is the only unit that seems to fit.

Nothing on this page was timed by AxonBuild. The three outside readings of the last stretch were read on 1 September 2026, each carrying the date it publishes and the name of whoever published it, and one of them is a maxim from 1985 rather than a measurement. AxonBuild’s own study of 26 applications audited in June and July 2026 records what was missing in each one and never how many days anybody spent, so no time figure here is AxonBuild’s. Nothing was run or rebuilt in order to write this, and no seller was asked how long anything takes.

What the “80 percent done” number is actually reporting

The number reports the share of the build that has been visible so far. It rises while screens keep appearing and stops when they stop, which is well before the work does. That is why owners who have never spoken to each other arrive at almost exactly the same fraction.

The mechanism is worth spelling out, because it is not a failure of attention. While the app is being built, every session produces something you can look at: a page appears, a button starts working, a table fills with your own data. Progress is legible, and the fraction climbs with it. Then the visible part stops changing, because everything left to do happens where nobody can look. The fraction stops too, and it stops at whatever it had reached.

Another owner advertising for help put a number on what was left and added that it ought to be straightforward. The number is the tell, not the work.

The oldest written version of this belongs to programming folklore rather than to research. The Jargon File entry for the Ninety-Ninety Rule states it as: “The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.” The entry attributes it to Tom Cargill of Bell Labs and says it was popularised by Jon Bentley’s September 1985 Bumper-Sticker Computer Science column in Communications of the ACM, where it carried the name Rule of Credibility. That entry sits at catb.org/jargon/html/N/Ninety-Ninety-Rule.html, credited rather than linked because on 1 September 2026 the host served the page over a certificate that does not cover it and the text was read from the raw response instead. The page carries no version or date stamp of its own, so no edition of the Jargon File is claimed here. The 1985 column itself, at dl.acm.org/doi/10.1145/3532.315103, refused both an automated and a raw read on the same day, so the attribution above rests on the Jargon File entry rather than on a direct reading of the column.

The joke is that the two nineties come to 180, which is arithmetic nobody would accept from an estimate. It survives because it describes the experience correctly. Both halves felt like the whole job while they were happening. An owner who says 80 is doing the same thing the maxim does, which is reporting on the part that has already been lived through and assuming the rest resembles it.

What the fraction measures is the share of the building you were able to sit and watch.

Why the last 20 percent of a software project cannot be sized

The remaining calendar resists being sized in a specific, measured way: most individual guesses turn out fine, and the total still runs long, because a small number of items blow up badly enough to carry the average on their own.

Erik Bernhardsson’s post Why software projects take longer than you think: a statistical model, published 15 April 2019 and read on 1 September 2026, puts a shape on that. He models the ratio of actual time to estimated time as a log-normal distribution and checks it against a public dataset of estimated and actual task times, published in a GitHub repository. The result he reports: “The median blowup factor turns out to be exactly 1x for this dataset, whereas the mean blowup factor is 1.81x.”

Sit with the gap between those two numbers. A median of 1x means the typical item landed on the time somebody guessed for it. A mean of 1.81x means the average item did not, because a few items ran far enough over to drag the whole set. Both statements describe the same dataset. That is why an owner can look back at a build in which almost every individual step went roughly to plan and still be nowhere near finished, and why asking somebody how long the rest will take produces an answer that is honest about each piece and wrong about the sum.

One builder put the shape of it plainly: the first working version arrived in a fraction of the time an assistant had predicted, and then the remainder swallowed several times longer than the part that had felt like progress.

The practical consequence for somebody holding a fraction is that the fraction cannot be converted into a calendar by multiplying anything. If 80 percent of the elapsed feeling has been used, the arithmetic that produces a remaining fifth of the time is the arithmetic the maxim is making fun of. The distribution is the wrong shape for it.

Why does building with an AI tool make the number less reliable?

An AI assistant makes the fraction less trustworthy rather than more, and the belief that it helped survives the evidence against it. In a randomised controlled trial published 10 July 2025, METR found that developers allowed to use AI tools took 19 percent longer, and still believed afterwards that the tools had sped them up.

METR’s write-up, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, read on 1 September 2026, reports it in these words: “When developers are allowed to use AI tools, they take 19% longer to complete issues.” The same page records what the participants expected and what they concluded. Before the trial, “developers expected AI to speed them up by 24%”. Afterwards, “they still believed AI had sped them up by 20%”. The design was a randomised controlled trial with 16 experienced developers working on 246 issues in large, mature open-source repositories.

The three numbers matter in that order. The prediction was wrong, the outcome was the other way round, and the belief did not move to meet the outcome. A self-report about progress is exactly the kind of judgement that trial found unreliable, and 80 percent is a self-report about progress.

The limitation belongs in the same paragraph, because the study states it plainly and the sellers quoting it usually do not. METR writes that it does “not claim that our developers or repositories represent a majority or plurality of software development work”. These were experienced developers on mature codebases they already knew. Somebody without a programming background, working on a first version an AI tool wrote for them, is not that population, and nothing in the trial says how the effect would land for them. What transfers is narrower and still useful: the belief about the speed-up was measured against the outcome and did not match it.

Why your search returned advice about cutting features

Two search results pages were pulled on 1 September 2026 for the two ways people type this question, and neither one is written for somebody who already built the thing.

The first, for the phrase about an MVP being 80 percent done, is mostly a homonym field. Five of the nine organic results are the same three letters meaning something else: a basketball award, a video game thread about earning the title in a match, a health insurer, a disc sports brand and a federal reporting programme. Three are about software first versions, and two of those three answer the question of which features to build rather than what to do about the ones you already built. molfar.io, in a post dated 1 May 2025, argues that “approximately 20% of your product’s features will generate 80% of its value” and describes itself as selling custom software development and IT consulting. tappable.co.uk, in a post dated 4 August 2026, argues that most first versions carry too many features and invites readers to send in their feature list so it can be trimmed. The third is a post about cutting a build timeline by 80 percent, which is a question for somebody who has not started. The remaining result, beratungadvisors.com, dated 16 October 2023, is a financial advisory firm using the term as a metaphor for leadership, and it discusses no software.

The second search, for the last stretch of a software project, returns the same aphorism in five forms across Facebook, Quora, Stack Overflow, Reddit and Hacker News, plus three general project posts and one consultancy publication. theomarproject.com, dated 19 August 2020, argues that the final stretch of a successful project is the hardest to finish, and its worked examples are painting a room, moving house, car manufacturing and putting up a skyscraper. It is a good post and it is not about code. Reddit refuses an automated read, so nothing from those threads is characterised here beyond the fact that the threads exist and repeat the aphorism.

That is why the search felt useless. Advice about choosing fewer features is aimed at somebody standing in front of an empty repository. You are standing in front of a full one.

Here is what this page actually rests on, and what each source cannot be stretched to say.

None of the three was written about your app, and none of them was written by anybody selling you the finishing work. That is most of why they are worth reading.

The move that replaces the percentage

The replacement is a count of named items, and the counting has already been done by somebody else. Somebody has already gone through applications in this exact state and counted what was missing in each one, item by item, which is a far more useful thing to hold than a fraction.

A count works where a fraction does not because it survives being read by a stranger. Nothing in it depends on how the build felt to the person who lived through it, which is the entire content of the fraction. Getting one costs you no code reading at all. The named items themselves, counted application by application, belong to the page about paying a developer to finish an app that already runs.

It also tends to correct an assumption owners make about why the last stretch is slow. The instinct is that the code the tool produced must be bad, and that the remaining time will go on straightening it out. Across the 21 third-party applications in the June to July 2026 ledger, Maintainability and Evolvability came out at an average sub-score of 61.1, one of the stronger areas rather than one of the weak ones, with any pillar an application had none of left out of its average instead of being marked zero. The code the tools write is generally workable. What tends to be absent is the set of parts nobody watched being built, which is a different problem and a differently priced one. Those applications were reviewed by automated analysis with human-verified findings, and the dataset is published along with how that cohort was picked and how the sub-scores were worked out.

Finding and paying the person who does the remaining work, and what to put in front of them first, belongs to the page that covers the hiring, and this page stops at what the number in your head is worth. If that is where you are, read hiring somebody to close out a half-built app, and what they will want from you first next.

What changes once you stop quoting the number

Three things change, and none of them requires you to learn anything technical. You stop bidding against yourself in your own head, you can see which of the remaining items the builder you already pay for can still close, and the calendar stops being something you carry alone.

You stop negotiating against yourself. A fraction invites the other person to guess what it contains, and their guess runs larger than the truth, because the safe guess always does. A list of named items removes the guessing on both sides of the conversation.

You can also see which parts are still tool work. Some of what is left is the kind of thing the builder you already pay for does perfectly well, and paying a person for that is money spent on nothing. Deciding to pay somebody for the rest of it is the next question, and it comes with its own vocabulary, its own sellers and its own way of arriving at a price. What finishing an MVP contains as a purchase belongs to the page named in those exact words.

And the remaining calendar stops being a mystery you carry alone. How long a first version takes to build from nothing is a separate question, and it is answered from what sellers publish rather than from anything measured here. Everything that goes into building a minimum viable product, from the first idea to the version other people actually use, sits above this one question.

Common questions about an MVP that is 80 percent done

What does it mean when an MVP is 80 percent done?

An MVP at 80 percent means the visible part of a first version stopped changing and its owner wrote down where the feeling had reached. The figure records elapsed effort rather than an inventory of what is left, which is why it does not convert into a date or a price.

Why does the last part of a software project take so long?

Because the remaining items are the ones nobody watched being built, and because a small number of them run far over while most run to plan. Erik Bernhardsson’s 2019 model of estimates against actual times reports a median blowup factor of 1x and a mean of 1.81x on the dataset he used, which is that pattern in one line.

Is the 80 percent figure ever right?

Occasionally, by coincidence. The figure lands right when the remaining items happen to be small and already named, and it has no way of being reliably right, because nothing was counted to produce it. Treat a correct 80 as a lucky guess rather than as evidence the method works.

Is the number less reliable if an AI tool built the app?

Yes, and by more than owners expect. The tool compresses the visible half of the work and leaves the invisible half untouched, so the fraction climbs faster than the project does. METR’s July 2025 trial also found experienced developers took 19 percent longer with AI tools while believing the opposite, which is a warning about self-reported progress generally.

How do I work out how much time is actually left?

You do not work it out from the fraction. You replace the fraction with a short list of named, yes-or-no items about your own app, and then ask somebody to price the list. The list is answerable without reading code, and it converts into a calendar in a way a percentage never does.

Will the tool that built it close out what is left?

For some of the remaining items, yes, and for those it is the cheapest option you have. The parts it struggles with are the ones with no visible surface to check against, because the tool works from what it can be shown and so do you. Naming the items is what tells you which group each one is in.

Should I say my app is 80 percent done when I ask somebody for a price?

Give the named items instead. A fraction makes a seller price the risk of everything it might be hiding, and that risk gets priced high because the seller has no way to bound it, so quoting a percentage usually costs you money rather than saving you time.

Anyone quoting from a description rather than from a look at the code is guessing too, so it is worth knowing what this kind of work costs before the conversation starts: what an hour of this work costs, and what a whole job costs sets that out.

What changes once the percentage stops moving?

The percentage stopping is the signal that the visible work is finished, not that the app is. It is the right moment to write down the named items rather than to keep pushing the number, because everything after this point is invisible progress that no fraction will record.

Most owners keep quoting the number long after it stopped meaning anything, because it is the only summary of the app they have that fits into a sentence. Writing down the named items gives them a second one, and that is usually the thing that ends the stall.