How I helped build a profitable MVP over a weekend
mzrn.sh
mzrn.sh
It highlights that the true business driver is that personal interconnectedness: author's friend had good relationships with both restaurant managers and drivers. This is what has allowed an MVP to be successful, not the kludgy "product".
Sure, this product still needed to be built for people to be willing to continue to work together, but businesses of the sort have survived for years on spreadsheets and similar "implementations".
Some of these constraints do not hold on the internet, but you still need to catch the attention of the right folk to get that word-of-mouth moving (which is why we see so many "Show HN" posts here: there're plenty of people here who can do that for others).
Exactly! It feels like the article draws exactly the wrong conclusion. They were able to succeed _in spite_ of having a crude application because the relationships trumped. Know your customer, have an audience, all that stuff that you hear all the time.
> It’s not about making friends with the right people
Because my takeaway was the opposite… if you have good connections, your actual product isn’t as important.
It's a tremendous blind spot, where "the right people" are defined as people his friend would have to pay for some business thing, rather than the people who have the money to give him.
Coincidentally I'm helping someone in this way right now. She has a good business idea because she has the talent and potential clients already (as well as being a good people-person), but the fact that she has me to make a website for her and advise on her technological needs for free isn't the thing that makes it a good business idea. Don't get me wrong, it can be extremely valuable and thrifty to have someone who knows enough to know where and when to say "no," or YAGNI, but those are cashflow and time questions, not a fundamental viability one.
Everybody has theories, and none of them line up.
> No, it’s about embracing the constraints. They proved to be his true allies
And say pretty much the same thing you did.
Constraints helped them ship by Monday (a seriously admirable feat) but the direct relationships with both the customer (restaurants) and infrastructure (couriers) was what made it a profitable endeavor.
What they've done is had a shortcut to finding their first customers and convincing them to use the product. Often the hardest part, no fiddling with a contact form or landing page
Main reason I wrote it was to keep reminding myself that resources, and especially time, are limited. As a developer, it's easy to spend all your time on your pet project and think it's free and there's no harm. I fall for that all the time. But it's never free and yes, there is actual harm. Think of all the other projects you never launched. All the moments with loved ones you never had.
Using creativity instead of all your time is just like using an elegant algorithm* instead of brute-forcing it.
Notes:
* I am a (primarily) front-end developer, don't know a single algorithm
** Thanks @jeremylevy for sharing my story here, I would never dare to
Congrats on both fronts!
> It’s not about making friends with the right people
It clearly WAS about that, because having friends in the restaurant industry is what allowed your friend to succeed. If he had no restaurant connections, he could have never signed up any customers.
So, over a weekend you and your friend decided to take on postmates, ubereats, etc.? Nice story.
I refuse to use any of the delivery services on principle, principles which they lack. If I can't call the place on the phone, I just eat someplace else.
> [The lesson is] not about making friends with the right people
As making friends with the restaurant owners and the delivery guys was absolutely the key to my friend's success. To which I 100% agree. So I made it clearer:
> [The lesson is] not about making friends with a developer
The point I am trying to make is entirely different: our friendship didn't force me to write the code the way it was written. The limitations we had did. And it's possible to do it with non-friend developers as well: just limit the budget.
If a client comes to me with detailed scope of work and unlimited budget, I will make sure to build something truly amazing and earn a new house in the process. That's just how human brain works. But if they approach with a limited budget telling me to do the best I can, I might build something good enough to launch.
Now that comes with a different problem: most clients will want more after you have done your best for the budget. That doesn't necessarily mean they're bad people. Friends will do the same. Don't remember for a fact but probably my friend also asked for some more stuff, to which I would have said no. Ability to say no is absolutely crucial, be it with clients or friends. Better people than I have written on the matter so I won't bother you further with my thoughts on this.
Very cool story but it's hard for me to really understand it without knowing how the business actually worked and made money. I assume it was a very different market from USA and so economics are very different (cheaper labor, less regulation etc.). Would love to know the name of the business to see the outcome.
Here are some answers:
- The market was definitely not USA
- He made some kind of an arrangement with his employer, where he helped them during the transition period after merger (something he really didn't want to do, given he was being fired right after) and they didn't come after him for entering the same market as a much smaller player.
- Initially he handled all the issues you raised (and ones you did not) manually. At scale, you cannot handle courier demand manually, that's why you need software in this business. But he didn't start at scale, he just started. Did things that didn't scale. After we launched, he didn't sit back and watch money pile in. He was there all day, refreshing my non-autorefreshable application and being on the phone with couriers and restaurants and sometimes end customers, making sure it all didn't fall apart.
- The outcome: as I said, this was not a US-based business and the money he made was not the US money (both in terms of currency and scale). He built a business of a local importance in a small market. To me, there's nothing wrong with having a small bootstrapped business. In fact, that's one of my goals in life.
When the pandemic hit, food delivery became really hot and 3 startups of global scale have entered his market. His former employer didn't survive, even though they had nearly 100% of market share at some point. So he had to pivot as well. Instead of running a delivery business, he is now running a SaaS business - offering only the software to restaurants who want to handle online orders themselves (with in-house delivery) to avoid paying 30% marketplace fees. This allowed him to focus his attention elsewhere, while running this SaaS on the side, with nearly 0 involvement and exactly 0 employees.
Lesson to learn: not everything should be planned as a complex enterprise app.
Most engineers try to start with software, and build a customer relationship from what they've built. Most of the time they find they built the wrong thing.
The customers and the delivery guys willing to jump on right away were the true assets and no, you can't build those relationships on a single weekend.
One of the biggest examples of a constraint that I feel has benefited my organization & product is a requirement that everything must start out using SQLite. To this day, ~6 years after this one directive, we have not yet found any actual need to move off this approach. The amount of time we were able to spend focusing elsewhere has actually made us viable as a business.
There was a period where our organization was essentially unconstrained on tech (think microservices, tons of repos, mapping/API hell, etc). These were very fun times for the novice engineer. For everyone else it was a living nightmare to watch the weeks slip by without an ounce of additional business value being added to the product.
I really, really like this idea. After experimenting with SQLite recently I was quite impressed, and I can easily see how using it to abstract away the database layer for another day makes a world of sense.
Also at the language layer, constraints are a big win to me. I used to love Perl, don't get me wrong, but Erlang with its opinionated architecture (async, immutability, assertions everywhere) seems like a much saner way to develop a serious program.
> I said I could build it over the weekend. It was Friday.
I wonder how long the ideation phase took. I know a fair number of people, myself included, are bad at defining "true" MVPs, and it takes time to cut an idea down to the bare minimum. I would definitely not be able to do that AND implement it in a weekend.
I think the key here was that there was no "ideation" phase. We just got to business right away. And we were really, strictly limited with time.
I have worked on a dozen, maybe more other MVPs (where I got paid, as that's what I do for a living). And I don't think I have any other MVP story worth writing about.
I assume there was some additional context about the order in the form that the restaurant filled out, to assist in the end-of-month bookkeeping?
And unless you built reporting into the MVP, I bet your friend got to learn how to use some kind of database GUI (e.g. phpMyAdmin) and/or basic queries?
>The app would assign the order to a free courier, triggering an email. Their Gmail was our mobile app!
>The courier would then pick it up, deliver, take cash on delivery, and mark themselves as “free” again.
This tripped me up for a second. In this context, "free" indicates that the courier was available to pick up an order and make the delivery.
You assume that bookkeeping in restaurants is diligent. Which, er...
I reckon they were more than happy to just take the cash and apply some creative skills later on.
Sure, there were a couple extra fields.
> And unless you built reporting into the MVP, I bet your friend got to learn how to use some kind of database GUI (e.g. phpMyAdmin) and/or basic queries?
I don't really remember, but I bet we'd include an option to export to Excel. This project was built on Rails, and there are readily available gems to export data. Also, I believe we had a dashboard powered by https://github.com/ankane/chartkick. Setting it up may have taken 50% of time. Was it necessary? No. Did I mention this in my post, saying we could have done it in a day? Also no :D
> This tripped me up for a second. In this context, "free" indicates that the courier was available..
Thanks for catching this, changed it to "available" for clarity
Clearly these guys had a huge amount of trust amongst each other.
That's one of the hidden advantages of B2B, and recurring business models in general.
The momentum gained by getting something so simple, live so quickly, is not to be underestimated!
https://www.gwern.net/docs/technology/2004-03-30-shirky-situ...
Basically: fit for purpose can be simple.
I have paralysis outside of work. At work I get done whatever needs doing, but on my own project I get stuck at picking stack and debating architecture.......when in reality none of that matters if the projects goes nowhere at all.
Thanks to your story I'm going to try scaling my ideas down to bare minimum and building from there as needed, however, getting an app even if it involves making spaghetti.
It is another version, and more relatable I might add, of Reid Hoffman saying "if you aren't embarrassed by your first version you have launched too late." (https://twitter.com/reidhoffman/status/847142924240379904)
Terrific storytelling, and sadly, 99% of founders will never get past their narcissism and just launch it.
Thanks for the story from real experience.
Talking to the submitted article: It took a weekend sure. But it also took developing a friendship over years.
I can find plenty of students happy to build a simple prototype, but in my life I met less than 5 people who were able to turn a few HTML pages or even a full fledged product into money.
Instead of thinking of MVPs to prove an idea, startups should be ideas that are Known To Work and the MVP more like this - the actual minimum needed to connect a knowledgeable user to a well-trodden business action.
What value does this MVP offered, bookkeeping orders? Couldn't the restaurants just contact the courier directly too? Looks like the restaurants were already doing it.
I'm assuming the burden of filling up the web form would be the same as contacting the courier. In many places couriers will use their own cash to pay for the order, so the restaurant gets the payment immediately.
I guess, the MVP tracked which couriers are free and also would automatically assign a courier to a new order, depending on who was free.
If you have to send out an e-mail, you have to pick a recipient, therefore you have to know by yourself / look up manually which ones are free...
Basically, this was food delivery as a service for restaurants.
If not (or not all of it), why do you want to pay a cut of your salary/income to the utilities company?
Restaurants can focus on doing what they do best: prepare food. Delivery is offloaded for a fixed fee (if you read the article even).
I love it, I just love it
After reading the original blog post, it seems like their solution was pretty close to no code already. It very well could have taken longer to learn how to use airtable or powerapps than it did to hack this together.
That account was caught in a software filter; those are tuned more strictly for new accounts. I've marked it legit so this won't happen again. In the meantime, users vouched for all the comments—that's good. (More info on vouching: https://news.ycombinator.com/newsfaq.html#cvouch.)