Why this is hard
The non-obvious constraints that keep these problems unsolved, so a builder doesn’t assume “you just
need this one magic technology.” These operate at both the user level and the system level.
(Draft, the fuller constraints section lives in the sector source report and will be folded in once it’s in the
drive.)
At the user level
- Stigma and dignity. Many clients will not engage with support that costs them anonymity. Privacy is
a first-order requirement, not a feature.
- Safety fears. Some clients (e.g. Marguerita) worry about ICE and family
safety, which raises the stakes on anonymity and data handling.
- Access. Transportation, time, limited devices and data plans all limit what clients can reach and
use. Solutions must be light.
At the provider level
- Volunteer-led, time-poor, low-tech. Small pantries are often run by volunteers like
Gladys (75, iPad + flip phone) with limited skills, hours, and a
no succession plan risk. Anything built must demand near-zero setup.
- No infrastructure. Limited refrigeration and storage mean food can’t simply be held over time.
- Missing data. Providers like Dan often operate without the data they need,
not solving the problem badly, but with a complete gap, which leads to waste (wrong food to the wrong
place). Many of these are greenfield, missing-data problems where data collection is the hard part.
At the system level
- Disconnection from networks. ~40% of orgs sit outside Feeding America (see
landscape.md) and lack visibility, support, and funding.
- Data fragmentation and trust. Data isn’t aligned across organizations; sharing it requires trust and
must meet administrative requirements: one of the two design questions tackled at the event.
- Funding and policy constraints. Sometimes orgs can’t act on a known gap because funding or policy
blocks it, not a “doing it badly” problem but a “can’t execute” one.
What this means for builders
Don’t treat these as pure software problems. Expect to design with the community, to handle privacy as a
hard constraint, and, for the missing-data jobs, to treat data collection itself as part of the
product.