FoodTech Tweaks Lean Startup Recipe for 210 Billion Dollar Industry

Spend as much time around chefs as we do, and everything starts to take on restaurant speak. We try to avoid being “86” coffee at the office, our sales team goes into overdrive when they get a ton of signups at once and find themselves “in the weeds”, and product is constantly asked to deliver new features “on the fly”.

That last one is complicated. People often assume that building product on the fly means rushing untested, mediocre features out the door, and improving and iterating later, but ask a high-end chef, or watch one episode of anything starring Gordon Ramsay, and you’ll find out pretty quickly that that simply, uh, will not fly--not in the kitchen, and not in companies that service the kitchen either. The best restaurants don’t let a plate go out unless it will make their customers happy from first look to last bite, and they expect the same level of professionalism from everything in their kitchens, including BlueCart.

One of DC’s best chefs recently asked us, “How does every single thing you guys do work so well? Most apps I’ve tried don’t really understand what happens between restaurants and suppliers, but you guys seem to have covered all the angles. How does that happen?”

Co-founder and CTO Jag Bansal explains, “The secret is in slightly tweaking the lean startup recipe to create new features and products quickly, without sacrificing quality or releasing anything that our customers might send back for further cooking.”

Unlike KFC and Coca-Cola, we are willing to share our recipe.

First, the foundation, the heat and oil that get everything crackling: Our office.

The BlueCart office has an open floor plan, where software developers, sales, operations, marketing and founders sit intermingled, intentionally. Obviously this is nothing new, but having constant cross pollination across the team has been essential not only to making our product more useful, but also to actually accelerating our “cooking” time by enabling our product development and sales teams to continuously provide feedback to each other and avoid the development of too many extra “garnish” features that no-one would use. Garnishes can look great, but they have no practical use to diners and too many may take away focus from the key elements on the plate.

Now, the main ingredients in the BlueCart Feature Dish:


  • 1,000s of feedback calls and client visits
  • Handful of focus groups with chefs, suppliers, and industry experts
  • 100s of hours of product development
  • 1 External user testing team
  • 100% company wide testing
  • Pinch of Beta users
  • 100% roll out


Our not-so-secret recipe is a 6 step process involving a tremendous amount of love and care. It all starts with collecting feedback.

Step #1: Our sales, operations, and product teams collaborate with existing clients to learn about their operations. We observe them in action – how they go about their day in the kitchen, learn about the hectic pace of work, listen to their wish lists, and collect ongoing feedback from our quarterly feedback calls and client visits. Here we track recurring requests, and look for patterns to prioritize the top features. These features are then wire-framed by our designers and presented to our focus groups in Step 2.

Step #2: We hold focus groups with chefs, industry experts, and suppliers to further flush out these potential functionalities, ensuring we do not miss any “must haves” and conduct mock activities with our wireframes. It’s important to note that we don’t just take their word for it when it comes to what they want. We watch them actually interact with the product. If they say they really want a feature, but we never actually see them use it, we know we can keep this on the backburner. At this point we have a clear set of business requirements.

Setp #3: After prioritization, our team goes to work and develops the solution for a given set of features. It starts with designing the user experience to solve the given problem and all the intricacies of writing code for web, Android, and Apple devices. It’s a delicate dance of making our product as intuitive as possible and robust enough so thousands of clients across the nation can use it seamlessly. Once the design and software engineering team finish their work, the feature is ready for testing.

Step #4: Here we first use an external team to test our latest features. The goal is to break the product and find all the areas where things go wrong. Next, comes internal testing. Every single one of our employees tests the new features, from social media interns to our CEO--everyone (and we track this!). This way we train and educate our entire team on the latest build, and further polish the finished product. Only after all the defects are fixed, the new features are ready for our clients, or almost ready...

Step #5: To ensure the user experience fits the busy lifestyle of the chefs that will be using our product, we start with a beta release. Essentially, we open up the new features to a limited set of clients, and get their feedback. Think of Google or Facebook asking you to try out a new feature, before they make it available to general public. Once again, our team is monitoring the feedback from beta users very closely, so we can make any enhancements to our apps as quickly as possible. After all, who better to tell us whether the app is working as they thought it should, than our actual clients.

Step #6: Once all the i’s are dotted and t’s are crossed, things go in motion for a full release. It’s a concerted effort between our sales, marketing, and engineering teams to notify the current and new clients of what’s to come, and of course to release the new features without interrupting current users. Our clients can then update their apps and go on with practicing what they do best.

As you can see, this process is a slight departure from the beloved Minimal Viable Product (MVP) model. Like high-end chefs, we can beta test here and there, but our user base simply does not have a critical mass of early adopters patient enough to trial a buggy product. Last year we learned of a software company in our space that developed 18 MVPs in 12 months! Imagine if a chef opened 18 mediocre restaurants, or even pop-up dinners, in 12 months. The chef’s reputation would be shot, and customers would avoid his next openings for fear of getting burned again. That’s exactly what happened to the MVP addicted startup. Users lost trust, and they approached us to buy them late last year.

Chefs react to bad products the same way their customers react to bad food. They spread angry reviews and refuse to try your next stuff, even if you promise it’s really, really good this time. As a result, we must consistently provide our users with a great product experience and justify time after time the love for the products we build. So, we follow our own recipe.

The reviews are great so far.