MVP Examples: What First Versions Actually Contain

You searched for an example of an MVP and got a list of famous companies. That is what this query returns, and the newest company on the freshest of those lists was founded before an AI builder could produce a working app from a description. Meanwhile the thing you actually want an example of is sitting on your screen: a first version that came out of a prompt over a weekend, which you are not sure counts.

So this page shows the other kind of example. Six applications that already existed and were read at the code level, one row each: what the app was, what it contained on the day it went out, who it met, and what the code showed at that point. None of them is a company legend. All of them shipped, and all of them met somebody.

Three letters, one meaning here: minimum viable product, the first version somebody puts in front of real people. What the three letters stand for, what they do not cover, and the coding pattern that shares them, are settled where the term itself is the subject.

An MVP example is a first version somebody actually put in front of people, described by what it contained. The six below come out of a fixed group of 26 applications read in June and July 2026, and each row records what was inside the app, who it was built for, and what the code showed at the point it was read.

What counts as an MVP example?

An MVP example is a shipped first version described by its contents: which capabilities were really there, what sat behind them, and who used it. A company origin story answers a different question, which is what became of that company in the years afterwards, told backwards from the ending.

Two different things get called an MVP example, and only one of them helps when you already hold a first version of your own.

The first is a founding story. A product started as a directory, or a mailing list, or a short video, and grew into something worth a great deal, and the story gets told from the ending back to the start. These are genuinely interesting and they are the wrong tool for the job in hand, because the part you need is the part they compress into one sentence: what the thing contained on the day it went out.

The second is a description of that first version as an object. Which capabilities were really present. What sat behind them. Who opened it. What happened when they did. That is the shape this page uses, because it is the only shape you can hold your own app up against.

The reason the second kind is rare is that it needs the code. An mvp software development example that consists of a paragraph about a company’s early days can be written from memory by anybody. One that says what the app was made of needs somebody to open the project and read it, and needs permission to do so.

There is a step before all of this that trips people up, and it is worth naming rather than answering here. Whether the thing on your screen is a first version at all, or the stage before one, turns on a distinction with a page of its own.

Why the example lists stop before the AI builders

No application was built or run for this page. Every first version described below was read from a repository that already existed, and the example lists it is set against were opened and dated on 1 September 2026.

The examples of MVPs on the front of this search are all company stories, and six of the eight results on the main query are published by firms that sell app building or investment services. Two of those pages, and a third that ranks on a separate search for the wizard-of-oz technique, were opened twice on 1 September 2026, once as rendered text and once as raw page source with an ordinary browser identity. None of the three is linked here, and the reason is the same for all three: a link from a page about first versions to a company that sells you one would send the reader straight to the seller. They are named instead.

www.antler.co/blog/minimum-viable-product-examples carries a date of 13 November 2023 and lists nine examples: Meta, Amazon, Loom, the iPhone, Oculus, Aardvark, Uber, TikTok and Foursquare. Its own definition of the term reads “A minimum viable product, often referred to as MVP, is something that meets the minimum criteria for the market and customer.” Not one of the nine carries a year anywhere in the page’s text, and not one of them needs to.

appetiser.com.au/blog/minimum-viable-product-example/ is the fresh one. Its page carries the line Last Updated: July 24, 2026, and it lists twenty examples, nineteen of them with a founding year attached; the seventeenth entry is the one that carries none. The oldest year given is 1994. The newest is 2023. So the freshest page on this search, updated in July 2026, answers a 2026 question with a set whose most recent member predates every builder in common use today.

That gap is the finding, and it is fairer to state it as a documented absence than as an accusation. Read against the raw source of both pages on 1 September 2026, the strings Lovable, Bolt, Replit, Base44, Claude Code and ChatGPT each return zero hits, and so do “no-code”, “AI builder” and “AI coding”. These pages are not wrong about their own examples. They are answering a question last asked in a world where producing working software was the expensive part of the exercise.

How far an AI builder carries each part of the job, part by part, is mapped where that argument belongs.

Six apps that shipped, and what was inside them

These six come out of a fixed group of 26 working applications read in June and July 2026: 11 built by other people and read closely, another 10 built by other people and held back for a blind reading, and 5 that the founder had built for his own work. How this cohort was assembled, what each denominator covers, and how the code was read is documented on the page that owns those numbers. None of the six below appears among eight apps from the same cohort, read one at a time at the code level, which is a different set entirely.

