The ugly, incomplete, buggy MVPs of top tech companies

“An MVP isn’t a product, it's a process. An MVP is a process that you repeat over and over again: Identify your riskiest assumption, find the smallest possible experiment to test that assumption, and use the results of the experiment to course correct” - Jim Brikman

A lot of startups are building things nobody wants. The sooner they recognize this, the better off they'd be.

This sounds harsh, and I get it: As builders, we love to fall in love with an idea and tinker with it until it's just right. But nobody cares about the hover animations in an app they don't want to use.

But the point of a startup is to build a fast-growing company that makes money. And that requires people willing to give you that money.

And the bar for people to pay is lower than you might think. In this article, we'll explore just how low that bar is - by looking at successful SaaS and tech companies' MVPs.

First, let's see why this matters so much:

Why nobody wants your product: the data

CB Insights found that the number one cause of startup failure (42% of the time) was “no market need.” Nearly half of these startups spent years building a product before they discovered that nobody wanted what they were building.

The only way to prevent this from happening is to put your product in front of your customers as quickly as possible.

This makes your MVP the perfect starting point – you can scale up easily from your v1 if your customers validate your hypothesis. And if not? Go back to the drawing board, change directions and course correct without compromising on speed. 

Let’s dive in, shall we? 

The DIY MVP: AirBnB

Airbnb’s MVP was as bare bones as they come. Their first version was literally Brian & Joe taking pictures of their room and putting it on a website for visitors to rent. They ended up making $240 from this. This validated their idea on the buyer’s side.

To test their hypothesis on the renter’s side, they expanded their MVP to allow people to list their space for rent. They included a map of all the places visitors could get rooms & limited the listings to locations near high-profile events. 

The lesson here is to start scrappy and do things yourself to validate your primary assumption. You don’t need a fancy app with a sleek UI when you’re just starting out. Remember, function beats aesthetics in the beginning.

Uber

Today, Uber is a complex marketplace with tons of features. Uber founders Travis Kalanick and Garrett Camp's MVP was a street team that camped outside crowded train stations at peak hours, local tech events, etc. in New York and San Francisco. 

This street team gave out coupons for free rides to everyone. People took the coupons, downloaded the app and could get a free ride. They used a small fleet of black cars driven by professional drivers. The app had one feature only—booking a ride. Users specified their location in the app and Uber sent the nearest cab to the rider’s location.

Do things that don’t scale – it’s overused as hell, but it’s true. Uber was never going to scale operating their own fleet of black cars everywhere, but the non-scalable version of the product can ultimately become scalable.

But doing what doesn' scale first will tell you whether your idea has got legs or if you need to move on. 

From internal resource to $27b sale

Did you know Slack was an acronym? At Stewart Butterfield's gaming company, where Slack started as an internal tool, Slack stood for: Searchable Log of All Conversation and Knowledge.

At the time, Butterfield's team worked out of different locations across America, which required a way to communicate asynchronously. That's why they built what became the MVP of Slack: Part of the validation was scratching their own itch.

But Stewart soon realized the potential of what they’d built and decided to take it to market. They started with three core lists:

• Channels — this listed the channels the user joined to see what conversations he needed to be part of.
• Messages — presented the messages in a channel or DM in chronological order, most recent last.
• Members — see the list of people who were in this conversation & who were online.

Funnily enough, this is still Slack's core functionality (though the product has grown a ton under the hood).

Sometimes, your MVP is just an unpolished but functional tool to get things done internally. And if it works for your use case, chances are others might find it useful as well. 

There's also another interesting lesson here. If you've discovered your idea doesn't have legs (like Stewart Butterfield's gaming company), look for what you've built internally to solve your own problems. There might be something there.

How to validate without a product: Buffer

The social media scheduling app Buffer launched in 3 phases. Joel, the founder, initially validated his hypothesis by creating a landing page where users would enter their email ids to get access to the waitlist. This is what they started with:  

After a few people signed up and Joel got some useful feedback via email and Twitter, he considered his idea “validated”.

The next step was to validate the pricing, so he added a pricing page in between the two pages which showed pricing. So users had to click one more time before giving their email. The extra step tested the pricing (by detecting which plan they click on) and also tested further the demand for the product. 

As you see above in the "Hello! You caught us before we're ready" message, people couldn't even pay yet. This is called a painted door test - it's a great way to test if something will work before you build it.

