The best example of Lean Startup I know
Building a thriving dating app without building a dating app
The Pitch
Meet Breeze, a dating app. The twist: No chat, you schedule a date directly on a match. Too fast?
Well, not for almost 200.000 dates in 4 countries in Western Europe, as of writing.
How did they start out? Very lean. Learn from their experiments, below.
Breeze had an amazing approach
I had the pleasure to mentor Breeze for the first 6 months. What would most people start with, after the interview phase?
Start sketching mockups in Figma
Build a landing page
Write a business plan (yuck)
Starting building no-code (Bubble or Webflow)
Starting coding a native app
I was happy to see that Breeze took a different route than the ideas above. They didn’t want to wait 3 months for an app to be ready. This was back before no-code wasn’t widely available. Flutter was relatively new.
Instead, step by step, the team hacked stuff together, postponing building their envisioned app as long as possible. This team was not interested in building an app. They were interested in (in)validating their startup idea.
Looking back, I can tell apart five rounds of validation of their startup idea, each highlighting one hypothesis. Any startup should be able to learn from this. Let’s go!
Round 1: Are people willing to go on dates by just seeing a profile without chatting first?
The biggest assumption of the team was that people would be willing to go on dates based on just a profile, without chatting first.
Blind dates happen all the time, however: friends of friends equals safety, to some extent. Profiles without chat are scary. This is what they did to validate this assumption.
The team asked their single friends if they could find a date for them
They made paper dating profiles, including a photo and bio
Went to campus, and put the piece of paper in front of strangers
Asking: “Would you go on a date with this person?”
Answer: Yes. 1 date scored!
Over WhatsApp, the team arranged a date and location
The date went very well, they had a great night
Why this experiment worked well?
➡️ It simulated the full experience of the solution by focusing on the job to be done rather than the application.
➡️ The response went beyond the usual ‘I’m interested in the concept’ by leaving an email on landing page: it required actual commitment from a potential customer to go on a date.
➡️ They ‘launched’ fast; a lot of founders would feel weird to look unprofessional with just a piece of paper. Don’t worry, people can value a prototype. They were ready in an hour to go out there.
➡️ Based on customer feedback, they validated they were able to create value.
Round 2: Can we do this digitally?
Just one date. That is not a business. They need scale. Going on campus every day is too time-consuming. ‘Do things that don’t scale’, but at some point you should try to scale some things. Here’s how they hacked something together.
Buy a burner phone for WhatsApp access
Create a Google Form for signing up, spread via WhatsApp groups
Manually make profile PDFs with Adobe InDesign for the submitted forms
Create a Google Sheet as a matching grid (males on rows, females on columns)
Every Tuesday they would send out 2 profiles to everyone, based on some basic requirements (such as age) and their gut feeling because of the initial user base (first 50 users) were at least semi-acquaintances
Users responded in WhatsApp to which profile they say yes.
For every match, the team would message both a simple date picker and location.
It was time-consuming, but more dates came in.
Why this experiment worked well?
➡️ The prototype provided value for the customer already
➡️ It saved a lot of time in building (ready within one day)
➡️ It allowed them to learn as you build, quick iterations
➡️ They weren’t making longterm commitments on tech before knowing what you require
➡️ WhatsApp offered a tighter conversation with launching customers than an app would
Round 3: Can we automate the hefty work?
At around 250 users, the hacky prototype became unbearable for the team. After 3 months, they knew that the biggest time-waster was the profile PDF creation and the manual matching.
Therefore, they deliberately automated two steps of the cumbersome process to scale things up a bit more. But not by building an entire app.
They created a simple tool that would have profiles on a webpage. Instead of a PDF, people now receive a link. It was not possible to edit your profile, just a front-end
The matching process took a full week when 100x100 users needed to be matched. Therefore, a Python script for matching was created. This algorithm could match within a few seconds. Obviously this was faster.
They build a landing page for the front-end and the profile form.
WhatsApp was still the interface for users: they received links to the webapp profiles to check it out. Users still needed to message via WhatsApp to ‘swipe’ (yes/no).
Word of mouth was the biggest driver of growth
Why this iteration worked well?
➡️ The requirements for the automations were very clear by being frustrated with what actually took a lot of time. Most people overestimate what the core of your application and routines are.
➡️ They could build this relatively fast compared to a fullblown application
➡️ WhatsApp still offered a tighter conversation with launching customers than an app would. They were experimenting with ease, as you can see in Round 4.
➡️ The team now had more time on their hands, and they increased the days you would receive profiles from one to two per week. This increased user engagement.
Round 4: Can we make enough money?
The initial revenue model of Breeze was simple: referral. The dates need a location, bars need clientele: a match made in heaven. Or not?
Bars are used to paying for clients, however, the margins are low. A restaurant pays about €1-€3 per reservation to platforms such as The Fork or TripAdvisor. Dates have a much lower bill than diner, because it’s only drinks, no food.
In the first months, Breeze had a deal for €1,50 per date. Breeze calculated that they needed more money per date to make a living out of this. Therefore, they tried something out: what if you monetize the users directly?
For a full week, all dates received a ‘pay what you want’ (open Tikkie) link.
The message? “Did you like our date? Tip us!” with suggested values of €1, €3 and €5 euros.
To the team’s surprise, most people tipped, and the average was over €3. They rounded it off to €5 per person per date.
Why this iteration worked well?
➡️ A fair proposition to your users. Other dating apps give you expensive subscriptions that don’t guarantee any dates. In this way, people were only paying if they got value. Charging close to the value you generate is an easy starting point for any business model.
➡️ The bars weren’t a fan of the fact that they needed to pay another invoice to Breeze. Part of the deal was that the first two drinks were on the house, and bookkeeping wise that was a bit of a hassle for a relatively low number of extra clients.
➡️ With the new model, the team swapped it around. Bars don’t pay Breeze anything, you just offer the first drink (beer, soda, wine) on the house. The wholesale price of those drinks is very low, so the bars hardly notice it, making it much closer to what they are use to pay for clientele. Win win.
Round 5: Can we build an app quickly?
How long did Breeze run on this tech stack of tools and scripts running together? Months. They were banned many times from WhatsApp. But after 7 months of doing things manually, they knew exactly what app they should build.
And only then they started building that app. To save time coding for both iOS and Android, they worked with Flutter, launching in 2019. How to notify the users? Over WhatsApp:
Their first version didn’t include the date picker yet. That still went down over WhatsApp. But, in early 2020, the full app was released, having all features of their hacky MVP.
Why this iteration worked well?
➡️ Now that the revenue model and core mechanism of the app were fully validated, the requirements of the initial app were very clear
➡️ The risk of sunk costs on building the wrong app was reduced
➡️ They started with the core functions (swiping), only to add the datepicker later. That’s lean!
🔥 Lessons learned
Starting with just one date per week, five years later Breeze is almost doing 500 dates per day. Breeze has arranged close to 200.000 dates in 4 countries in Western Europe.
What can we learn from this journey?
Obsess about what your customer is trying to achieve
Be interested in the job to be done of your application: in Breeze’s context, getting people on dates, in whatever way.
Get out there fast
Working lean is not about obsessing about the hypothesis. It’s about reducing the risk of spending resources on the wrong thing.
By doing hacky MVPs, you will learn what is actually important.
It’s about getting something representative in the hands of your customers ASAP.
Hacking together some web apps can serve your first 250 customers
You don’t always need to build an app to prototype an app
Marketplaces such as Breeze’s are very suited to do concierge /wizard of oz tests, yet not all applications can be prototyped this way, YMMV.
Did Breeze do everything perfectly? No! During the Covid-pandemic, they made a wrong bet. Read about it here.
Special thanks to Marsha, one of Breeze’s co-founders, for being very open about their journey, and for sharing numbers and images of her journey.
This is a GREAT read! Quick catch, if I understand it correctly, the data in the "Lessons Learned" chart is incorrect. It's titles "dates per day" but seems to indicate dates in total (your "nearly 200k" callout).