No app is named here, and none of them can be. These are live products with real users, and anonymity is the price of reading working code rather than a demonstration.

The freelancer dashboard

This is the purest example of a first version that is all surface. It arrived out of a prompt-to-app builder looking like a finished product: a client list, invoices, charts, navigation, the lot. Open the project and every client and every invoice on screen has been typed into a file inside it. There is no server for the app to talk to, nothing survives a refresh, and nobody signs in, because there is nothing to sign in to. As an example it earns its place precisely because it is honest about nothing: a screen recording of it is indistinguishable from a working business.

The food-delivery marketplace

The checkout worked. You could fill a basket, place the order, and watch it land on the seller’s screen, with the money changing hands at the door. What the first version did not contain was the arithmetic underneath: the count of what a shop still had was never reduced when somebody bought something, and the database held no rule keeping that count at zero or above. A shop with one portion left could take orders for it all evening, and every one of those orders looked accepted to the person placing it.

The golf-shot analytics app

This one worked, and its numbers were the product. What it did not contain was any record of its own structure. The shape of the data, and the rules deciding which player could see which rounds, had all been made by clicking around in the hosting provider’s control panel, and lived there and nowhere else. Nothing in the project could rebuild any of it, nothing could review it, and a change made in that panel left no trace a person could read afterwards. The first version was complete on screen and unreproducible off it.

The multi-tenant messaging platform

The founder built this one. Several businesses shared it, and each of their customers messaged an ordinary number and got an answer back. Messaging providers resend a message when they do not hear back quickly enough, which is normal and expected, and the app had a check for exactly that case. The check looked the message up by an identifier the app had never once written down, so it could never match anything, and a resent message ran the whole sequence again: a second answer to the same customer, a second row in the history. None of that is visible from outside until real messages arrive at real speed.

The AI fitness app

Signing in was real here, on the screens: the pages checked who you were and sent you to a login if you were nobody. Behind those screens, the code that fetched a person’s plan and wrote to their profile never asked who was calling. It used whichever identity the request claimed, and the address of that back end travels inside the app itself. As a first version it contained the sign-in the product needed and did not contain the part where signing in counts for anything.

The browser spam classifier

Not every first version has to be large to count as one. This was a single page with about 138 lines of ordinary JavaScript behind it, and no package file at all, because there were no packages to list. No server, nowhere to store anything, no accounts. You pasted a message in and it told you whether it looked like spam. The judgement itself came from a hosted language-model API that the page called directly, so the product was those 138 lines plus somebody else’s model. Whatever else is true about it, it is a shipped first version, and it is smaller than almost anything the famous lists describe.

Read the six together and the same shape shows up in every one. What the user could see was further along than what stood behind it, and the missing part was a thing nobody had reached yet rather than anything built badly. Reaching it takes a second person, or a review that asks the second person’s questions before one turns up: what happens when two people buy the last item, when a message arrives twice, when a request arrives with nobody behind it. Those are checks you can run before real use, and in this reading they were found by opening the code.

One person put that whole shape into four short sentences after their own first version went out:

launched 25 days ago. 500 downloads. 10 free trials started. All 10 cancelled.

That is an example of an MVP in the only sense this page cares about. It contained enough to be found, enough to be downloaded, enough to start a trial, and not enough to hold anybody past the first one. The lists at the top of this search carry no row shaped like that, because the companies on them are the ones where the next line went differently.

What the famous MVP stories were, and the one part that transfers

The famous examples earned their fame, and it is worth being accurate about them rather than dismissive.

Off the two pages read on 1 September 2026, the recurring cast runs to Amazon, Dropbox, Airbnb, Groupon, Uber, Buffer, AngelList, Duolingo, Spotify, Netflix and Zappos on one, and Meta, Amazon, Loom, the iPhone, Oculus, Aardvark, Uber, TikTok and Foursquare on the other. On the page that dates its entries, the founding years run from 1994 to 2023. These are the stories every guide on this search retells, drawn from what is by now a fairly small common stock.

