Rethinking a Staging Environment

Tanner Siciliano
Local Kitchens
Published in
5 min readMar 28, 2022

We’re excited to introduce the physical realization of our staging environment! Local Kitchens builds and maintains a diverse ecosystem of applications that run on a variety of devices, making up what we call “KitchenOS.” Our new staging environment is housed at our San Francisco headquarters and allows us to test new workflows in a mock kitchen with all the capabilities of our physical store fronts. (P.S. We are hiring engineers and designers! Visit our jobs page.)

Our Staging Environment

About Local Kitchens’ “KitchenOS”

Local Kitchens is a micro food hall that lets you mix-and-match your favorite local restaurants in one easy order. Operating a dozen restaurant brands out of a single kitchen is challenging, to say the least. In the early days, we stitched together a variety of third party services to solve this challenge (point of sale, in store kiosk, etc.). We’ve since outgrown generic software solutions built for traditional kitchens, replacing them with internal applications custom-made for our multi brand value proposition. This suite of proprietary products is known internally as the KitchenOS.

Imagine Matt Rudofker, our director of culinary operations, wants to make a menu change to The Melt in Lafayette. This could impact the presentation of the item not just on our website, but also on the in-store kiosk, the kitchen manager app, and importantly on the kitchen display system (the KDS — the primary user interface for the cooks in the kitchen). These web applications are running on hardware that we can’t easily mimic on our local machines — Matt can’t just open up a browser to check how his menu change will render. Meanwhile, we can’t have him calling the kitchen or crossing the Bay Bridge every time he wants to make a change. So we can’t always bring the chef to the kitchen. What if we could bring the kitchen to the chef? Et voilà, the staging kitchen was born.

The KitchenOS coordinates the end-to-end lifecycle of orders in the kitchen — from the moment a guest places an order to the moment it starts cooking, and finally until it is picked up. Orders are placed on a kiosk (iPad), after which they appear on the status board (Fire TV) and the expeditor app (iPad). Further down the line there are multiple different receipt printers involved, as well as custom Kitchen Armor interfaces for cooks.

  1. Status Board: Guest-facing TV that displays the status of orders
  2. Kiosk: In-store platform for ordering
  3. Stripe Payment Reader: In-store payment processing
  4. Kitchen Manager: Front of House application for coordinating orders
  5. Kitchen Display System (KDS): Line item display for cooks; configurable to the specific brand and station the cook working
  6. Expo Printer: Receipt printers for the entire order at the Expo station
  7. Chit Printer: Sticky labels for individual line items at the KDS stations
Kitchen OS Architecture

A Different Staging Environment

As the KitchenOS grew, each new piece presented new challenges. Something as mundane as saving a password can be incredibly difficult to walk a kitchen manager through over the phone if you’re looking at a web browser and they’re looking at a Kitchen Armor interface (especially if it’s the dinner rush in Palo Alto). Printers have very unique debugging steps; the Stripe Terminal connection to the iPad is finicky; the status board sometimes needs to be manually scrolled; yes, Matt already tried turning it off and on… you get the picture.

The physical staging environment — a (not to scale) technological replica of an actual Local Kitchens — could unlock an enormous amount of value for the team:

  1. Test new features end to end from HQ
  2. Build empathy for end users
  3. Train new engineers and Kitchen Managers on the complex product ecosystem
  4. Debug live issues in a production-like environment
  5. Write a blog post detailing the whole darn process to excite prospective candidates ;)

Execution

As we planned and built the staging environment, we had an opportunity to look more deeply at our infrastructure.

Engineering Team Setting up the Status Board (From Left to Right: Jordan Bramble, Michael Parlato, Tanner Siciliano)

For instance, replicating production workflows without interfering with production data was important. That required some changes to how we seed our staging databases. Additionally, we needed to make sure we created an easy workflow for engineers to push changes to this environment for testing purposes.

Lastly, we needed to configure which store all of the staging devices were pointed to with minimal effort. For example, what if Matt wants to test a specific prep station at a specific location, say Nash and Proper in Roseville? That process should be seamless, requiring no more than a few clicks.

Conclusion

Building out this environment has drastically improved product development at Local Kitchens. Now, when Matt wants to add some spice to the menu, he simply walks over to staging and checks out the changes in real time. Engineers are close at hand to brainstorm and problem solve. This encourages cross-functional collaboration, but it’s important to note that it does not take the place of being onsite. In fact, “going where the work is” happens to be one of our core values. Engineers spend time each month in the kitchens — getting to know the guests and staff, working cook shifts to research improvements to our processes, and eating some hella good food!

Our Staging Kitchen in Use by Matt Rudofker (Culinary) and Eduardo Baik (Engineering)

Still, the staging environment has proven incredibly valuable. Some key takeaways from the journey:

  1. We can always improve our infrastructure to make our engineering team more efficient. This includes making sure our environments are properly decoupled.
  2. We can invest more to empower our kitchens to be able to debug issues. Right now, we do not have a clear go to playbook for tech issues in the kitchen. By walking through common debugging issues in an actual kitchen like environment, we have more context on how to build that playbook. Within a day of launching the staging kitchen, one of our engineers was able to walk through an authentication bug with the kitchen in real time.
  3. Our kitchen team has been able to audit our menu systems using this environment in our support center, rather than having to drive to individual kitchens.
  4. We now notice system wide bugs when they happen, and respond to them sooner. We recently had an issue impacting multiple systems, and we used the staging kitchen to diagnose and resolve in real time.

Local Kitchens is hiring across all positions, including engineers and designers! Click here to find a position.

--

--