TL;DR
The Groupon MVP was a WordPress blog. In November 2008, after ten months building a platform called The Point that nobody used, Andrew Mason took a stock WordPress install, changed the branding, posted one local deal a day as a blog post, and embedded a Flash widget from The Point so the deal only “tipped” once enough people signed up. When a deal tipped, a FileMaker Pro script generated a PDF coupon for each buyer and Apple Mail sent them out, hundreds at a time, by hand. The first deal was two-for-one pizza at Motel Bar, the restaurant in the building. About twenty people bought.
It took roughly a month to put together. Seventeen months later the company was valued at $1.35 billion; two years after that it was the largest internet IPO since Google.
The rest of this post is the detail: what The Point got wrong, what signal made them pivot, exactly what the blog did and what the humans did, what it validated, what it did not, and what a founder testing a business model in 2026 can copy from it.
What people mean when they say “the Groupon MVP”
Groupon is one of the few MVP stories with a proper primary source. Andrew Mason gave a long, unguarded interview to Mixergy in July 2010, while the company was still private and before anyone had reason to tidy the story up. Eric Ries then used it as a case in The Lean Startup, and the details in the two accounts match. The dates, numbers and quotes below come from those.
“The Groupon MVP” means the version that ran from November 2008 to roughly the middle of 2009: a rebranded blog, a borrowed widget, a desktop database and an email client, operated by a handful of people in Chicago. During that time Groupon was already a real business taking real money. It was not a landing page or a prototype. It was the full product, assembled out of parts that already existed instead of built.
That makes it the textbook piecemeal MVP: the entire user journey delivered by stitched-together tools with humans as the glue. It is also, unusually, a pivot story and an MVP story at the same time, and the two halves explain each other.
The Point: ten months of getting it right
Groupon did not start as an idea about deals. It started as a failure about collective action.
In 2007 Mason, then a graduate student in Chicago, took $1 million from Eric Lefkofsky, whom he had worked for at a printing company called InnerWorkings, and built The Point. The idea was the tipping point applied to the web: you pledge to do something, boycott a company, fund a cause, buy something as a group, but only if enough other people pledge too. Nobody acts alone; the campaign “tips” when it reaches a threshold.
Mason has been precise about what went wrong, and the first part is timing. They spent from January to November 2007 building it, “to get everything just right”, in his words, instead of getting something started and letting users say whether it worked. When it launched it did too many things: activism, fundraising, group buying, events. Users could not tell what it was for. Campaigns drifted. One that Mason remembers gathered 211 supporters and went nowhere.
His later verdict on the whole thing is the sharpest line in the story: The Point should have been a book, and Groupon should have been the website. The concept was interesting enough to write about. It was not specific enough to use.
This matters for the MVP that followed, because the lesson Mason took was not “build a deals site”. It was “never again spend ten months building before finding out”. That is the origin of the one-month constraint everything else in this story sits inside. The why MVPs fail guide lists over-building before learning as the most common cause; The Point is the case study.
The pivot signal
The Point did produce one thing worth having: evidence of what people would actually use a tipping mechanic for.
Among the drifting campaigns, a pattern showed up. Users were organising group buys. Someone would set up a campaign to get twenty people together to buy the same bicycle so they could ask the shop for a discount. Another for magazine subscriptions. Nobody had told them to; the platform was built for activism and they had repurposed it for saving money.
Lefkofsky pushed hardest on this. The question was how to act on it. The obvious move was to add a “collective buying” tab to The Point. Mason’s insight was to do the opposite: instead of letting users set up their own buying campaigns on a general-purpose platform, Groupon would curate one deal, in one city, every day, and point the whole audience at it. Concentrating everyone on a single offer was what made the threshold reachable and the discount worth a merchant’s while.
That is the pivot: same mechanic, a different product wrapped around it, chosen because users had already demonstrated the behaviour. The pivot or persevere guide covers how to make that decision deliberately; Groupon made it by noticing what people were doing anyway.
What the Groupon MVP actually was
Having spent ten months on The Point, Mason gave Groupon about a month. Here is the complete build, piece by piece, in his own description: they took a WordPress blog, skinned it to say Groupon, and every day did a new post with the deal embedded. He called it totally ghetto, and he was not being modest.
- The site: a stock WordPress blog with the theme edited to say Groupon. The domain was getyourgroupon.com, because groupon.com was taken.
- The deal page: a blog post. One a day. The write-up was the product page.
- The tipping mechanic: the Flash widget from The Point, embedded in the post. It counted sign-ups and showed whether the deal had reached its minimum. This was the only piece of custom code in the MVP, and it was borrowed from the failed product.
- The coupons: a FileMaker Pro database on a Mac. When a deal tipped, a script generated one PDF coupon per buyer.
- The delivery: Apple Mail. The PDFs were sent to buyers as attachments, from a desktop email client, by a person.
- The audience: a mailing list of about 500 people, mostly from the office building on the Near North Side of Chicago and the people around it.
- The marketing: printed postcards, handed out in the building’s lobby.
There was no account system, no checkout in the modern sense, no merchant dashboard, no city selector, no mobile anything. There was a blog post, a counter, and a person with a database and an email client.
The first deal: Motel Bar, twenty pizzas
The first Groupon was two pizzas for the price of one at Motel Bar, a restaurant on the ground floor of the building where the team worked. Around twenty people bought it.
That number is the point. Twenty vouchers for a restaurant downstairs, sold to a mailing list of neighbours with postcards, is not a business. It is a signal: people who received a daily email about a local deal opened it, understood the mechanic, and paid. The threshold worked. The merchant, who had risked nothing because the deal only paid out if it tipped, was happy to be paid for customers who showed up.
Eric Ries quotes Mason on the early deals, and the quote is the best one-paragraph description of a piecemeal MVP that exists. They sold T-shirts on the first version of Groupon, and in the write-up they said: this T-shirt will come in the colour red, size large; if you want a different colour or size, email that to us. They did not build a form for sizes. They put a sentence in a blog post and handled the replies by hand. In Mason’s words, it was enough to prove the concept and show that it was something people really liked.
The mechanic that made it work
It is easy to focus on the tools and miss that the Groupon MVP tested a specific, clever business model, and the tools were chosen to test that model and nothing else.
Three things about the model were doing the work.
The merchant carried no risk. A deal that did not tip cost the restaurant nothing. That made the sales conversation easy enough for a handful of people, Mason included, to sign up local merchants by phone and in person, which is how supply was built with no sales software and no track record.
The threshold created urgency for buyers. You wanted the deal to tip, so you told friends. The mechanic that had been abstract on The Point became a reason to forward an email.
Groupon was paid before the merchant was. Buyers paid when the deal tipped; the merchant was paid later, minus Groupon’s share of roughly half. The MVP was cash-flow positive per deal from the pizza onward, which is not something most MVPs can say.
None of that needed a platform to prove. It needed a post, a counter, and money changing hands.
Seven months of doing it by hand
Mason has said that from launch until about July of the first year, the company was “just scrambling to grab the tiger by the tail”. That is the manual period, and the stories from it are the useful part.
The T-shirt sizes went by email, as above. When a deal sold well, the coupon delivery did not scale with it. Mason’s example: they would sell 500 sushi coupons in a day, and then send 500 PDFs to people with Apple Mail, at the same time, from a desktop. Someone sat at a Mac and did that.
Merchants were sold one at a time. Around seven people, Mason among them, did the outreach in the early months: walking into businesses, phoning, explaining a mechanic that did not yet have a name. Every deal on the site in those months existed because a person had persuaded a merchant to try it.
And the site stayed a blog. A blog post per day, in one city, for months, while the subscriber list grew from 500 to tens of thousands and the daily coupon count went from twenty to hundreds. The proper platform, with accounts, checkout, city pages and automated fulfilment, was built during 2009, once the model was beyond doubt and the manual work had become the constraint on growth.
The sequence is the same as DoorDash’s a few years later: assemble, run it by hand until you are the bottleneck, then build. The difference is that Groupon’s manual version was already transactional software, just not custom software.
What the numbers looked like after
The MVP period ends around the middle of 2009. Everything after is context, and it goes fast.
- 2009: expansion beyond Chicago to Boston, New York and Toronto, then a new city every few weeks.
- April 2010: a $135 million round from Digital Sky Technologies valuing the company at $1.35 billion, seventeen months after the pizza deal.
- August 2010: Forbes called it the fastest-growing company ever.
- October 2010: 150 cities in North America, 100 elsewhere, 35 million registered users.
- 2010 revenue: over $700 million, from nothing two years earlier.
- December 2010: Google offered roughly $6 billion (reported as $5.3 billion plus a $700 million earn-out). Groupon said no on 3 December.
- 4 November 2011: IPO on Nasdaq, raising about $700 million at a valuation near $12.7 billion, the largest internet listing since Google in 2004.
What the Groupon MVP validated, in order
Like every good MVP, it answered questions in the order of how cheap they were to answer.
1. That the mechanic worked outside The Point
From the first deal. Twenty strangers understood “this only happens if enough of us buy” and bought. Cost: a month of assembly.
2. That merchants would say yes
From the first weeks of selling deals by phone. A no-risk offer to a local business was easy to close, which meant supply could be built by a few people with no software. Cost: the founders’ time.
3. That the economics closed per deal
From the money. Groupon collected from buyers when a deal tipped, kept about half and paid the merchant later. Every tipped deal was profitable on its own terms, and the sushi day proved it held at 500 vouchers. Cost: nothing extra.
4. That it repeated
From doing it daily for months. A daily deal is a habit product, and the only way to know whether people open the email on day 60 is to send it for 60 days. Cost: seven months of a person at a Mac.
Only after all four did they build the platform. And notice what was never validated by the MVP: whether merchants would come back for a second deal, and whether buyers redeemed at a rate that kept merchants happy. Those questions got answered later, expensively, and they are why Groupon’s later history is complicated. An MVP proves what it is built to prove.
Why it worked, and where the legend gets it wrong
It worked because it was a pivot from evidence, not from a guess
The month-long build gets the attention, but the reason a one-month assembly could find product-market fit is that ten months of The Point had already shown users repurposing the mechanic for discounts. Groupon was the second experiment on a question the first had half-answered. A founder who copies the month and skips the observation is guessing with a faster stopwatch.
It worked because the manual version was the real product
Buyers of the Motel Bar deal got a real voucher and real pizza. Merchants got real customers. Groupon took real revenue. The blog was ugly and the fulfilment was a person with an email client, but nothing was simulated. That is what separates a piecemeal MVP from a landing page MVP: the landing page tests interest, the piecemeal version tests the business.
It worked because the only custom code was already written
The tipping widget was the one thing that could not be bought off the shelf, and it existed because The Point had built it. Everything else, the site, the database, the email, was a tool anyone could install in an afternoon. The no-code MVP guide makes the general case; Groupon made it in 2008 with worse tools than are available now.
It worked because they charged from the first deal
Twenty people paid for pizza. That converted “would you use this” into “will you pay for this” on day one, which is the question that matters. A free version of the Groupon MVP would have told them people like discounts, which they already knew.
Where the legend gets it wrong
The legend says Groupon was “built in a month”. It was assembled in a month, and then run by hand for seven, and the manual months are where the learning happened. The legend also tends to skip The Point entirely, which reverses the lesson: the story is not “move fast”, it is “you already spent ten months moving slow, now spend one month finding out”. And the legend rarely mentions that the piecemeal MVP validated demand and per-deal economics but not retention or merchant repeat rates, which is the part of Groupon’s story that later went wrong. The tool that proves one thing does not prove the next thing. MVP validation is about knowing which question you have actually answered.
Groupon next to DoorDash and Dropbox
Three famous MVPs, three different types, and the type was chosen by what needed proving.
| Dropbox | DoorDash | Groupon | |
|---|---|---|---|
| MVP type | Explainer video | Concierge | Piecemeal |
| What existed at launch | A video of a product that did not work yet | A landing page, PDF menus, a phone number | A rebranded blog, a borrowed widget, a database, an email client |
| Who did the work | Nobody; the video did | The founders, driving | The founders, generating and emailing vouchers |
| Money on day one | No, a waitlist | Yes, $6 a delivery | Yes, twenty pizza vouchers |
| What it proved | People want this enough to queue | People will pay for delivery; the unit economics | The tipping mechanic works; merchants say yes; deals are profitable |
| Time before real code | Months | About six months | About seven months |
Dropbox could not be assembled from tools because its value was a piece of engineering that did not exist; a video was the cheapest way to test whether anyone cared. DoorDash’s value was food arriving, which a person can deliver as well as an app. Groupon’s value was a transaction with a mechanic, which existing tools plus one widget could run for real. The rule: pick the MVP type by what part of the value cannot be delivered without building it. For Groupon that part was a counter. The full set of cases is in MVP examples.
How to copy the Groupon MVP in 2026
Groupon’s tools were WordPress, FileMaker and Apple Mail because that was 2008. The method translates directly, and the modern parts are better. This is the playbook for a founder testing a transactional model, a deal, a subscription, a marketplace with a twist, without building the platform.
Step 1: find the behaviour before the product
If you have an existing product, audience or community, look for the thing people are doing with it that you did not design for. Groupon’s pivot came from campaigns users created on The Point. If you have nothing yet, the equivalent is customer conversations and the idea validation work that finds a problem people are already solving badly.
Step 2: reduce the model to one mechanic
Groupon was: one deal, one city, one day, tips at a threshold. Write your model in a sentence that short. If you cannot, you are not ready to test it, because you will not know which part the result validated. The MVP scope guide is about getting to that sentence.
Step 3: assemble the loop from tools
A page (any site builder), a way to take money (a Stripe payment link or a checkout tool), a list (any email tool), and a spreadsheet or lightweight database for the manual step. If your model has one piece of custom logic, the way Groupon’s had the counter, build only that, or fake it with a form and a person until you cannot. The piecemeal MVP guide has the full toolkit and the step-by-step for wiring it.
Step 4: charge from the first transaction
Do not run a free version to see if people like it. Run the paid version to see if they pay. Groupon’s first twenty customers paid for pizza; every question after that was about scale, not about whether the thing was wanted. If your model has a merchant or supply side, make the offer to them no-risk, the way a deal that does not tip cost the restaurant nothing.
Step 5: run it by hand, and count
Send the emails yourself. Generate the vouchers, or the confirmations, or the matches, by hand. Keep a tally of the numbers the platform will one day automate: conversion from email to purchase, tip rate, redemption rate, repeat rate, time per fulfilment. Groupon’s manual period is where they learned what the platform needed to do; the build-measure-learn loop is the discipline for turning that into decisions rather than anecdotes.
Step 6: build when the manual step is the ceiling
For Groupon that was 500 PDFs in a day from Apple Mail. For you it will be whatever step a person cannot do faster. That is the moment to scope a real build, and it will be a smaller build than you would have specified before, because seven months of running the loop has already shown you which features nobody used. That is what a rapid MVP build is for: the first custom version, scoped from evidence.
When the Groupon approach does not apply
A piecemeal MVP is the right tool when the value can be delivered by existing tools plus people. It is the wrong one in a few recognisable situations.
When the value is the engineering. If your product is the thing that cannot be bought, a model, an algorithm, a device, a new kind of interface, there is nothing to assemble. Dropbox could not be stitched together from tools; that is why it was a video. A thin real build or a prototype is the honest test.
When the manual step would never survive at scale, even in principle. Emailing 500 PDFs is unpleasant but a platform obviously replaces it. If your manual step is something like “an expert personally reviews each case”, you are running a concierge MVP, which is fine, but be clear that it validates demand for the outcome, not for a product that can deliver it without the expert.
When trust requires the real thing. Regulated money, health, identity. A customer evaluating whether to trust you with those is evaluating the system, and a blog with a form is a system they will not trust.
When the question is retention, not demand. The Groupon MVP proved people would buy a deal. It could not prove merchants would run a second one or that the fifth email got opened like the first. If those are the questions your idea lives or dies on, the piecemeal MVP is a first step, and you should decide up front what the second step measures.
What happened after, and what it does not teach
Groupon’s later story is well known and mostly not about the MVP. The company scaled the manual sales model into thousands of salespeople, expanded into hundreds of cities in two years, restated its accounting before the IPO, and fired Mason in February 2013. Merchant repeat rates and buyer fatigue turned out to be the constraints, and neither had been in scope for the seven months on the blog.
Two things from that are worth taking. First, an MVP that proves demand and per-transaction economics has not proved the business; it has earned the right to test the next question, and founders who treat the first yes as the last one build on a half-answer. How investors evaluate an MVP is largely about whether the founder knows which questions remain. Second, the blog itself did not last, and was not meant to. The platform that replaced it was rebuilt again as the company grew. When to rebuild your MVP and MVP technical debt cover that transition; the piecemeal version’s job is to be replaced with something scoped by what it learned.
Conclusion
The Groupon MVP was a WordPress blog with a borrowed counter, a desktop database and an email client, assembled in a month by a founder who had just spent ten months building something nobody used. It sold twenty pizza vouchers on its first day, 500 sushi vouchers on a good day a few months later, and ran by hand for about seven months before a platform existed. Seventeen months after the pizza it was worth $1.35 billion.
The transferable lesson is not the tools and it is not the speed. It is the sequence: notice the behaviour, reduce the model to one mechanic, build only the piece you cannot buy, charge from the first transaction, run the loop by hand until the manual step is the ceiling, and be honest about which question the result answered. Groupon did the first five well and skipped the sixth, and both halves of that are instructive.
If you have a transactional idea and are working out how much of it needs to be built before you know, that is a conversation we have most weeks as an MVP development company: sometimes the answer is a platform, and often it is a page, a payment link and a person first. Start it here.
Related guides
- Piecemeal MVP, explained
- The DoorDash MVP
- The Dropbox MVP
- Pivot or persevere
- Landing page MVP
- No-code MVP
- Pre-sales MVP
- MVP examples
- How to build an MVP
Frequently Asked Questions
What was the Groupon MVP?
A WordPress blog, rebranded as Groupon, that posted one local deal a day in Chicago from November 2008. A Flash widget borrowed from Andrew Mason’s previous startup, The Point, counted buyers and showed whether the deal had reached its minimum. When it did, a FileMaker Pro script generated a PDF coupon per buyer and the team emailed them out with Apple Mail. It took about a month to assemble and ran that way for roughly seven months.
What was Groupon’s first deal?
Two pizzas for the price of one at Motel Bar, the restaurant on the ground floor of the building where the team worked in Chicago. About twenty people bought it. Marketing was a mailing list of around 500 people and printed postcards handed out in the lobby.
What was The Point and why did it fail?
The Point was Mason’s first startup, launched in November 2007 with $1 million from Eric Lefkofsky. It let people pledge to act, boycott, donate, buy as a group, only if enough others pledged too. It took ten months to build and did too many things, so users could not tell what it was for. Mason’s own verdict was that The Point should have been a book and Groupon the website.
How did Groupon pivot from The Point?
Users on The Point had started creating campaigns to organise group purchases, of bicycles and magazine subscriptions, to get a discount, which the platform was never designed for. Rather than add a group-buying feature, Mason kept the tipping mechanic and built a new product around it: one curated deal, in one city, every day, so the whole audience concentrated on a single offer.
Was the Groupon MVP a piecemeal MVP?
Yes, it is the canonical example. A piecemeal MVP delivers the full product by stitching together existing tools with people filling the gaps. Groupon’s site, database and email were off-the-shelf; the only custom code was the counter, and that was reused from The Point. Real money moved from the first deal, which separates it from a landing page test.
How long did it take to build the Groupon MVP?
About a month, compared with the ten months, January to November 2007, that Mason had spent building The Point. The speed was deliberate: having over-built once, he wanted the second product in front of users before spending anything on a platform.
What did the Groupon team do by hand?
Generate and email every coupon (Mason’s example is 500 sushi coupons sent as PDFs through Apple Mail in one day), handle T-shirt sizes and colours by reply email, sign up merchants by phone and in person with a team of about seven, and write and post every deal as a blog entry. The proper platform with accounts, checkout and automated fulfilment was built during 2009.
How did the tipping point mechanic work?
Each deal had a minimum number of buyers. Below it, nobody was charged and the merchant paid nothing, which made the offer risk-free for the business. At or above it, the deal tipped, every buyer was charged, coupons went out, and Groupon kept roughly half the voucher price before paying the merchant. The threshold also gave buyers a reason to tell friends.
How fast did Groupon grow after the MVP?
It expanded to Boston, New York and Toronto during 2009. In April 2010, seventeen months after launch, a $135 million round from Digital Sky Technologies valued it at $1.35 billion. By October 2010 it was in 150 North American cities with 35 million registered users, Forbes had called it the fastest-growing company ever, and in December 2010 it declined an offer from Google worth about $6 billion. It went public on 4 November 2011 at a valuation near $12.7 billion.
What did the Groupon MVP not prove?
Whether merchants would run a second deal and whether buyers kept opening the email and redeeming at a rate that kept merchants happy. The blog-era MVP validated the mechanic, merchant willingness to try it, and per-deal economics. Retention on both sides was answered later, at scale, and it is where the company’s later difficulties came from. An MVP proves the question it was built to test and earns the right to ask the next one.