Read as a group, one thing is true of all of them. Each was a way of finding out whether anybody wanted the thing, using the cheapest method available at the time. A page describing a product nobody had made. An order taken by hand and filled from a shop down the road. A recording of software working, made before the software worked. None of that was clever for its own sake. It was the cheapest available way to ask a question whose expensive answer was a build.

That is the part that transfers: the question rather than the method. And the reason the method no longer transfers is that the price of the answer collapsed. The cheapest way to ask whether anybody wants your product is now the product itself, handed to somebody who is not you, rather than a video or a waiting list, which is a test the famous examples could not have run at that stage even if they had wanted to.

It is also a faster answer, and a blunter one. One person described what came back after theirs went out:

One week ago my friend and I launched our product… About 20,000 impressions… Zero signups

Every famous story has a version of that moment somewhere in it, usually compressed into a clause about early struggles. What none of them has is the part where you already own a working product on the day you ask the question.

Wizard of Oz, concierge, and the techniques built for expensive software

Four names come up whenever somebody asks how to test an idea without building it, and all four are older than the thing on your screen.

www.exponentially.com/wizard-of-oz-mvp sets out the first of them plainly. It describes a Wizard of Oz MVP as what Alberto Savoia’s pretotyping method calls the Mechanical Turk: users interact with a product that looks fully automated, but humans secretly do the work behind the scenes. It gives two worked examples, Aardvark and CardMunch, and it separates the technique from a concierge approach on a single axis, whether the customer knows. In a Wizard of Oz test the person doing the work is hidden and the product appears automatic. In a concierge version the manual service is explicit and the customer sees it happening. As of 1 September 2026, that page renders no publish or update date to an automated read of its source, so nothing here dates it, and like the two pages above it is named here without a link.

The other two go by ordinary names. A landing-page test puts up the page that describes the product and counts who asks for it, with nothing behind the button. A piecemeal version stitches the thing together out of tools that already exist, so that something real happens for a customer without a product existing to maintain.

The first two rows below follow that page’s own comparison. The last two are the ordinary descriptions of the other two names.

Now the part nobody on this search says out loud. All four techniques exist for one reason: building the working thing used to be the slow and expensive part, so the entire craft was in getting an answer without paying for it. Read the classic examples again with that in mind and they turn out to be budget management rather than clever product thinking, and very good budget management.

For the person reading this, that constraint has gone. You can have a working version of most small products by the end of a weekend, which means that for a small product you can already run, a landing-page test usually buys a weaker answer more slowly than the thing it was standing in for. The four techniques are still sound, and they still fit where the doubt is about the whole idea, where a stand-in can be shown safely, or where running the real thing carries a cost you cannot take yet. For the reader who already holds a working version that is safe to hand over, they have become substitutes for something cheaper than they are.

What replaces them is the same question, asked of the product you already hold rather than of a stand-in: give it to somebody who does not know you, and watch whether they come back. That is a harder test to pass, and the reason is worth sitting with. A Wizard of Oz run can only tell you whether anybody wanted the thing, because a person is supplying the quality by hand. A real first version answers that question and the question of whether it holds up, and most of the six above came unstuck on the second one.

How to tell an example from a demonstration

Everything on this page rests on one distinction. A demonstration is a thing you drive. An example is a thing somebody else drove. Four questions separate them, and not one of them requires reading any code.

Has anybody who does not know you opened it alone, with nobody narrating? That is the whole test in one question, and most first versions have not passed it yet at the point their owner starts calling them an MVP. You know which button is safe. That knowledge is invisible to you and it is doing more work than you think.

Does the data in it come from somewhere real? The freelancer dashboard above was full of clients and invoices and none of them existed. A screen can be dense with records and hold nothing, and the check is simply whether a record on screen got there because somebody outside the project put it there.

What happens when it is used wrongly, by accident rather than on purpose? Two people buying the last item at the same moment. The same message arriving twice. A request turning up with nobody behind it. Every one of the six above met a version of that question, and it is the question a demonstration never asks, because a demonstration is used correctly by definition.

When it broke, how did you find out? If the answer is that a customer told you, that is still an example, and a painful one. If the answer is that it has not broken, check the third question again.

One person described their own version of all four in three sentences:

I can’t code. I shipped a site with AI anyway. 5 visitors, 0 sales.

