How we built the technology behind HelpKitchen

In late April, as coronavirus shutdowns across the US caused millions to lose their jobs overnight, the food security system imploded. Viral photos on social media showed massive food bank lines wrapped around city blocks and it seemed like the food supply chain was at risk of collapsing. It was around that time that Eric Ries reached out to a small group including myself, Justin Mares, and Jeff Nobbs to see if we could help him come up with a model to feed the people excluded from the existing food security system.

Together, we thought of an idea that could simultaneously help both those experiencing hunger and the restaurants facing unprecedented economic disruption. By building a lightweight tech solution, we could connect those who needed meals with restaurants that had the need for customers as COVID-19 evaporated their customer base. We’d fund the meals on the back end, through donations.

We started small (insert lean startup joke), and our V1 was a no-code Twilio bot that asked the person texting it a few questions to figure out location, how many meals they needed, and their first name. The bot deposited those requests into Airtable, where we could manually match them with a restaurant. We used an Airtable block to send out Twilio SMS messages right from our spreadsheet — and gave restaurants a read-only view of their "database" where they could see the orders we’d matched with them. Once a meal was picked up, the restaurant could click a link in the table, which would trigger a Zapier workflow to mark the meal as fulfilled.

Once this was ready to test, Jeff handed out the Twilio number via flyers to those at the back of the foodbank lines in SF. As hundreds of requests started flowing in, we validated the technology and were amazed to see just how high the demand was for a service like this — another kind of validation as we moved forward.

Version 1 of our bot in Twilio Studio

A week later, we hit our first limit: We didn't have the human bandwidth to match the number of hungry families texting us. We could reasonably text and support 300-400 families a day, and the pick-up process was seamless. However, if more than 400 texts came in, our system broke down. As we added more restaurants in more neighborhoods, we began working on an automated solution.

One of our developer volunteers, Jason Dielman of Twilio, started working on a Javascript-based algorithm that could plug directly into our Studio workflow via Twilio functions, allowing a lambda function to automatically match and direct people to their matched provider.

In the meantime, we needed a stopgap to handle our growing number of requests. I reached out to David Head, who, the last time I saw him, was running one of the most complex Google sheets I imagined existed. He jumped in and within a few days, built a Google Sheet matchmaker that could automatically assign users to matched restaurants. We kept it simple by always matching for the following day, and instead of collecting location, we asked those texting which neighborhoods they could most easily access. After testing, we launched and quickly saw our daily meals reach 1,000 meals served per day. It worked!

With a stable product able to meet the current need, we shifted our focus to building an overall more reliable service that could scale to other cities, as well as balance capacity across our network of restaurants. Jeff was building out an impressive operations effort with our restaurant partners, working with owners to get our cost per meal down from $10 on average to just above $7. As Eric and Justin worked on raising our first funds and putting that money to use, we needed to define a growth path that allowed us to help as many people as possible.

In a Slack team, we assembled an amazing group of volunteer developers. USDR connected us with Ryan Wang, who wrote code to get user feedback, as well as "remember" repeat users to avoid collecting their details each time they text. Through Twitter, Tom Monks joined up and helped us build functions to track our statistics and user inputs. Meanwhile, Jason and I plugged away at the automated system.

Two weeks later, we went live with V2, which we’re still running today. The new bot ensured that we could now handle thousands of requests per day. In San Francisco, we hit a new milestone: serving 20,000 meals in one week.

Here’s how V2 works:

When a user texts our number, we first run a number of checks. The first is to see what language they speak. We use keywords to identify language, as the bot is fluent in English, Spanish, and Chinese. We then check if they’ve texted before, and if not, ask a few intake questions to best match them.

We then take their family size and zip code and run that through our meal-matching algorithm. Jason built an algorithm to balance restaurant capacity so that we can make sure we give each restaurant a consistent flow of meals per day. This is important for our provider owners, who use that consistency to avoid layoffs and keep their kitchens running.

The algorithm uses the Google Distance Matrix API to find the restaurants that have "balanced capacity" closest to our family in need. We then text back that family with three different pick-up options based on time and location. Now, we can match meals up to 3 days in advance. This way, if there isn’t a meal available in their neighborhood until tomorrow, they have the option to travel a bit farther to get a hot meal today.

Once they’re matched, we send over the name and address of the restaurant and a pickup window to get their meal. One of the most important pieces of this entire process for us is that the pickup process is as dignified as possible. We want all of our users to be able to walk into a restaurant and pick up a meal just like they would with a normal takeout order.

A few hours after the meal has been picked up, we send out a request for feedback. Ryan built out a function to collect a 1-5 star rating and a space for our users to comment on their experience, which then goes right back into the restaurant’s dashboard. We get to see what’s working on our end, and the restaurants get to improve their experience as well.

Version 2 of our bot, zoomed all the way out, in Twilio Studio

Now that we’ve served over 175,000 meals in San Francisco and Detroit and we’re looking for more ways to help improve this model and bring it to other cities. If you’d like to help out in any way, including sharing ideas for V3, please visit our website at HelpKitchen.org and use the contact form there.

I know there’s a stigma in Silicon Valley about "tech people jumping in to solve a problem that’s already been solved" — but in the case of COVID, I’ve been blown away at the amount of good work being done in tech right now. We can only overcome this urgent crisis if we all come together and put the needs of our communities first. We must think deeply about the tools, ideas, and access we have as individuals and make the choice to prioritize our creative and technical energy to do good. Creating HelpKitchen has shown us how quickly an idea can become a lifeline for thousands of people. We’re proud of what we’ve created and we’re humbled to see its impact after just four months. There is still much to do, and we couldn't have accomplished any of this with the many people who have opened doors and supported us along the way.