The soup kitchen build: fitting tools to real workflows

Early in IronForge's life, I did a community project for the Laramie Soup Kitchen, and it taught me more about how automation succeeds and fails than some paid contracts have.

The problem

After every food pickup, staff spent 30-plus minutes recording donations on paper forms, then re-entering everything into spreadsheets later. Multiple pickups a day. For an organization running on volunteers and goodwill, that's a brutal administrative tax on people who signed up to feed their neighbors, not to do data entry.

What I did differently

I didn't gather requirements in a conference room. I went on the food pickup runs. I watched how donations actually came in, watched the inventory process firsthand, felt the time pressure volunteers were under during busy donation periods.

That changed the design completely. Sitting at a desk, I would have built a nice orderly form. In the field, you learn that donations show up as a chaotic truckload while three other things need doing, and nobody has a free hand, let alone patience for dropdown menus.

So the tool met the chaos where it lived: barcode scanning for packaged goods, AI photo analysis for bulk items, voice descriptions for the weird stuff that fits no category. Smart categorization, weight calculations, and donation value estimates happened automatically underneath. On its best runs, the 30-plus minutes dropped to under 10, with the data organized and ready for reporting instead of waiting in a paper pile.

The honest part

Notice I said "on its best runs." Here's the part a case study would normally skip: I don't think the tool I built was good enough, and I'm still working on that.

The staff already had a system that worked. They knew it cold, they were fast at it, and they were comfortable with it. Paper and re-entry is a tax, sure, but it's a tax they had fully priced in. To beat an incumbent system like that, a new tool can't just be clever. It has to be clearly, obviously easier, every single week.

And this task fights back. Donation intake runs on human intuition more than it looks like from the outside. Every week brings different donations: different types, different conditions, oddball items that fit no category, judgment calls about what something is even worth. A tool that handles 80% of that smoothly still leaves the hardest 20% to work around, and the workaround erodes the whole gain. Asking a busy kitchen to shift onto experimental software for modest gains is a huge ask, and my tool struggled to justify itself against that bar.

So this one is still open. I'm still trying to find a configuration simple enough, and genuinely easier than the way they already do it, to deserve adoption. Not fancier. Easier. If I can't find it, the honest answer is that this task belongs to humans for now, and I'd rather say that than pretend otherwise.

What carried forward

That project set the bar every IronForge build has had to clear since: not "does it work," but "is it clearly easier than what the client already does, on their worst day, on their weirdest week." Show up and watch the real workflow before designing anything, because the conference-room version of the work is fiction. Respect the incumbent system, because comfortable-and-working beats clever-and-new almost every time. And when a task runs on human intuition, be honest about whether the tool is helping or just adding steps.

Step one of how I work is "I learn your business" for a reason. I learned it hauling donated food, and it was worth more than the code.

-Thayne