Building software for real-world operations eventually means leaving the office.
As part of our ongoing work with Gleaners Food Bank of Indianapolis, members of the Counterpart team spent a recent morning on site observing the Groceries2Go drive-thru program in action. The goal was simple: see how the platform performs during a live distribution and identify where we can continue improving it.
The platform has been live, and this visit was just another part of making sure it continues to perform as intended.
Groceries2Go supports a high-volume drive-thru distribution in which neighbors select the items they want and place orders, while volunteers fulfill them in real time. The system is currently designed to handle around 200 orders per hour and to scale further over time as demand grows and processes are refined. That means the platform, volunteers, and traffic flow all need to stay in sync.
Neighbors begin the process as they pull into the drive-thru distribution site. They can place their order using a web application on their phone by texting a number when they arrive.
From there, each vehicle is assigned a parking spot, and volunteers begin gathering the selected groceries inside the warehouse. Once the order is fulfilled, volunteers load the food directly into the vehicle before the driver moves on (neighbors never leave their vehicles).
It’s a system designed to keep things moving while allowing Gleaners to serve a large number of families in a relatively short window. That scale is why reliability matters so much.
To understand how everything worked together, a few members of our team who work closely with Gleaners spent the morning spread out across the operation as part of the ongoing work to observe how the platform is performing in real use.
Some stayed near the entrance where neighbors were placing their orders. Others followed the process into the warehouse, where volunteers were fulfilling orders. The team also watched how vehicles were directed through the parking area and how orders were loaded before cars pulled away.
Jason, the lead architect on the project, spent much of his time watching how cars moved through the queue and into their assigned parking spots. That flow plays a big role in how quickly orders can be fulfilled, so he focused on where things moved smoothly and where small slowdowns appeared. Throughout the morning, he also listened closely as volunteers and team members shared what they were noticing, gathering ideas about improvements or places where the process occasionally snagged.
Because not everyone on the project team could be there that morning, we also captured photos and short videos along the way. Sharing those moments helps the developers see how the system is being used and better understand the environment it supports. It’s something we’ve found especially valuable throughout this project as the system continues to evolve.
Seeing the full journey helps surface details that are easy to miss during development. Small movements, like how quickly someone can place an order or how volunteers interpret order information, can have a real impact on how smoothly the system runs.
Much of the preparation for a day like this happens well before anyone arrives on-site, and it’s closely tied to how we approach building and validating systems from the start.
JT from our QA team has been running load tests to simulate the same level of activity the platform sees during distribution days. Using one of his preferred tools, he’s able to write test scripts that automatically place orders on the test site and apply load to the system’s endpoints. The goal is to match the number of users who typically attend a drive-thru event and ensure the system is configured to handle the load.
As JT explained, this kind of testing allows the team to work through potential failure points before anything reaches production. The scripts automatically run through the ordering process, placing orders and generating traffic so the team can see how the system behaves when many users interact with it at once.
That work doesn’t stop once the platform is live. It helps the team compare expected performance with what’s actually happening during distributions. It also creates opportunities to refine the experience. Testing can lead to adjustments in screen layouts, interactions, or how different roles move through the system. The more scenarios the team can account for early, the smoother things run when the platform is live.
As JT puts it, it’s always easier for the team to find and fix a bug before a user runs into it.
Observing the drive-thru wasn’t just valuable for developers and QA. User Interface/User Experience (UI/UX), which we more generally refer to as design, also plays a role in these visits. Jade from the design team joined the walkthrough to observe how people interacted with the interface during the distribution process. Real environments often reveal things that documentation can’t.
Jade explained it with an analogy from outside the tech world. Play-Doh was originally created as a wallpaper cleaner, but the company later realized children preferred using it for arts and crafts. Once they saw how people actually used the product, its purpose shifted entirely.
She sees something similar when observing software in action. Reading requirements and designing wireframes can only go so far. Watching how people interact with a system often changes how she approaches the design, sometimes in ways that would have been difficult to predict earlier.
On this particular day, the operation processed roughly 140-160 orders per hour. That range gave us a useful benchmark for how the system performs under steady demand, as well as the time to explore potential improvements to make the overall process smoother when experiencing peaks of 200+ orders per hour.
More importantly, it helped our team understand what the experience actually feels like for the people involved. Neighbors are placing orders from their cars and driving their vehicles through the facility. Volunteers are moving quickly through the warehouse, gathering groceries. Everyone is working together to keep the line moving. Spending time onsite makes those dynamics much easier to understand.
Software always ends up living inside real environments like this. Watching it operate alongside volunteers, staff, and neighbors helps us see what’s working well and where small improvements can make a difference.
For Groceries2Go, those details matter, especially when small improvements can help increase throughput over time. They impact how quickly orders move through the line, how clearly information is communicated, and how smoothly the overall experience runs for both volunteers and neighbors.
Launching a platform is one step. What happens after, how it performs, how it’s used, and where it can improve are just as important. Spending time onsite helps us stay connected to that reality and continue refining the system alongside our partners.
If you’re building something that needs to perform in the real world, we’d love to hear about it.
Posted in Innovation
