Building software for real-world operations eventually means leaving the office.
Recently, members of the Counterpart team spent a morning at Gleaners Food Bank of Indianapolis observing the Groceries2Go platform during a live distribution. The goal was simple: see how the platform performs during a real distribution and understand how the digital system and the physical process work together.
Groceries2Go allows individuals and families to place food orders through a web app before driving through the Gleaners’ warehouse distribution site (neighbors place their orders by texting a number when they arrive). Volunteers then fulfill the order and load groceries directly into each vehicle. On busy days, the system needs to support roughly 150 to 200 orders per hour, which means the platform, volunteers, and traffic flow must stay in sync.
Our team wanted to see how all that looked outside of a virtual test environment.
Neighbors begin the process as they pull into the drive-thru distribution site. Using the web application on their phone (or placing an order with a volunteer), they place their order before moving further into the warehouse area.
From there, each vehicle is assigned a parking spot, and volunteers begin gathering the selected groceries. Once the order is fulfilled, volunteers lead the food directly into the vehicle before the driver exits the line.
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 exactly 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.
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 was paying attention to 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 actually being used and gives them a clearer picture of the environment the platform supports.
Seeing the full journey helps surface details that are easy to miss during development. Small moments, like how quickly someone can place an order on their phone or how volunteers interpret the 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 at the warehouse.
JT from our QA team has been running load tests to simulate the same level of activity the platform sees during distribution days. Using Grafana Labs K6, 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 can handle the load.
JT explains that 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 all at once.
Along the way, it also creates opportunities to refine the experience.
Testing sometimes leads to adjustments in screen layouts, interaction, 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.
And, as JT put 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.
Design also plays a big role in these visits. Jade from the design team joined the walkthrough to watch how people were actually interacting with the interface during the distribution process.
Wireframes and requirements provide a starting point, but real environments often reveal things that documentation can’t.
Jade explained it with an analogy from outside the tech world. Play-Doh was created as a wallpaper cleaner before the company 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 in the process.
On the day our team observed the drive-thru, the operation processed about 140 orders in an hour. It was a slower day than some distributions, but it still gave us a clear sense of how the system performs during a steady flow of vehicles.
More importantly, it helped our team understand what the experience actually feels like for the people involved. Neighbors are placing orders from their cars. Volunteers are moving quickly through the warehouse to gather groceries. Everyone is working together to keep the line moving.
Spending time on site 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 the details that matter most.
For Groceries2Go, those details help ensure families can move through the drive-thru efficiently and receive the food they need without unnecessary delays. Spending time onsite helped our team better understand what was working well and where small improvements could make a difference.
Whenever possible, we like to see the systems we build in the environments where they’re used. It helps us better support the teams relying on them every day.
If you’re building something that needs to work in the real world, we’d love to hear about it.
Posted in Clients, Software Services
