A charity connecting surplus food from shops and restaurants with families who need it wanted to build an app with a suggestion algorithm that would learn what different communities actually use. It had three staff. There was no existing platform to audit, so the work became a scoping exercise instead: what could be built in phases, what existing platforms could carry part of it, where developers might be found at charity rates, and how to prove the concept simply before committing to a full build.
What was the problem?
A charity working to connect surplus food from shops and restaurants with families who need it. Small team, meaningful budget by charity standards, and an idea that was more ambitious than either.
If you sit on a charity board and a project like this lands on your desk, a checklist built for trustees helps you pressure-test it before any money is committed.
The charity wanted to build an app. Not just a matching service pairing a food donor with a food bank, but something more sophisticated: a suggestion algorithm that would learn what kinds of food different communities would actually use.
The thinking behind it was sound. A pallet of coconuts donated to a food bank is generous, but if the families that food bank serves do not cook with coconuts, the food is wasted twice over: once by the business that could not sell it, and again by the families who cannot use it. The proposed app would track what was available, what was needed and what actually got used, then learn over time and suggest redistribution routes reflecting cultural preferences, dietary needs and practical constraints like storage and transport.
For a funded tech startup, that is a reasonable product roadmap. For a charity with three staff, it was a different proposition entirely.
What did I do?
There was no existing website or platform to audit, so the brief shifted. Rather than reviewing what was there, the work became a scoping exercise built around a few questions:
What could realistically be built in phases, rather than all at once?
Were there existing platforms that could handle part of the problem, without a custom build from scratch?
Where might the charity find developers willing to work pro bono or at charity rates?
How could the concept be proven with something simple, before committing to the full build?
What was the result?
A scoped, phased view of an idea that had arrived as a single large one, with the question of proof moved to the front: what is the smallest thing that would show this works, before any money goes into the algorithm.
What does this show?
Digital work is not always about selling more or driving more traffic. Sometimes it is about getting surplus food to families before it ends up in a skip.
The technology to solve a problem like this already exists: the APIs, the algorithms, the platforms. None of it is technically out of reach. What makes it hard is the funding model. Charities cannot raise venture capital. They cannot run at a loss for three years while they build a user base. Every pound has to be accounted for, and every project has to demonstrate impact to funders.
Organisations like this one exist in every region, and most of them do not need advice on their mission. They need help building the tools to deliver it.
Because there was nothing to audit. No existing website or platform, just an idea, so the useful work was establishing what could be built in phases, what could be bought rather than built, and what the smallest proof of the concept would look like.
Is an idea like this too ambitious for a small charity?
Not necessarily, but not all at once. The technology exists and none of it is out of reach; what a charity cannot do is run at a loss for three years while it builds a user base. That is why the question is what phase one looks like, not whether the whole thing is possible.
Not sure where to start?
Most clients begin with a conversation. No pitch, no hard sell.
Just a straightforward discussion about where you are and whether I can help.