That is an example, and a small one, and it is worth more than a demonstration that has never been contradicted. The person who wrote it knows something now that no amount of clicking through their own app could have told them.

Deciding what the first version keeps and what waits for later is settled on another page. The order of work for turning one of these into something you can hand to strangers is a separate piece with its own steps.

What MVP development means now that a first version arrives out of a builder in a weekend is the wider question this sits under.

Common questions about MVP examples

What is a real example of an MVP?

An MVP is a first version complete enough for a stranger to use on their own and hand you back a real answer, and here is a real one from the reading behind this page: a spam classifier that was one web page and about 138 lines of ordinary JavaScript, with no server, nowhere to store anything and no accounts. You pasted in a message and it told you whether it looked like spam, with the verdict coming from a hosted language-model API the page called directly, and that was the whole product. It shipped, and anyone with the link could use it without an account. What makes it an MVP is that it could be used by somebody who was not its builder, rather than how much of it there was.

What is an MVP in a project, with an example?

In a project, the MVP is the point where the work stops being preparation and starts being evidence. The example of MVP behind this page that shows it most clearly is the food-delivery marketplace. Ordering, checkout, sellers and drivers all worked, and the code showed the gap at the point it was read: buying something never reduced the count of what the shop had left, and nothing kept that count above zero. That is the kind of fact a code review or a two-buyer test finds before a customer does, and it is the kind of fact planning alone does not produce.

What are some famous MVP examples?

The recurring cast on this search, read off two ranking pages on 1 September 2026, runs to Amazon, Dropbox, Airbnb, Groupon, Uber, Buffer, AngelList, Duolingo, Spotify, Netflix, Zappos, Meta, Loom, the iPhone, Oculus, Aardvark, TikTok and Foursquare. On the page that dates its entries, the oldest gives a founding year of 1994 and the newest gives 2023. They are real examples and they are worth knowing. What none of them can show you is what a first version looks like when a builder produced it over a weekend.

What is a Wizard of Oz MVP?

A Wizard of Oz MVP is a product that looks fully automated while people quietly do the work behind it. www.exponentially.com/wizard-of-oz-mvp describes it as what Alberto Savoia’s pretotyping method calls the Mechanical Turk, with users interacting with something that appears automated while humans secretly do the work behind the scenes, and it names Aardvark and CardMunch as worked examples. It differs from a concierge version on one axis: in a Wizard of Oz test the person is hidden, and in a concierge version the manual service is open and the customer knows about it.

What is an example of an MVP in business?

Any first version put in front of paying or potential customers is an mvp business example, and it does not have to be software. A shop taking orders by hand before it has a system is one. In the reading behind this page the clearest one is the multi-tenant messaging platform: several businesses used it to answer their own customers automatically, which is a commercial outcome from the first day it ran. What the code showed was a commercial fact too: a resent message could produce a second answer to the same customer.

Are the classic MVP examples still worth copying?

The question they asked is worth copying. The method usually is not. Every classic example exists because building the working product was the part that cost the most time, so the craft was in getting an answer without building it. That constraint has gone for most small products. If you already hold a working version that is safe to hand over, a landing-page test usually buys you a weaker answer more slowly; if the doubt is about the whole idea, or the real thing carries a risk you cannot run yet, the classic methods still earn their place. Copy the discipline of asking, and where you can, use the product you already have to ask with.

What is the difference between an MVP example and a demo?

A demo is a thing you drive, and an example is a thing somebody else drove. Polish has nothing to do with the difference. Several first versions in the reading behind this page looked more finished than products that had been running for years. What settles it is whether anybody who does not know the app has used it alone and produced a result you did not expect. Until that has happened you hold a demonstration, and its most important property is that nothing has ever contradicted it.

What did these first versions have in common?

Two things, across all six. What you could see was further along than what stood behind it, and every gap was the kind ordinary use exposes rather than anything going obviously wrong; in this reading they were found by opening the code and asking the second person’s questions. Nobody in this group shipped something broken. They shipped something whose missing parts only matter once a second person turns up: stock that has to stay honest across two buyers at once, a message that arrives twice, a request that arrives with nobody behind it. Each of those is a known rule you can exercise yourself before real use, whatever the demand question later says.