Growing a Food Startup to $10K/mo and Shutting it Down

Kevin was the founder of Melon, a food delivery startup aimed at being more cost-effective. Melon’s unique approach was quickly validated through an MVP and in just two months, the business grew to $10k/mo and 500 users. However, they realized becoming profitable would be hard and decided to discontinue the service.

Description

CTA

Hi Kevin! Who are you and what are you currently working on?

Hi, I'm Kevin Wang! I've been based in Atlanta for the past 6 years after starting my undergrad at Georgia Tech.

I was the founder and CEO of Melon, a food delivery startup aimed at being more efficient and cost effective for users and restaurants alike. Our model was focused on streamlining the process by offering the most popular items and most popular times, allowing us to pool many orders at once, reducing time taken during trips to drop off items.

Here's how it worked. Each week, we would create a unique, curated menu of the best local restaurants and their popular items that would last well for delivery. Our lunch drop off was between 12-12:30, dinner between 6:30-7. Users would pre-order before 11am, and 5pm for lunch and dinner, respectively, and all orders would be picked up and dropped off in the shortest trip possible. This enabled us to pool many more orders than would be possible compared to on demand.

Our business model was dependent on restaurant commissions. We could charge zero delivery fees because pooling 10+ items at once with one driver would pay for the driving time with just 10% of the total order cost.. Food delivery uniquely has three segments to balance: the customer, restaurant, and driver. Here are their respective benefits under this model.

As we expanded, we had to get creative to effectively deliver many items within a short time frame. We adopted a sort of miniature warehouse distribution style, where a car (like a truck on the highway) would pick up 50-60 items from the restaurant further out, and meet with other cars at a common point (the warehouse) to pass off 10-15 items each for them to make short stops downtown and around campus. This allowed us to achieve a high capacity of items delivered in a short timeframe with fewer miles driven, benefitting consumer price-point as well as environmental impact.

My vision for the company expanded far beyond this concept, into a service that would involve collaboration between users and local businesses to further improve efficiency, reduce costs, and allow small businesses to thrive using a delivery supply chain that truly worked for them. To users, we would be the one-stop-shop marketplace for your local favorites (food, crafts, groceries), with the best prices.

Our team was small, but close, with my brother Jeff, and a good friend Jack Olinde, and we were all technical founders. I led our business development, customer discovery, as well as technical aspects like design and software development. We all wore many hats. My day-to-day varied widely from fixing bugs and implementing new features to onboarding restaurants and collaborating with other entrepreneurs, but I tried to keep a main focus each day to reduce time lost from context switching.

Now that Melon is shut down and school is closed, I am actively looking for roles related with software engineering, data science, and machine learning.

‍

What’s your background and how did you come with Melon’s idea?

After graduating in 2018, I worked as a software engineer working on a mix of full stack development and signal processing. I also pursued a Masters in Computer Science with a focus on machine learning, which I just graduated from this Dec 2020! Late 2019, early 2020, I was at a sort of crossroads of what I wanted to do - I was actually early in the job search stage when I shifted focus fully on this startup.

Melon's approach to food delivery was inspired by problems I, a frugal student, personally faced as a user like cost, reliability, and simplicity. Existing companies were trying to reduce costs by combining orders to shorten the number of trips, but only one to two drop offs at a time. What logistics changes could enable food delivery with 20+ items dropped off together? Would there be consumer demand of more people like me for such a product given the additional constraints that would arise?

Tackling this problem appealed to me partly based on my past experience with startups. Atlanta and especially Georgia Tech has a deep startup and entrepreneurial culture, so I was exposed to many companies, industries, and founders. I had worked at a startup with high technical risk- meaning rolling out the product required technical innovations. However, testing out a food delivery concept has limited technical risk and financial risk. Entering the market and making progress is influenced more by business development and validating concepts with quick iterations, rather than having complicated software, and this new challenge interested me.

How did you go from idea to product?

Our MVP was as simple as it gets: a group chat where we would broadcast a menu of 2-3 items from a popular restaurant, with specific drop off times and locations. Our target market was students at dense locations on campus. We spammed existing group chats and added friends to find users.

