I love this story, but for somewhat different reasons than most.
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).
Same. It's not about making friends with the right people...except for the part where he had already done so.
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.
I quite literally came to the comments to quote this:
> 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.
I wouldn't call these 'good connections' in the traditional sense. Not the kind that recommends you for a job or can hook you up to seed investors.
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
I figured it was a play on the "networking industry" rather than knowing people who know people bit. He was able to build trust with people he worked with every day. Not much different than getting a recommendation from someone who you worked closely with and landing a new contract.
> 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".
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.
Okay folks! Jumping in to thank everyone for reading my story. I really didn't expect it to resonate with so many and I am so happy (and slightly terrified) that it did. Wow!
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
Your story was interesting, but I think this statement needs some qualifiers:
> 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.
> [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.
Wait you can't build a reverse proxy binary tree with recursively hashed nodes and O(n log n) guaranteed in place sorting? Why do you even call yourself a developer?? Why should I trust my webform->database web app with you? On the serious side I loved the story.
Your story was great! I also really enjoyed the mobile version of your site (haven’t had the chance to check desktop yet). Font style and size, line height, colors all made for truly enjoyable reading experience.
when I started reading your story, I thought you meant delivering food to restaurants. Then it said they'd be happy to do all the marketing, keep all the money, and I was like... how is your friend going to make any money? coin dropped.
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.
I like this story but I must say it leaves me with more questions than answers. How did he get restaurants to sign on and trust him enough to prepare food for 1 month without payout? Assuming "based on existing relationships" I have to wonder his former employer didn't care about taking his rolodex and directly poaching customers? What about couriers? How did they handle "no couriers available" or a spike in demand? If someone places a delivery order and it turns out there's no one to deliver it in the next hour, that's a problem. What about disputes, refunds, missing items, "this isn't what I ordered" etc.? The all-cash nature of the business makes clear this was not a US based business where that would likely have been a non-starter.
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.
Thanks for reading it, and raising some very good questions. I tried to keep the blog post short, as my side of this story is how I helped this business build the MVP, not the business itself.
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.
Thanks for the reply. Good to hear he's pivoted to SaaS, I think its a better business model and managing a 3-sided food delivery marketplace without funding or scale sounds like a nightmare
I like the article. I am the kind of person who thinks things hundreds times before acting, so it would probably taken me weeks just to settle for an architecture which would probably been overkill for an MVP.
Lesson to learn: not everything should be planned as a complex enterprise app.
They key here, he started with the customer relationship, and built software to support it.
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.
This, sir, is 100% true. This was never a software company, but a food delivery company that happened to run on software.
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.
You might enjoy this video, Stanley Tang of DoorDash talking about how they got their first few orders... masterclass in 'minimum amount of initial work to validate a concept'.
https://www.youtube.com/watch?v=oQOC-qy-GDY
As a songwriter I really suffer from analysis paralysis, and what kinda helped me was to write a song a day for a month. I'm still not a prolific song writer by any means, but it helped me learn that perfect is the enemy of good enough, and that iteration is a lot easier than trying to perfect something the first time.
Yes!! With music I used to debate whether I should do A or B, and spend a long time debating whether I wanted an album of genre A or genre B.. and then not write anything. Now I write both, one (or both!) will sound how I wanted, and then move on
Very nice, being limited or constrained with resources is not necessary a bad thing rather it empowers the mind to work with what's available and see options that won't be seen before.
I have adopted an extremely strong affinity for constraints after seeing what they can provide in return for being handcuffed in particular ways.
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.
> 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.
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.
If anyone needs a similar app/system you can try your luck with this defunct startup's code I open sourced a few years ago: https://github.com/Purple-Services (on-demand gas delivery app)
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.
> 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?
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
This reminds me of a podcast Ben Orenstein was on where he talks about something similar. Made a big difference in how I build/think about side projects.
“At the end of the day the couriers would bring in the cash, minus their cut.
At the end of the month, my friend would wire the money to the restaurants, minus his cut.”
Clearly these guys had a huge amount of trust amongst each other.
Yes, but it shouldn't be surprising. This trust is not based on belief in human decency, it's based on belief that people want to make money. You can never go wrong with that.
That's one of the hidden advantages of B2B, and recurring business models in general.
Fundamental. Make it easy (or at least possible) for honest people to be honest. Worrying about theft from your partners... Well, at least you should think about why your business interests aren't aligned...
This is a great example of a real mvp and targeting work towards solving problems first and foremost. It would be a boon for the world if our industry in general worked more like this.
Awesome story. I should start working on some of my ideas.
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.
I like the KISS principle applied here. I'm guilty of over-engineering. Once I worked on a project where we processed a lot of very large XML files ... and we set up a distributed application with Akka! We spent a couple of days to figure out the most clever way to listen for file system changes at the OS level. It was just crazy to read and process a bunch of XML files. A story like the one told here is a good reminder that in many cases a simple solution is enough (at least for a start).
I hate that the goal of all the entrepreneurs here is an exit. No one is better suited to run your company than you, no matter what BS financiers tell you.
I agree and I had an idea recently that I haven’t acted on but it has descoped from “should I is hasura?” to “I probably don’t even need a site at all, but a single HTML file will be handy enough validate this” in 2 hours of insomnia.
Talking to the submitted article: It took a weekend sure. But it also took developing a friendship over years.
Your friend is the right person to make friends with.
He was able to sell a crude form you can build in a weekend and bootstrap a business out of it.
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.
Always important to remember the code is only ever the implementation of an idea.
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.
Another take away is as always build what is actually needed. In this case it's a business for businesses and they do not care for your polish, your logo, and how nice your UI is. They want to get things done and not have anything slow them down.
I wish we would stop focussing on MVP. This is the easy part. Sure it needs to be nailed, but the hardest part is finding engineers for the last 5 years if bugfixing at the end of the product’s lifecycle…
So we “scaled down” all the way to B2B. Turns out, more than a few restaurants in town would gladly handle the sales and marketing themselves and keep 100% of the order value minus fixed delivery fees.
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.
The problem is the same as what all of the delivery apps solve. There are many restaurants, many customers and many delivery drivers. Someone needs to match all of them together.
Reading the article it seemed to me like courier management was the deal here; multiple couriers, some which might be free and some which weren't, marking them as busy when the email is sent and as available when they said so.
> This is a perfect use case for no-code platform like Airtable or MS PowerApps.
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.
The author of this article, mzrnsh, responds to comments here, but they are "dead" and can't be viewed without being logged in and activating "showdead" in profile settings, which is unfortunate. I don't have enough karma to vouch for them to be unflagged.
It's best when someone lets us know at hn@ycombinator.com so we can take care of it. I only saw this randomly.
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.)
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).