The FoodXChange: a donation marketplace for surplus food, 25+ screens shipped, headed for Greater Boston

I. Stakes

Food waste is a logistics problem dressed up as a moral one. A third of the food we produce never gets eaten, and surplus food and food-insecure people often live in the same zip code. The bottleneck is not supply and it is not demand; it is matching, scheduling, and trust, which is exactly the kind of bottleneck a marketplace can attack.

II. Decisions

Protect the donor's 30 seconds

Restaurants need to post in under 30 seconds or they won't.

The supply side of a food marketplace dies on friction, so the post flow is two taps: photo, title, expiry, dietary chips, done. The welcome screen holds the same line, three feature pills and one CTA, no survey, no forced email entry. A restaurant manager at closing time will not fill out a form, and every screen upstream of the feed exists to keep that person posting.

Gate contact behind trust

Recipients request; donors accept or decline with one tap from an approval queue. Contact information is shared only after a donor accepts, and reputation does the rest of the work: ratings and listing history let strangers vet each other before food changes hands.

Keep coordination in the app

Once a request is accepted, pickup gets arranged in a realtime thread over Supabase channels, with online presence and unread state. Pickup happens in DM, not over text, which keeps the listing, the thread, and the reputation in one place.

Rank the feed by distance

The feed sorts listings by location and freshness; search adds radius, category, dietary, and saved-search filters, all backed by Postgres + PostGIS. Proximity is the product: a sourdough loaf is only worth claiming when it sits 0.4 miles away and expires today.

III. What shipped

25+ screens on iOS and Android from a single TypeScript codebase: React Native under Expo Router, NativeWind for styling, TanStack Query and Zustand for state, and Supabase underneath, Postgres with PostGIS for radius search and realtime channels for the pickup threads. The structure below is the live router; the screen map after it is the product in ten lines.

app/
├── (auth)/          # welcome · get started · log in
└── (app)/
    ├── (tabs)/      # home · search · post · messages · account
    ├── listing/     # detail · one-tap request
    ├── chat/        # realtime pickup threads
    └── requests/    # donor approval queue

IV. Results

The honest ledger: the app runs, the market does not exist yet. 25+ screens work on iOS and Android today, but The FoodXChange is pre-launch, so there are no user counts, no pickup times, and no diverted-food totals to report, and this page does not invent them. The first market is Greater Boston, and the numbers that matter, listings posted, claims completed, median pickup time, will come from there or not at all.

V. What I learned

• Marketplace supply dies on friction. The two-tap post flow is the most important engineering in the app and it barely looks like engineering: every field removed from the donor form is worth more than a feature added anywhere else.
• Trust has to be built into the product, not written into a policy. The approval gate, the ratings, and the in-app threads exist because strangers exchanging food need a reason to trust each other before the handoff.