Every day, our team of 10 developers, marketers and product folks head out into the city to get lunch. We’re a close team, and that means sticking together and all going to the same restaurant. Given the various personalities and palates we find ourselves debating, arguing and fighting over where to get lunch. It’s a process, like clockwork, that begins around 11:30am and can last upwards of 20 minutes. Everyone has their quirks – John doesn’t like a particular place, Colby has issues with another, and because there are nearly 10 of us that go out to lunch each day – finding the common denominator becomes a difficult and lengthy process.

What it does

Lunchio simplifies this process by identifying and recommending the most favorited restaurant among luchio users getting lunch that day. Simply add your favorite places for lunch to your profile, as well as the places you’ll never go, and lunchio does the rest. Start a lunch request by inviting your teammates and friends using slack command: /lunchio invite @user, and once all teammates have accepted, lunchio finds and recommends the place everyone will love.

How we built it

Lunchio is written in javascript and has its logic divided into a number of commands that are independent and have clearly defined roles. The commands carry channel and user identifiers through the lunch picking process to give its decisions context. To keep things as stateless as possible, the lambda function interacts with a dynamo db schema that was designed to be simple as well as scalable to support later features. The database holds user preferences such as favorite cuisines and restaurants, as well as user specific ban lists.

Challenges we ran into

First and foremost, Slack was blocked by our internet security team. As an insurance company we’re pretty locked down and getting it unblocked for an afterhours, unfunded project, was not effortless. Additionally, like many projects we’re faced with, feature creep was front and center. We have trouble deciding on a place to go for lunch so locking down our core product was a challenge we had to work through. Ultimately, solving the fundamental problem of identifying the restaurant guided our decision making. Finally, a large piece of the inspiration for lunchio was to offer an experience that was as easy for the user as possible, to contrast with the painful daily negotiations. A big part of that was incorporating language processing into the process as much as possible to save users from having to memorize unwieldy commands.

Accomplishments that we're proud of

This was an un-sponsored, unfunded project that had to be done after work hours. We’re proud to have committed the time and energy as a team during nights and weekends to learn, code and launch lunchio. Most of all, lunchio is something we’ll now use every day to decide where we go to lunch

What we learned

For starters, how to manage a project from end-to-end. We also learned that starting with the idea first, and then trying to solve for the technical limitations can prove challenging. Next time, we’ll approach from the bottom up (understand tech first) then use the tech to solve the business challenge

What's next for

Weather can play a role in where we go to lunch. Pouring rain? We want to go close. Is it freezing out? We want to go even closer and probably have a hot meal. Integrating current weather conditions into lunchio’s recommendation engine is a must have for version 1.1. Additionally, the ability to integrate with iCal or Outlook calendar is another must have. Lunchio will not only recommend the restaurant, but will also find the optimal time to go, and send everyone a calendar invite. Lastly, on Friday’s or before holidays, we enjoy taking a longer lunch and maybe even sitting down to eat. Lunchio will have the ability to account for these times when our enthusiasm to dine is higher and recommend appropriately.

Built With

Share this project: