Do you trust online reviews when everything seems to have a 4.5 rating? Several products or sites have recommendations on where to eat, what to watch next, or lists of “the top 5....” However, they tend to be biased, and they are hard to trust (when you know several are incentivized). 

People need a way to store and share recommendations from their friends for different categories such as places to eat, movies, etc. because you can’t trust site reviews (e.g., Yelp, Google, FB). Furthermore, you can obtain great ideas or recommendations by leveraging your own network and asking your friends. 

BEST helps users reduce decision fatigue by assisting them in asking questions about recommendations to trusted friends or contacts, storing and visualizing answers. BEST makes users feel more confident about their decisions. 

Research & Validation

Since all three of us have sought out recommendations from people in our circles in various categories, it seemed like this would be a fairly universal problem space.  While the idea was to create a network for an endless number of categories, we needed to narrow it down for the MVP and landed on restaurants as the space to focus on.  To validate the usefulness of a recommendation app that would be this focused, Nathan conducted five user interviews to analyze the decision-making process for eating out and ordering in.

While all five interviewees shared certain pain points related to finding a new place to eat, this issue was most relevant to those who didn’t have young children and who lived in large cities, given that they dined out with more frequency and had enough untested options to make the choice somewhat daunting.


Key findings

While all the interviewees looked to review sites when choosing a new place to eat, they barely ever left reviews themselves, if at all.  However, they all shared recommendations with friends and found the advice they received from friends was much more likely to live up to their expectations than going by Yelp or Google Maps star ratings.

Furthermore, despite the success rate of going by word-of-mouth recommendations, only one of the five actively kept a list of the places that had been recommended to him.  Four of the five mentioned that proximity was a major determinant in where they chose to eat, and two of the five were sometimes motivated by the vibe or atmosphere rather than a specific cuisine.

How much of a pain point are we talking about?  Four out of five said that deciding where to eat can be stressful or a chore.  They said it was too time-consuming and that it’s harder to decide when they’re going with friends.  2 of those also mentioned how hard it is for everyone to agree.


Much of what we learned validated our problem space and basic solution.  More importantly, however, the interviews led to more specific insights that would help to prioritize features, such as the usefulness of a map view and the potential to categorize by the feel of a place rather than only cuisine.


Our first pivot:

We initially envisioned building a web service where users could ask for recommendations about several categories, such as the best restaurants, movies, etc. However, to prove our hypothesis, we realized that it would be best to limit the options for posting questions instead of giving them a myriad of options. 

Our second pivot:

During our research, we realized that 80% of survey respondents focused on where to eat the best (you name the dish) in a certain location. After exploring different ways to make it easier for the user on how to build a query, we focused our MVP on solving the pain point of finding the best restaurant by posting the question to a list of contacts selected by the user. 

We felt that our idea was limited by focusing on finding the best restaurants. However, we realized that we can prove our hypothesis that people have decision fatigue, online reviews are hard to trust, and people trust their friends’ opinions. 

Furthermore, when we realized the core functionalities that would be part of the MVP, we prioritized the features to be built as well as created a product roadmap. 

Design & UX

We wanted this app to be simple to use and to feel casual.  At the same time, it needed to have an element of class that one would associate with quality dining.  The logo we landed on was a wordmark with bold lettering and bold color, with the letters composing a perfect square to give a sense of a single unit – a monolithic representation of the idea that BEST means one single supreme option.

To combine fun and class, we used Renaissance artwork depicting a grand feast, with the bold wordmark superimposed.  This was intended to make the artwork seem slightly ironic rather than earnest and pretentious, and with the idea that different works of art could represent different categories as the app expanded beyond restaurants in the future.

The app was so back-end-heavy that only the most basic features could make it into the MVP within the time constraints.  The resulting UI was straightforward, using patterns that users were familiar with, so the basic tasks of requesting recommendations from friends and finding details among the responses turned up a 100% success rate when testing the prototype with five different users.

The basic tasks were:

Requesting Recommendations

 Giving Recommendations


 And navigating through responses:


We collaborated as a team by following one-week sprint cycles. During our planning sessions, we would determine the priority of every user story and make sure we had all acceptance criteria captured. 

We had daily standups during our project’s development phase; this helped keep the momentum and communication as a team. Also, by meeting frequently, we would learn more about the technical implications of focusing on our MVP’s core functionality to avoid developing “nice to have” features due to time constraints. 

Furthermore, Ian, our developer would make sure to communicate the technical aspects of every feature and share his research and provide prototypes so we could see the progress of our product.

The following features are part of the first version of BEST:

  • Login through a Google account
  • Formulate a question
  • Pre-populated categories to facilitate question formulation
  • Create groups of contacts to post questions
  • Store answers
  • Visualize answers


We committed to creating a product that depicts how to solve decision fatigue by leveraging our networks and stopping trusting reviews from commonly used websites. We realized that four out of five people we interviewed expressed decision fatigue around finding a place to eat with our research. By developing BEST, we can help people make decisions while nurturing and keeping in touch with their contacts. 

Through our Co.Lab experience, we realized that it is possible to create a high-quality MVP that solves a pain point within weeks. Learning is better when done together with like-minded people, and a diversity of backgrounds makes a richer experience. 

What’s Next

We intend for BEST to be a self-contained ecosystem - almost its own mini social network.  The next step would be to convert it into a native app that can more easily access the users’ contacts and then enable invitations and connections as one might have on Facebook, LinkedIn, etc.  The Google capability was merely a bare-minimum necessity for accessing at least a small number of users’ contacts and communicating with them.  However, the goal for BEST is to have communications like requests and responses take place in-app to ensure that the process is as streamlined as possible.  

Furthermore, once connections can be established within the app, users will see if and how any of their contacts have already answered a recommendation question, asked by someone else too, who they may be unconnected with.  Thus, the app will serve as a repository of these recommendations and will not always require the user to ask for suggestions and await responses.

Eventually, the idea would be to expand well beyond restaurants to include home services, vacation recommendations, books, movies, etc.  The functionality will be added to allow users to recommend the things they love without even being asked.

Another feature will be “follow” as it exists on Facebook, Instagram, etc.  Users will be able to see the recommendations of influencers and celebrities whose tastes they admire.


Product Manager Learnings:

Alexander Marlowe

  • Jobs-to-be-done theory: to ensure we solve a pain point with a product that is valuable
  • Agile: Optimized the execution of the product by dividing the development into manageable sprints that tied to specific user stories
  • Storytelling: Critical skill to pitch the idea to cross-functional team members so they can envision what we are trying to solve.

Designer Learnings:

Nathan Chitayat

  • Figma: Use this project as an opportunity to hone a familiarity with this robust and industry-leading app.
  • Constraints: Working with a cross-functional team introduces the realities of time and tech constraints and makes prioritization for an MVP much more complex

Developer Learnings:

Ian Belknap

  • New tooling and tech stack: Next.js framework, Prisma ORM, TypeScript, OAuth, Google People API

Developers Learnings:


Full Team Learning

As a team with diverse backgrounds and dispersed across three different US states, we realized that communicating often would make it less difficult to develop a product within a limited number of weeks. We all kept an appetite for learning something new and developed a growth mindset that is crucial in today’s tech world.