After the pricing was validated, Joel spent 7 weeks building his MVP & launched the V1 to his users with just one feature – they could only schedule tweets. 

Building a landing page is a low-effort yet effective way to validate your idea, and see how people react to it. If there’s demand, you have concrete data to go ahead and build the first version out. But remember to keep it lean! 

Don't even code: Amazon's MVP

Amazon famously started as an online bookstore during the dot-com boom. Bezos validated his idea by launching Amazon as a standalone website with no backend system. When users ordered books on his website, Jeff personally bought the books from stores and sent them to users via the post office. Talk about doing things that don’t scale! Within two months, Amazon earned $20,000 per week. Two years later, it went public.

And in true Amazon spirit, he kept talking to customers and iterated based on feedback. Decades later, Amazon became the behemoth we know today. 

You don’t even need to write a single line of code to build your MVP. Manual work can kickstart your validation process to see if there’s merit in your idea. Remember that software is merely an enabler to make sure the value you provide can be delivered & accessed at scale. 

Quick iterations: How Notion got started

Notion’s Ivan Zhao had a bold vision – he wanted to enable everyone to build apps without any code. For the initial MVP, he built the fundamental elements of Notion that we are all too familiar with today – text writing, image insertion & adding custom CSS. But after talking to customers, Ivan & team decided the idea wasn’t something that users wanted. So the team pivoted and built Notion into a knowledge base for teams & individuals. But though the product had changed, the essential building blocks remained. 

Your MVP can fail. And if that happens, great! You now know what NOT to build. That’s the beauty of an MVP - if you need to pivot, you can change directions without compromising on speed. 

Same tech, different market: Loom's MVP

Just like Notion, Loom built their original MVP for a completely different idea — a user testing marketplace called Opentest. Their initial MVP involved users submitting their product to get feedback on their user experience from experts. 

They validated their idea by launching on Product Hunt, which was super successful (They got voted the #1 product of the day). But while speaking to customers, the team realized that they needed to pivot & offer something that their customers truly wanted – a video communication platform. So they pivoted & built OpenVid, which later became Loom. 

The benefit of having an MVP is that it allows you to talk to users & iterate & change directions based on user feedback. This is an advantage only startups have - so make sure you leverage it to the fullest! 

From email list to platform: Product Hunt

As a non-technical founder, Ryan settled on a daily email list and a Linkydink group to validate Product Hunt. The list started off with a couple of dozen influential people in the startup industry that Ryan personally knew.

He sent daily to his subscribers, which soon started to grow & people started interacting with Ryan showing how much they enjoyed the daily digests. So he teamed up with his friend Nathan Bazchez and built Product Hunt on top of an open-source framework for a Reddit/HN like community & published the website in just 8 days. This is another example of validating your idea without involving any code. It can be as simple as collecting emails & sending users a newsletter. At this stage, the best question you can ask yourself is: What is the easiest version of my product that I can show to my users & get feedback on? 

When the MVP works: Reddit

Reddit’s MVP was simple and not too different from what we know Reddit to be today. Their vision was a platform where users could post cool stuff and the popularity of the content would be decided by anonymous user upvotes & downvotes. 

Alexis & his co-founder were guilty of over-engineering (aren’t we all lol) and so Paul Graham sent them an email asking why they hadn’t launched yet. A week later, Steve wrote back that Reddit was up and running. The founders built the prototype and launched it within 20 days. Paul shared Reddit on his own blog post which helped get initial eyeballs on Reddit’s first version & validate the founders’ hypothesis.  

At the start, it’s best to avoid over-engineering. It’s far more prudent to prioritize talking to customers & iterating via quick feedback cycles. Take Paul’s advice here. 

Conclusion: 

These stories have something in common – greatness often starts small and scrappy. And more importantly, greatness has no ego. 

Your MVP isn't about perfection and getting too attached to your idea. It's about function over form—getting something out there quickly to validate your idea. 

It’s about staying humble & listening to the customer and following their feedback. You have to get out of your own way & listen to your customer, because they will tell you everything you need to know. 

Whether you're manually shipping books like Bezos or offering free rides outside train stations like Uber's street team, the key is to start with what you have and iterate based on real-world feedback. 

So embrace the scrappiness early on – it’s not just a phase but a strategy that can set you up for long-term success. And remember – do things that don’t scale.