The goal of this was to answer a few questions: did people have similar problems with food delivery as I had? Does a cheaper price make the limited selection and drop offs worth it? Will the routing times actually pan out accurately to be more profitable then existing services? What simple gamification scenarios might work (ex. Order even earlier for a discount. Have product scarcity to encourage quick decisions).

We found relative success with this, notably 17 items dropped off within 45 minutes for our best delivery. Our solution to their pain-points was immediately recognized. We even made just a bit of money through ordering catered prices and selling at menu price, despite no delivery fee. Jack and I did the driving ourselves.

This only went on for one week, then COVID hit, and all students were sent home off campus. But we took this validation, and prepared for a real product launch. We had to shift away from campus and downtown to apartments instead. We launched a website to sign up and subscribe to menus, which consisted of automated daily text messages.

‍

First Launch and Obstacles

We didn't gain the traction we wanted during this new launch, which happened in June. We again used Reddit, group chats, and experimented with Facebook and Google ads. Our previous target customer, students, were not around, so we tried to focus on acquiring customers at apartment buildings by approaching apartment office leadership.

Growth was slow, and towards the end of the summer, we had 75 subscribed customers, and while we were able to achieve occasional bulk drop-offs and successful trips, it was clearly not sustainable. I still believed that with the return of students, we would find greater demand, so instead of trying to accelerate growth over the summer, we spent time learning the logistics, some customer behavior, and built an online ordering + tracking system.

‍

Relaunch

With students returning in August, we relaunched with a streamlined website ordering and checkout process, as well as implemented card payments. It was (almost) like a real food delivery product! During this, our customer base rapidly grew, so we started to expand restaurant selections, utilize route optimization, and experimented with different features and pricing strategies. We wanted to validate that our service could be profitable down the line, so we maintained a balance between trying to obtain margins on deliveries, acquiring, and retaining customers.

One extraordinary benefit of this model is that as orders increase for one trip, the average time between stops decreases, as they are more likely to either be at the same location or closer to each other. For example, within a 1 mile radius, dropping 10 items off might take 25 minutes over 5 stops, but 20 items could take 35 minutes over 8 stops.

‍

Notable achievements

$10k MRR at time of shut down (commissions and fees averaged 13% of this)
500 users
Over 15 items per trip on average
Less than 30 minute average drop off time
Best quantity: 47 items for one meal
Best profit: $420 payed by customers for a $350 meal at bulk price, over a 45 minute drop off time
Thousands in fees saved from customers, in additional payout to restaurants, and driven miles reduced as compared to if the orders were fulfilled on-demand
Accomplished largely from August 2020 to October 2020, doing our own driving, and just 2 meals/drop off times for weekdays!

‍

Hacks

Very first payment was only from Venmo/PayPal. We would send payment requests after dropping off. Fortunately, and miraculously, nobody ghosted us!
We initially created routes manually and sent our Twilio texts manually (from a basic web app) like a dispatcher for order updates. We had routing and estimation implemented just before this became too overwhelming
To roll out website ordering with limited front-end experience, we leveraged Webflow to create our UI. Their e-Commerce did not meet the functionality we needed, and they only had a back-end API, but we still used some of their item creation and display, so we glued together DOM manipulations as well as our backend API to create our ordering and checkout process.

‍

Which were the strategies to grow your business?

Our growth was mostly organic. We had a focus to provide excellent service and obsession with ensuring that our customers would receive the best product of food quality and variety. We made it clear that we're doing our best to support small businesses.

An additional behavior we did not expect was the desire for shared experiences, especially during the pandemic. We were uniquely positioned to offer high quality meals to friends apart from each other, enjoyed right at the same time. This was a key to having our service appreciated by users and shared with friends. And when nearby friends ordered together, this further improved our drop off efficiency.

It was important to continue to expand the number of restaurants we offered and keep the options diverse. This involved a balance between exploring new options, and still offering the high demand items.

Our most effective outreach to new customers was posting a friendly version of our menu to social media.

When did things start to go in the wrong direction?

