TL;DR
The Stripe MVP was seven lines of code a developer pasted into a website to accept a card payment, and a person on the other end of it. In 2010, when a developer signed up for what was then called /dev/payments, there was no financial infrastructure behind the API. Patrick Collison called a friend at a payment gateway, gave him the details, and the friend set up a merchant account for that user by hand. The developer saw an API that worked in minutes. What made it work was a phone call.
It stayed in private beta for about eighteen months, seeded almost entirely through other Y Combinator startups, with the founders setting it up on customers’ laptops in person. When it launched publicly on 29 September 2011 it had around a hundred customers and ten employees. Today it processes close to two trillion dollars a year.
The rest of this post is the detail: what the seven lines actually were and were not, what happened behind them, why the beta was gated rather than open, what the Collison installation taught them, and what a founder building an API, a developer tool or any “integrate this and it works” product can copy from it.
What people mean when they say “the Stripe MVP”
The Stripe story is usually told as a product story: two brothers made payments easy for developers, developers loved it, the rest followed. That is true and it skips the MVP entirely.
“The Stripe MVP” is the period from roughly January 2010, when Patrick and John Collison started building /dev/payments, to 29 September 2011, when Stripe launched publicly. For most of those twenty months the thing developers integrated was real and the thing behind it was not. The API was Stripe’s; the merchant accounts, the processing, the banking relationships were borrowed, arranged by hand, one customer at a time, by a friend at a gateway company.
That makes it the clearest large-scale example of a Wizard of Oz MVP: the customer experiences an automated product, and a human is doing the work behind the curtain. DoorDash’s founders told customers they were delivering the food themselves. Stripe’s did not tell developers that the account behind their API key had been opened by phone, because the developer did not need to know and did not care. The promise was “paste this and take payments”. The promise was kept. How it was kept was the MVP’s business.
The problem, and who felt it
In 2010, accepting a card payment on a website meant applying for a merchant account with a bank, which took days or weeks and paperwork; picking a gateway such as Authorize.net to connect that account to your site; and integrating an API that assumed you were a business with a finance department, not a developer with an afternoon. PayPal existed and was the default, and developers disliked it for reasons that filled forums: a hosted checkout that took users off your site, an API that had accumulated a decade of layers, and an account-freezing habit that startups traded stories about.
The Collisons had felt this personally. Their first company, Auctomatic, went through Y Combinator in the winter of 2007 and sold in 2008; building it had meant fighting payment integration. By late 2009 they were students at MIT and Harvard, and the idea was small and specific: make accepting a payment as easy as calling a function.
The reader to notice here is not “businesses that need payments”. It is developers. The person who felt the pain was the one writing the integration, and that person was also, in 2010, increasingly the one who decided which tools a startup used. Stripe’s MVP was aimed at the developer, priced for the business, and sold to neither. It spread from developer to developer.
What the seven lines actually were
The famous claim, “seven lines of code”, needs to be stated precisely because the legend drifts.
The seven lines were the integration: the snippet a developer added to a page to tokenise a card and create a charge through the /dev/payments API. Behind those seven lines was a real, well-built API and dashboard, which the brothers wrote themselves over 2010. Stripe was not a landing page and it was not a mock. The software the developer touched was genuine.
What was not genuine, in the sense of being Stripe’s own, was everything under the software. There were no bank partnerships, no processing agreements, no compliance apparatus. When a new developer signed up, the account that let their charges settle was set up manually by a contact at an existing payment gateway, on request, per customer. First 1000, which reconstructed the early years from founder interviews, puts it plainly: there was no financial infrastructure in any way for the first two years, and when someone signed up Patrick called his friend, gave him the details, and his friend set up a merchant account for that user.
So the MVP had two halves. A front half the customer saw, which was the product at nearly full quality for the narrow thing it did. And a back half the customer never saw, which was a person and a phone.
The beta: gated, seeded, installed by hand
The second unusual thing about the Stripe MVP is that it did not launch. The brothers went through Y Combinator (the accelerator lists Stripe in its summer 2009 batch) and, against the usual advice to ship publicly, kept /dev/payments in a private beta for the whole of 2010 and most of 2011. Three mechanisms filled it.
The YC network as the first customer base
The first ten to thirty customers were other Y Combinator startups: companies the Collisons knew personally, run by developers, who needed payments and hated the alternatives. The first customer of all was Ross Boucher, a friend from their YC days who later joined the company. In June 2010 a YC partner posted on Hacker News and the YC blog that if you needed payments on the internet you should email these smart people, which produced somewhere between 300 and 550 waitlist sign-ups. That was the entire top of the funnel for a year.
This is what design partners look like for an infrastructure product: not three to five, because an API can serve more than that, but a bounded group of users who share the founders’ vocabulary, will tolerate the rough edges, and will tell them the truth.
The Collison installation
Paul Graham coined the phrase for what the brothers did whenever a founder agreed to try it: they said “right then, give me your laptop” and set it up on the spot. No sign-up flow, no onboarding email sequence, no waiting to see whether the developer got round to integrating. The integration happened while the founder watched, with Patrick or John typing.
It looks like a sales tactic. It was a research method. Every installation showed them exactly where a developer got stuck, which parts of the documentation were unclear, which defaults were wrong, and what the first question after “it works” was. The seven lines got to be seven lines partly because the brothers had watched dozens of people type them.
Word of mouth, and nothing else
Patrick has said that everything else was so bad and so painful to work with that people were selling Stripe to their friends. For the first year there was no paid acquisition at all. The first paid channel, Stack Overflow ads, did not start until April 2012, seven months after launch. Capture-the-flag security contests in 2012 drew ten to fourteen thousand developers. Before that it was developers writing blog posts about the API.
The beta ended on 29 September 2011. Stripe launched publicly with about a hundred customers and a team of ten, four months after a $2 million seed round in May 2011 from Peter Thiel, Elon Musk, Sequoia, Andreessen Horowitz and SV Angel. Pricing was 2.9 percent plus 30 cents per successful charge, which it still is.
What the Stripe MVP validated, in order
Like every MVP that worked, it answered the cheap questions first.
1. That developers wanted this badly enough to switch
From the first YC customers and the waitlist. Developers with working PayPal integrations ripped them out for a beta product with no bank behind it, because the integration was that much better. Cost: a year of two people building the API.
2. That the abstraction held
From the Collison installations. Could a developer who had never seen it get to a successful charge in minutes, without the founders explaining it? Watching dozens of installs answered that and shaped the documentation. Cost: laptops and afternoons.
3. That the economics could work at Stripe’s price
From the beta’s real charges. 2.9 percent plus 30 cents, minus what the gateway and the networks took, on real volume from a hundred companies. Cost: the friend’s patience.
4. That it would spread without a sales team
From the twelve months of no marketing. If developers were not writing about it and recommending it, the launch would have needed a sales motion Stripe never built. Cost: nothing, which was the point.
Only after all four did the seed round fund the real financial infrastructure. And notice what was not validated by the MVP: whether large businesses would trust a startup with their payment flow, whether the model survived regulatory attention, whether the abstraction held for subscriptions, marketplaces and international payments. Those came later, expensively, over a decade. The MVP earned the right to ask them; it did not answer them. That is what MVP validation is for: knowing which question you have actually settled.
Why it worked, and where the legend gets it wrong
It worked because the thing behind the curtain could be borrowed
Stripe could run a Wizard of Oz MVP because merchant accounts, processing and banking already existed as services someone else provided. The founders did not have to fake the infrastructure; they had to arrange it, one customer at a time, through someone who could. A founder whose product depends on something that cannot be borrowed or arranged has a different MVP problem.
It worked because the front half was finished
This is the part that distinguishes Stripe from most Wizard of Oz stories. The API and dashboard were not a prototype. They were the product, built to the standard the founders wanted to ship, for one narrow use: take a card, create a charge. Developers were evaluating the interface, and the interface was real. If the seven lines had been a mock-up, nobody would have switched.
It worked because the user was chosen, not the buyer
Stripe sold to nobody. It let developers, who felt the pain and who were increasingly choosing their startups’ tools, find it, install it, and tell each other. The single-feature MVP logic applies here too: one thing, done for one kind of person, better than anyone else had done it.
It worked because the beta was gated
An open launch in 2010 would have produced a queue of merchant accounts one friend could not open, and a support load two founders could not carry. Gating the beta to people they could install by hand kept the manual half of the MVP inside the capacity of the people doing it. That is the discipline every concierge and Wizard of Oz MVP needs and most founders skip: the manual process has a ceiling, and the funnel has to respect it.
It worked because they charged from the first transaction
2.9 percent plus 30 cents from the first beta charge, which is the price today. Every question after the first customer was about scale, not about whether anyone would pay.
Where the legend gets it wrong
The legend says Stripe was “seven lines of code”. Seven lines was the integration; the product was a year of engineering in front of a manual back office. The legend says developers “just loved it”; they loved it because two founders sat next to dozens of them and fixed what they got stuck on. And the legend almost never mentions that the company had no financial infrastructure of its own for its first two years, which is the single most useful fact in the story for a founder deciding how much to build before finding out. The question of whether you need a product to raise is handled in do you need an MVP to raise funding; Stripe raised its seed on a hundred beta customers and a borrowed back end.
Stripe next to Dropbox, DoorDash and Groupon
Four famous MVPs, four types, and in each case the type was chosen by what part of the value could not be delivered without building it.
| Dropbox | DoorDash | Groupon | Stripe | |
|---|---|---|---|---|
| MVP type | Explainer video | Concierge | Piecemeal | Wizard of Oz |
| What the customer saw | A video of a product that did not work yet | A landing page, PDF menus, a phone number | A rebranded blog with a daily deal | A finished API that worked in minutes |
| What was behind it | Nothing yet | Founders driving, openly | Founders emailing PDFs, openly | A friend opening merchant accounts, invisibly |
| Money on day one | No, a waitlist | Yes, $6 a delivery | Yes, twenty pizza vouchers | Yes, 2.9% + 30c per charge |
| Beta gating | Open waitlist | Open, one town | Open, one city | Closed, YC network, installed by hand |
| Time before own infrastructure | Months | About six months | About seven months | About two years |
Dropbox could not borrow or fake its value, so it filmed it. DoorDash’s value was food arriving, which people can deliver. Groupon’s was a transaction with a mechanic that tools plus one widget could run. Stripe’s value was an abstraction over infrastructure that already existed elsewhere, so the abstraction was built for real and the infrastructure was borrowed. The rule: build the part of the value that is yours; borrow, fake or do by hand the part that is not, for as long as the customer cannot tell the difference and the founders can carry the load. The wider set of cases is in MVP examples.
How to copy the Stripe MVP in 2026
This playbook is for founders building an API, a developer tool, an integration, a data product, or anything else whose pitch is “connect this and it works”. It does not translate to consumer apps or marketplaces; those have their own posts above.
Step 1: find the person who feels the pain, not the person who signs the cheque
Stripe’s user was the developer; the buyer was the business. Identify who actually suffers the integration, the workflow, the report, and build for them. The buyer will follow, or the user will become the buyer. The B2B SaaS version of this is the champion inside the customer’s company.
Step 2: make the front half real and the narrowest possible
One operation, done properly: the equivalent of “take a card, create a charge”. Not a platform. Build the interface your user touches to the quality you intend to ship, because they are evaluating that interface and nothing else. Everything the interface depends on is a candidate for the curtain.
Step 3: put a person behind the curtain
Whatever the interface promises that you have not built yet, arrange by hand. Provisioning, data loading, the “integration” with a third party, the report that “generates automatically”: if a person can do it within the response time the user expects, a person should do it until the demand is proven. Keep a log of what the person does; that log is the specification for the software that replaces them.
Step 4: gate the beta to what the person can carry
Do not launch. Seed the beta from a network you already have (an accelerator cohort, a community, a mailing list of the kind of user from step 1) and cap it at the number of accounts your manual back office can serve. A waitlist is not a vanity metric here; it is the valve on the curtain.
Step 5: install it yourself and watch
Do the Collison installation. Sit next to the first fifty users while they integrate, or share a screen, and do not help until they get stuck. Every place they stop is a documentation fix, a default to change, or a feature you thought was obvious and was not. This is the cheapest user research you will ever run, and the only kind that tells you what a stranger does with your product rather than what they say about it.
Step 6: charge from the first transaction, at the real price
Set the price you intend to charge at scale and charge it to beta user one. A free beta of an infrastructure product tells you developers like free things. Stripe’s price has not changed in fifteen years.
Step 7: build the back half when the person is the bottleneck
When the friend cannot open accounts fast enough, when the waitlist is growing faster than the manual process, when the seed round lands, replace the curtain with systems, scoped from the log you kept in step 3. That is the point at which a rapid MVP build makes sense: the first real version of the machinery, specified by twenty months of evidence about what it has to do.
When the Stripe approach does not apply
When the back half cannot be borrowed or done by hand. If your value is the infrastructure itself and nobody else’s can stand in for it, there is no curtain to hide behind. Build a narrow real version instead.
When the user must know. Stripe’s developers did not need to know how the merchant account was opened. If your users would make different decisions knowing a person was behind the product (anything involving their money at risk, their data, their compliance), tell them, which turns the Wizard of Oz into a concierge MVP, or do not do it.
When the manual step cannot meet the promised response time. A payment API that settled “within a few days” was fine in 2010. A product that promises real-time results cannot be run by a person on a phone, and a beta that reveals the gap teaches your first users to distrust you.
When you cannot gate. A consumer product that has to be open to work (a marketplace needing liquidity, a social product needing density) cannot cap its beta at the size of a manual back office. That is why DoorDash and Groupon did it openly, in one town, rather than behind a curtain.
What happened after, and what it does not teach
After the launch Stripe spent the next decade building the infrastructure that the friend at the gateway had stood in for: its own processing, banking relationships, compliance, and then a stack of products on top. It raised at a $95 billion valuation in 2021, took a $50 billion down round in 2023, and was valued at $159 billion in a February 2026 tender offer. In 2025 it processed about $1.9 trillion. None of that is the MVP.
Two things carry over. First, an MVP that proves developers will switch has not proved that enterprises will trust you, that regulators will leave you alone, or that the abstraction survives every payment type; Stripe earned the right to those questions and then spent years and billions answering them. Second, the front half of the MVP, the seven lines, is still the product’s promise fifteen years later, which is unusual. Most MVPs are replaced. Stripe’s interface was kept and the curtain behind it was replaced with the real thing. That is what happens when the front half is built properly in the first place, and it is the argument for not treating “MVP” as a licence to ship a bad interface. Production-ready MVP makes the same case from the other side.
Conclusion
The Stripe MVP was a finished seven-line integration in front of a friend at a payment gateway opening merchant accounts by hand, gated to a private beta of Y Combinator companies, installed on customers’ laptops by the founders, priced from the first charge, and run that way for about twenty months. It validated that developers would switch, that the abstraction held, that the economics closed and that it would spread on its own, before a dollar was spent on financial infrastructure.
The transferable lesson is not “seven lines”. It is the split: build the part of the value that is yours to the standard you mean to ship, borrow or hand-run everything behind it for as long as the customer cannot tell and you can carry the load, gate the beta to that load, and replace the person with systems only when the person is the bottleneck.
If you are building an API, a developer tool or any product whose pitch is “connect this and it works”, and you are deciding how much of the machinery has to exist before you can find out, that is a conversation we have regularly as an MVP development company: usually the answer is a smaller front half than you think and a bigger curtain. Start it here.
Related guides
- Wizard of Oz MVP
- Concierge MVP
- Piecemeal MVP
- The DoorDash MVP
- The Groupon MVP
- The Dropbox MVP
- Single-feature MVP
- Fintech MVP
- MVP examples
Frequently Asked Questions
What was the Stripe MVP?
A seven-line integration and a real API and dashboard, called /dev/payments in 2010, in front of borrowed infrastructure. When a developer signed up, Patrick Collison phoned a friend at a payment gateway who set up a merchant account for that user by hand. Stripe had no financial infrastructure of its own for roughly its first two years; the developer saw an API that worked in minutes and never needed to know.
Was Stripe really built with seven lines of code?
No. Seven lines was what a developer pasted into their site to accept a payment. Behind those lines was a full API and dashboard the Collisons built over 2010, and behind that a manual back office. The seven lines were the interface, not the company.
What is the Collison installation?
Paul Graham’s name for how the Stripe founders onboarded early users: when a founder agreed to try it, they said “right then, give me your laptop” and set it up on the spot. It removed the gap between agreeing and integrating, and it let the founders watch exactly where developers got stuck, which shaped the documentation and defaults.
How long was Stripe in private beta?
About twenty months, from early 2010 to the public launch on 29 September 2011. The beta was seeded through Y Combinator startups, a single Hacker News post in June 2010 that produced 300 to 550 waitlist sign-ups, and word of mouth. At launch Stripe had about a hundred customers and ten employees.
Was the Stripe MVP a Wizard of Oz MVP?
Yes. In a Wizard of Oz MVP the customer experiences an automated product while a person does the work behind it. Stripe’s developers experienced an automated payments API; the merchant accounts behind it were opened manually by a contact at a gateway company. Unlike a concierge MVP, the users were not told, because it made no difference to what they received.
How did Stripe get its first customers?
Through the Y Combinator network: the first ten to thirty customers were other YC startups, the first of all a friend named Ross Boucher. A YC partner’s post on Hacker News in June 2010 added a few hundred to the waitlist. There was no paid marketing until Stack Overflow ads in April 2012, seven months after launch.
What did Stripe charge during its MVP?
2.9 percent plus 30 cents per successful card charge, from the first beta transactions. The price has not changed since, which meant the MVP tested willingness to pay at the real price rather than interest in a free tool.
What did the Stripe MVP validate?
Four things in order: that developers would rip out working integrations to switch; that the abstraction held for a stranger integrating without help; that the economics closed at 2.9 percent plus 30 cents on real volume; and that it would spread by word of mouth without a sales team. It did not validate enterprise trust, regulatory durability or the abstraction across every payment type; those came later.
When did Stripe build its own payment infrastructure?
After the $2 million seed round in May 2011 and the September 2011 launch, and then progressively over the following years: its own processing, banking relationships and compliance replaced the borrowed back end that had served the beta. The interface stayed; the curtain was replaced with the real thing.
Can a founder copy the Stripe MVP today?
For an API, developer tool, integration or data product, yes: build the one operation the user touches to ship quality, put a person behind everything else the interface promises, gate the beta to what that person can carry, seed it from a network you already have, install it yourself and watch, charge the real price from the first transaction, and build the back half when the person becomes the bottleneck. It does not apply where the infrastructure cannot be borrowed, where users must know a person is involved, or where the product only works at open scale.
