The Hopscotch Story (Part IV): The MVP
Before spending any real money on Hopscotch, we wanted to convince ourselves that we were onto something. We wanted to build the most basic thing possible—the fancy term for this is “minimum viable product (MVP)” — that would allow us to answer some fundamental questions. We had 100 of them, but the most important was, is there a market for online food delivery in Barbados? To answer it, we chose to target a particular set of people: university students.
We had several reasons. Many university students in Barbados aren’t locals, so we figured they might appreciate help navigating the local restaurant scene. Most probably don’t have cars, so they may have to travel a ways to get food, since there aren’t many eating places within walking distance of campus. And if today’s 20-year-olds are anything like I was, they likely aren’t the best or most enthusiastic cooks.
A survey we sent to students seemed to confirm our suspicions. 96% of respondents said they would be willing to pay for food delivery. More than a quarter said they thought they would order at least three times a week.
Still, people will say anything. I suspect the only way to know for sure if someone will pay for something, and how much, is to actually ask them to pay for it. The question was, how would we do that, without building a real (expensive) site that they could order from?
We considered putting a simple document online that listed the menus of our partner restaurants in plain text, and a form where people could submit their orders. That would have been quick and dirty, but it would also have been ugly and hard to use.
We considered a “cloner” site. You want to start the next Uber or Airbnb competitor? There are companies that sell ready-built software that will get you most of the way there, at a fraction of the cost of rolling your own from scratch. But these clones — say, of a well-known online restaurant marketplace like GrubHub — still cost several thousand dollars, which isn’t exactly loose change. We didn’t much like the look of them anyway.
We figured a reasonable middle ground was to use a drag-and-drop website builder, like Wix. They’re cheap (less than $50 USD per month), simple to set up, and pretty decent looking. They also have a ton of third-party components that you can plug in.
Happily, there was just such a component available for restaurants looking to take orders online. It allowed a restaurant to put up its menu, and let people select what they wanted and submit their order. The site administrators would receive an email once they did. It sounded right up our alley, so we went with it.
Needless to say, it wasn’t all rainbows and parades. The basic problem, from which all others stemmed, was that the component was intended for a single restaurant, but we were using it to host the menus of several restaurants. That forced us to resort to all sorts of hacks to get it to do what we needed.
For example, there was no designated area on the site to put the descriptive information about each restaurant — like its address and opening hours — so we stuck it in a menu section heading. We had to specify where the restaurant was located, but with several restaurants on board, obviously we had no single location. So we set the location to be the center of a roundabout in our main operational zone. That was a little confusing for customers. We couldn’t give each restaurant its own opening hours, so we ended up making each menu item available or unavailable, one by one, according to whether the restaurant was open. That was tedious, but it did the job.
There was also no way to tell which restaurant an order came from, other than the name of the menu item. So if an order came in for a “Veggie burger”, and that item existed on two restaurants’ menus, it was impossible to tell which veggie burger the customer ordered. In practice, that meant we had to introduce subtle differences in menu item names, and then remember what those differences were. We messed up a couple of orders as a result, but by and large we managed.
Performance was another problem. The component we used was built to accommodate a typical restaurant menu, with maybe 50 items at most. We were using it to host hundreds. Unsurprisingly, that eventually made it slow and prone to crashes.
Still, the thing worked, it cost next to nothing, and while we found it a little embarrassing to look at, it wasn’t hideous. So it allowed us to get going. And getting going allowed us to learn all kinds of interesting things without spending any serious money.
We learned what menus looked like in practice. We learned about the problems that arise when submitting orders to and collecting orders from restaurants — everything from restaurateurs not answering the phone to navigating tricky parking. We learned about customers: what restaurants they liked, what they bought, what time they ordered, and how much they’d pay for delivery. We learned about the daily and weekly cycles of demand and how many drivers we needed to handle it. We learned what problems our software, once we built it and ditched this MVP, would have to solve.
Most importantly, we learned that there was a business there. It was the MVP that gave us confidence to take the next step.
And that’s where we are now.