We had limited overhead costs especially as we did most of the driving. Any extra efforts we would spend on came from margins that came from previous deliveries. We started to raise a pre-seed of $275k, and preparing for that was part of the research where we saw a lack of a strong path forward. To grow faster, we wanted to raise money to improve our application, hire drivers, add more restaurants, and expand our drop off locations. We started to prepare decks and pitches for angels and early stage ventures, with a focus on landing a few of the former.

The logistics, process, and hypothesized benefits of our service realized new metrics that were off base from what we initially predicted. At the core of what we wanted to accomplish was a business model that could be successful at the smaller scale without need for heavy investments and subsidized orders.

With more users, our consistency and reliability decreased, so efficiencies were not as prominent as forecasted. The wages required for the drivers was also higher than initially planned, since the work was harder and more involved than delivering 1-2 orders at a time. Rapid stops, managing food, and constant communication equaled more effort so higher wages.

We initially estimated around 15% in margins over 150k MRR after paying the restaurant and drivers. However, after looking at the data for the time we delivered and adjusting our assumptions, in a best case scenario, the payout after restaurants and drivers would be near zero.

We were also rolling out features and experiments slower, with more time spent managing the existing service. Our path to profitability at scale was looking similar to those of existing on demand food delivery companies. It was necessary to find a fundamental shift or strategy in what we were doing.

Expanding to $150k MRR across the state and other cities would require much more overhead with software, support, and marketing. We decided to discontinue for these reasons as our burn rate would just be too high, even with low wages. Sure there was still a sliver of chance with slower growth or finding a new niche, but we did not set out to create just “another” food delivery startup. I still believe this was the right choice - I just don't think we would have been able to continue to outcompete if we expanded more.

‍

Which were the causes of Melon’s failure?

Pooling orders is not a unique concept. All the companies are trying approaches, and there are many promising startups as well, like Peach, Foodsby, and GoodUncle. UberEats tested out a concept of picking up many orders at once and distributing them over time, but discontinued that. Postmates Party has picked up traction and improved. Moreover, many ideas to further separate ourselves were being rolled out, like focusing on even more local businesses and grocers.

And I can't avoid saying that lack of experience was a major factor. We had to spend so much time learning technologies, the industry, and we were not quick enough to iterate with new concepts.

It was pretty strange to realize and make the decision to shut down, since I had spent so much time building just for the next week and hadn't taken as much time to reflect on the business as a whole, just different experiments within our local optimum.

‍

If you had to start over, what would you do differently?

Start with an even smaller target market and specific niche. We tried to do too much at once, instead of isolating concepts and fully learning about the implications. This resulted in us touching upon a lot of interesting concepts, but without any real knowledge or conclusions, including but not limited to the following:

How much value does reduced time in pre-ordering offer, and how many will plan ahead? If orders are in 1 day vs 6 hours vs 1 hour early, what does that mean for the user and restaurant?
Can we further limit drop off locations? What threshold resembles the best balance between market size and trip efficiency?
How many extra, unordered meals can we carry? What are the indicators to predict how many people might order if we say "I'm at location X with sandwich Y, want it"?
Would a subscription like MealPal work for these kinds of deliveries?
How might a loss leader come into play? For example, if we offered a popular sandwich at a loss, would people add on a pricier desert?
Okay... is "local" really that important?

Form more intimate relationships with restaurants, and have a restaurant expert on our team. I felt like a salesman much of the time. We should have pursued a journey along with them, rather than just have them as a product. Seek out failure, that's when you know you're pushing a boundary and will learn the most. Doing what's safe and enjoyed by many will just keep you comfortable in a local optimum. I wish more kitchens turned me away, so I could have found what fewer owners absolutely LOVE, and commit to, to grow concentrically from there. That goes for users too.

Target more specific ethnic cuisines, groups, locations, and restaurants. A good foothold on a section of international students would have enabled us to have more sustained demand for a cuisine further away that is not as accessible to them. In terms of preparing food, much of Asian cuisine shines under bulk preparation as it can be made together, and its quality holds after time. However, something like sandwiches is not as effective, because the preparation effort scales linearly.

Team expertise. While I absolutely loved working with my team, we didn't necessarily complement each other's weaknesses or strengths. While we were all smart, and hardworking, most time was spent learning frameworks instead of focusing on the customer product.

‍