Food Rescue Logistics Software Problems: The 7 That Cost You Donations, and How to Avoid Them

Why does the first release keep growing into a routing optimiser?

The scope conversation in food rescue almost always ends in the same place. Someone says the word routing, everyone pictures a map with coloured lines on it, and within twenty minutes the first release has grown a multi stop optimiser solving time windows against vehicle capacity for a fleet you do not employ. It is the most expensive wrong turn in this category, because real routing optimisation is genuine engineering rather than a mapping call, and for most programmes it is the last thing needed rather than the first.

The reason it happens is specific to this work. A dispatcher's day looks like a routing problem from the outside. From the inside it is a matching problem: which agency can take four bakery racks and three cases of yoghurt today, and which volunteer with a vehicle that fits will actually say yes in the next ninety minutes. Until a driver routinely takes three pickups on one run, optimisation solves a problem you do not have while the matching logic that does run your programme stays in one person's head.

The fix is to write the first release as the loop that already works: donation intake with a computed expiry, an agency capacity model, wave based volunteer dispatch, and a driver app with offline proof of delivery. In Digital Heroes delivery experience that is the $45,000 to $110,000 band, shipping in 10 to 16 weeks. Route optimisation, recurring donation schedules, donor portals and impact analytics belong to the phased $120,000 to $300,000 platform, and every one of them is cheaper to build after the first loop has survived a real month of Tuesdays.

What goes wrong when you move donors, agencies and pounds out of the group chat?

Most food rescue programmes have no data to migrate in the ordinary sense. They have a contacts list, a shared spreadsheet of pounds by month, and a group chat. The migration problem is not moving records, it is that the most important information was never written down anywhere. Nobody has recorded that the pantry on the north side has a walk in cooler but no freezer, that the church accepts prepared food and the food bank branch does not, or that one agency's Thursday distribution means produce delivered on Friday will not move.

That knowledge has to be captured deliberately, and it takes longer than teams expect. Plan a structured pass over your twenty most active agencies before any code exists: storage capacity by type, receiving windows including holiday exceptions, category acceptance rules, and who actually opens the door. Do the same for donors, and record the dock address rather than the street address, because a driver sent to the front of a supermarket is a driver who calls you.

The second trap is historical poundage. Whatever numbers you have already given donors and funders are now the record, and the new system will produce slightly different ones from the same period because it counts differently. Decide before launch whether history is imported as a summary that is explicitly labelled as legacy, or left out entirely with a clean start date. Importing partial old records into the same tables the new custody chain uses is how a programme ends up unable to explain its own annual figures to a foundation.

Why do notification and mapping integrations break after launch?

Every part of dispatch depends on a message arriving on a volunteer's phone within seconds. That is the integration that breaks, and it rarely breaks loudly. Text messages get filtered by carriers when a sending number starts pushing high volume with similar content, which is exactly what wave based dispatch looks like from the outside. Volunteers change numbers and nobody updates the record. Somebody replies STOP to an offer they cannot take, which unsubscribes them from every future message, and they assume the programme stopped calling.

The fixes are unglamorous and must be in scope from the start rather than added after the first bad week. Use a messaging provider properly with a registered sending identity. Treat delivery receipts as data, so an offer that was never delivered escalates instead of sitting in a queue looking sent. Give volunteers an in app inbox as well, so a lost text is not a lost rescue. Handle opt out as a per channel preference with an obvious way back in.

Mapping is the quieter one. Geocoding a donor site by its street address puts the pin on the shop front rather than the receiving dock, which costs a driver ten minutes on every visit until somebody fixes it manually. Store a verified dock coordinate and dock access notes as part of the donor site record, captured the first time a driver actually finds it. Map and routing services also bill by request, so a system that recalculates distances on every list refresh produces a bill nobody budgeted for.

What happens when the custody record and cold chain rules are not covered?

This is the gap that turns a logistics tool into a liability. The Bill Emerson Good Samaritan Food Donation Act provides protection for good faith donations of apparently wholesome food, and the Food Donation Improvement Act extended aspects of it, but the specifics for your programme belong with counsel. What is not a legal question is the operational consequence: protection and donor tax positions both rest on records made at the time, and records assembled afterwards from a group chat are not records.

Programmes that skip this in release one end up with a driver app that captures a signature and nothing else. Then a product recall reaches a donated lot and nobody can answer which agencies received it. Or a donor's finance team asks for substantiation of what they gave and the programme sends a spreadsheet with a total in it.

The requirement is that a complete custody record falls out of the driver simply doing the job: donor, items and categories, weight, condition with a photo, pickup time, transport duration, receiving agency, delivery time, and the name of the person who took it. Temperature controlled items need the cumulative time out of temperature tracked rather than a single reading, with the food safety limit enforced as a check before delivery and a documented decision when it is exceeded. Get this in the first release. Retrofitting a custody chain onto a year of loose deliveries is not possible.

Should you build custom or configure what you already own?

If you run under roughly 40 pickups a week, do not build. Food Rescue Hero and Careit both understand this domain properly, both bring a volunteer experience people already recognise, and money spent on custom software at that scale is money taken out of food. We say this on sales calls and lose work by saying it. There is no honour in a nonprofit owning a platform it does not need.

Configure harder before you conclude a product cannot fit. Most programmes that feel constrained have not modelled agency capacity inside the tool they already pay for, and are working around a gap they created. Fix the data first and see whether the constraint survives.

Build when two or more of these are true. Your matching logic is genuinely local and you fight the packaged model daily. You run a hybrid of volunteer drivers and paid or contracted vehicles, which packaged tools handle poorly. Your donors demand reporting the platform cannot produce and somebody rebuilds it by hand every month. You coordinate a county wide network where the system has to be shared infrastructure rather than one charity's tool. Or a funder is specifically backing a technology build and expects the result to be shareable with peer organisations.

How do hidden costs get into the quote?

Four things reliably sit outside a first quote in this category and reliably show up in the invoice.

• Offline reliability in the driver app. Loading docks, basements and rural roads have no signal. Capturing weight, photos and delivery confirmation locally and syncing later with original timestamps preserved is architecture, not a setting, and a quote that does not mention it has not priced it.
• The agency and donor data pass. Capacity, receiving windows and acceptance rules take real staff time to collect. It is your time rather than the developer's, which is exactly why it never appears in a budget and always delays a launch.
• Running costs. Messaging, mapping, hosting and any document storage bill monthly and scale with pickups. Ask for a modelled monthly figure at your current volume and at double it, before you sign.
• Volunteer onboarding. A new app means retraining every active driver, and the ones who do not convert simply stop appearing. Budget a period of running the old dispatch method alongside the new one rather than a hard cutover.

Donor system integration is the fifth, and it is a real project of its own if a grocery partner wants to push surplus automatically. Keep it out of release one unless the donor is already asking.

What separates a build that works from one that fails here?

Three things, and none of them are features.

The first is that the driver app takes under a minute to complete. Every additional field is a volunteer you lose, and a volunteer who stops using the app takes the custody record with them. Capture what the record and the donor reporting genuinely need and nothing else.

The second is that failure has a path. Unclaimed offers escalate to a wider radius, then to a paid or partner vehicle if you have that fallback, then to a recorded failure with a donor facing explanation. Systems without that last state look healthy while the donor list quietly shrinks.

The third is ownership and a named internal owner. Settle in writing before kickoff that you own the repository, the cloud accounts and the full custody record, and if a funder wants the result shared with peer organisations, agree that at the same time. At Digital Heroes the client owns the code and the data from the first commit. Then name the person inside your organisation who owns the system after launch, because a platform with no owner degrades within two years regardless of how well it was built.