Inspiration
Most people own tools they use twice a year. Their neighbors buy the same tools new. A drill costs $60. Three households buying one each spend $180 on three drills that mostly sit in a closet. We wanted asking a neighbor to feel as easy as adding something to a cart.
Before you buy it, find it nearby.
What it does
Relay is a neighborhood sharing app built around one chat.
- Borrow Tomorrow. Type "I'm building a bookshelf this weekend." Relay lists the tools you need, finds which neighbors own them, and schedules the loan so two people never book the same drill at the same time.
- Need and Offer matching. Say what you need or what you can give. Relay matches the two, and it fills partial asks. One neighbor offers 12 notebooks, another offers 8, and a request for 20 gets both.
- Shared need. When several households want the same item at different times and nobody nearby owns it, Relay shows a card that compares buying alone with buying once and sharing. For a $60 drill and three households, that is $180 alone or $60 shared.
- Garden. Every finished loan or handoff grows a shared garden counter.
All neighbors and items in the demo are fictional.
How we built it
We built around one rule: AI extracts and explains. Code decides. Gemini turns a message into structured JSON that maps to a fixed catalog. Our own code then validates it, ranks lenders, schedules loans, and tracks every status. The model never picks a lender or a time slot.
- Frontend: React, TypeScript and Vite, styled with a Frutiger Aero look.
- Backend: Python and FastAPI. Loans, handoffs, projects and the garden live in SQLite through SQLModel.
- Snowflake: holds the shared neighborhood inventory and the open requests. The backend reads who owns what from Snowflake and writes every confirmed need, offer and borrow ask back to it.
- Matching: a greedy partial fill, plus a lender ranking by distance and overlap with the requested time window.
- Scheduling: a first free slot search with a 30 minute buffer between loans, and an earliest deadline first plan for shared items.
- Tests: pytest covers the matcher, the scheduler and the API flows. A smoke test runs the demo flows against live Snowflake and passes 10 of 10 checks.
Challenges
- Keeping the model out of decisions. It is tempting to let the model pick a neighbor or a time. We kept it to reading messages only.
- Time. Windows arrive as text from chat and as strings from Snowflake. We normalized everything to UTC so a Saturday ask lines up with a Saturday window.
- Honest empty states. Relay never claims nobody owns an item when it cannot see the inventory.
- A plain "yes". The model sometimes read it as a brand new request. Now code answers yes and no before the model sees them.
Accomplishments
- A full loop from a typed message to a scheduled, double-booking-safe loan.
- Partial fills across several neighbors.
- Snowflake working end to end with real reads and writes.
What we learned
Putting a model at the edge and plain code in the middle made the app easier to test and easier to trust.
What's next
Bring the same chat to iMessage, add reminders for returns, and let real neighborhoods add their own items.
Built With
- fastapi
- google-gemini
- photon
- python
- react
- snowflake
- sqlite
- sqlmodel
- typescript
- vite

Log in or sign up for Devpost to join the conversation.