Second Seating

Slide Deck 1
Slide Deck 5
Slide Deck 4
Slide Deck 7
Slide Deck 6
Slide Deck 2
Slide Deck 3
Whiteboard Brainstorming
Whiteboards RICE Framework
Whiteboards
Whiteboard Data Flow Diagram

Inspiration

Every night, restaurants, cafes and grocery stores throw out good food while 12% of people in the Lowcountry Food Bank's 10 coastal counties face food insecurity. U.S. food service ended 2024 with about $156 billion of surplus food, and under 1% was donated (ReFED). When restaurant companies were asked why, they named transport, liability and storage. The food is already cooked and nearby. What's missing is a simple, trusted way to move it.

What it does

Second Seating is a free, phone-first web app for three people:

Donors post tonight's surplus in two screens, tapping dishes from their own menu. The app suggests a category and allergens; the donor confirms each one. They can follow the offer to the door.
Pantries see what they still need this week, with the most-needed food flagged, and every delivery on the way, with when it arrives and how to store it.
Volunteer drivers see pickups on Google Maps, nearest first, claim one, and get directions. Only one driver can win a pickup.

Four rules make it safe to say yes: no pickup until a pantry accepts it, approved volunteers who are never paid per trip, organizations only (never individuals, no public map of need), and unknown food details shown as unknown, never as safe.

How we built it

Next.js and TypeScript on Vercel, with Supabase Postgres and Auth, and the Google Maps Places and Routes APIs. Every write goes through a named, reviewed database function, and the "one driver wins" claim is a single database transaction. Demo data comes from a pipeline that collected 175 Charleston-area restaurants and their real menus.

We built it with an AI agent team defined in skill files: a router sizes each request, a product lead writes the story, a builder codes it, a separate critic tries to break it and never edits, and a librarian keeps the board and decision log. We call our process the Harbor Loop: people whiteboard and decide, write it down, agents build and break, the librarian records, and everyone reads that context before pushing. Our rough ratio was one hour of people planning for every 1.5 hours of agent work.

Challenges we ran into

Two big pivots mid-build: from text-message intake to a web form, and from Firebase to Supabase. Both are logged as decisions.
Keeping six people and parallel agents from drifting apart. We had two competing data schemas early on and reconciled them with a contract test that fails if they diverge.
Being honest about what's live. Some steps, like a pantry accepting an offer, aren't built yet, so the demo labels them as set up in advance.

Accomplishments that we're proud of

50 merged pull requests, 40 logged decisions and 126 automated tests in one weekend
A real single-winner claim enforced by the database, not the browser
Safety rules written before the code, and built into every screen

What we learned

Agents went further because people stayed in the loop. The most valuable agent wasn't the builder; it was the librarian, because no one person could have held all the context.

What's next for Second Seating

Pantry acceptance, handoff and receipt confirmation, and cancelling offers; then donor insights by dish and weekday so kitchens can prep less; then real pilots with local pantries.