Replate

Inspiration

Food waste and food insecurity are both issues in Boston today, and are often overlooked because we’re not “as bad” as LA or NYC. Restaurants and cafés throw away surplus every day while food banks and pantries struggle to keep up. We wanted a single place where businesses could list surplus at a fixed price, buyers could grab affordable meals, and a share of surplus could go straight to local food banks by need. So we built Replate: a Boston-focused surplus food marketplace that connects businesses, buyers, and food banks on one map. Utilizing BU Libraries and Food Insecurity Maps to navigate food to the right place.

What it does

Replate is a surplus food marketplace for Boston. Businesses create listings (title, quantity, price, address, category) and can set a donate % — the app allocates those units to nearby food banks by need and distance, and the rest stays available for customers.

After creating a listing with donations, businesses ask drivers:
“Will you drop it off?”

If yes, they get “Deliver X units to [Name], [Address]” with a Get directions link.
If no, they see contact info so a driver from the food bank or a partner food rescue organization (like Food Link MA) can arrange pickup.

Buyers browse a map of open listings (with filters for open now, price, category, and Gemini-powered smart filtering), reserve a bag, and pick up (e.g., via QR).

Businesses create listings (title, quantity, price, address, category) and can set a donate %—the app allocates those units to nearby food banks by need and distance, and the rest stays available for customers.

After creating a listing with donations, businesses choose: “Will you drop it off?”

Buyers browse a map of open listings (with filters for open now, price, category, and Gemini powered smart filtering), reserve a bag, and pick up (e.g. QR).

Less waste, more meals, and surplus flows to where it’s needed most.

How we built it

Feel free to reach out to amadarap@bu.edu, cmiyai@bu.edu, ns16@bu.edu, kawgit56@bu.edu, or aaudi@bu.edu if you have questions about any of the following sections.

Backend & data

Our backend is FastAPI with MongoDB. Listings have optional GeoJSON location (geocoded from address when creating). We use a 2dsphere index so the map API returns only listings inside the current map bounds.

Business auth is by code (X-Business-Id); endpoints cover:

listings (CRUD)
orders
reserve / pickup / cancel
donation plans

Donation routing uses a separate service: we find nearby food banks (from a food_banks dataset from Boston.gov), score them by need (calculated from a food insecurity dataset) and driving time (OSRM), then allocate donated units proportionally by that score (not winner-take-all) so high-need banks get more.

The ingest script joins food bank CSV data with Census tract food-insecurity data so each bank has a need weight. Allocations include name, address, and phone so the business can drop off or arrange pickup.

Donation allocation & food bank data

We use OSRM for driving-time estimates between listing location and food banks, and Census ACS SNAP data (by tract) as a proxy for need.

The donation routing service:

Picks candidate food banks by proximity
Scores them with
need_weight / (duration_minutes + 1)
Splits donated units proportionally

When a business creates a listing with donate_percent > 0, we:

Run this pipeline
Persist the donation plan
Set qty_available to the remainder
Return { listing, allocations } so the UI can show “Deliver to…” or “Contact … to arrange pickup.”

AI Integration

AI Smart Filtering: We integrated the Gemini API to power natural language filtering for buyers. When a user searches for food, Gemini processes the query to extract intent, categories, and dietary restrictions, which we then map to our MongoDB 2dsphere queries to return the most relevant nearby surplus.

Frontend

The web app is React + TypeScript + Vite. The map page uses Leaflet with a light tile layer; we fetch listings in the current bounds.

Buyers:

See markers
Open a listing
Reserve from the detail page

The business flow:

Login by code
Go to Listings (Mongo-backed)
Create form includes:
- business name
- title
- total quantity
- donate %
- address
- price
- category

On success we show the “Will you drop it off?” choice, then either:

Delivery instructions with directions links, or
Contact/phone for pickup,
plus reservable quantity.

(organizations with currently available driver)

Challenges we ran into

We hit a few challenges:

Allocation fairness: at first, a winner-take-all approach sent most donated units to one bank; we switched to proportional allocation by score so high-need banks get a fair share.
Donation plan vs create flow: we had to keep the standalone donation plan and trigger-expiring endpoints in sync with the new “create listing with donate %” flow so qty_available and donation state stayed consistent.
Algorithm: it took over 50 iterations of experimentation to get the algorithm for food bank “need” scores working. Trying new algorithms and tuning parameters was very tedious.
LLM Prompt Tuning & Latency: Integrating the Gemini API for filtering meant we had to strike a balance between accurate natural language parsing and fast response times. We had to iterate on our implementation to ensure Gemini returned consistently structured data (like JSON) that our FastAPI backend could actually use for MongoDB queries without slowing down the map rendering.

Accomplishments that we're proud of

We’re proud of shipping a full loop:

Businesses list surplus and donate a share to food banks by need
Buyers see a map and reserve
The app handles both:
- “I’ll drop it off” (with directions)
- “I need pickup” (with contact/phone)

The proportional allocation and OSRM + SNAP data pipeline make donations data-driven. Getting the map, filters, business auth, and donation UX working end-to-end in a single Boston-focused app felt like a solid milestone.

What we learned

We learned how much data quality and structure matter for the donation routing algorithm—joining food bank locations with Census tract need and using driving time (not just distance) improved allocation. Proportional scoring beat a single “closest or highest need” winner.

On the product side, making the success message ask “Will you drop it off?” and branching to directions vs contact made the flow clear for businesses. We also got more comfortable with GeoJSON, 2dsphere queries, and keeping backend allocation logic and frontend state in sync.

What's next for Replate

We’d like to add user accounts, implement a rewards system, and add QR-based pickup at the restaurant.

On the donation side:

Notifications when a driver is assigned or pickup is scheduled
Tracking of donated units (e.g. “delivered” or “picked up”)

We’d also like to expand beyond Boston and allow more food rescue partners in the allocation pipeline. Longer term, safecoins-style incentives for businesses that donate could be a fun extension.