-
-
1. Campus meals, matched. | TapIn turns 680+ people coordinating meal swipes by hand into one bookable board.
-
2. Search in plain language. | GPT-5.6 resolves the nickname, time, and party size.
-
3. Live availability, verified. | Deterministic rules check hall, time window, and capacity. No payments, no ID transfer.
-
4. Offer in one sentence. | Providers describe when they're free; GPT-5.6 turns it into structured, bookable windows.
-
5. Reserved slots stay locked. | Once booked, the slot is held.
-
6. Coordinate the meetup. | A shared contact space to confirm the entrance and arrival, nothing else.
-
7. Bring TapIn to your campus. | Any school with a mandatory meal plan has the same problem.
-
8. Group-chat extractor. | GPT-5.6 pulls real offers out of multilingual chat. 89.2% exact match on a hand-labeled eval set.
Inspiration
At Columbia, undergraduates are required to purchase meal plans, but some finish the semester with unused guest swipes or more dining access than they need. Meanwhile, graduate students, visiting friends, and campus guests occasionally want to eat at a dining hall without buying a full-semester plan.
Today, these people find one another through scattered WeChat groups, Reddit posts, and direct messages. One Columbia meal-swipe group reached its 500-person limit, and a second group grew to more than 180 people. The demand was real, but coordinating it through group chat was slow and unreliable.
TapIn turns this existing community into structured, bookable availability.
What it does
Meal-plan holders describe their availability naturally:
“I’m available next Wednesday from 3–8 PM at any dining hall, no guest limit.”
TapIn uses GPT-5.6 to convert that message into structured availability, understanding time ranges, dining-hall aliases, flexible locations, party size, and mixed Chinese-English expressions.
Someone looking for a meal can enter:
“Wednesday around 5 PM at John Jay for two.”
GPT-5.6 interprets the request and ranks compatible availability. Deterministic application logic then verifies the date, dining hall, capacity, and whether the requested time falls inside the provider’s complete availability window.
The guest can reserve a time, which locks the availability, and both participants receive a shared contact space to coordinate their meeting.
TapIn also provides date, time, dining-hall, capacity, and crowd-level filters; live dining-hall crowd indicators; email verification; booking management; and a group-chat importer that turns existing community messages into structured supply and demand.
TapIn does not process payments, sell meal plans, or transfer IDs. It is a coordination layer for in-person meetups and permitted guest access.
How we built it
TapIn was built in a continuous Codex session using TypeScript, React, vinext, Cloudflare D1, and the OpenAI Responses API.
GPT-5.6 powers two primary workflows:
- Availability extraction: converting informal, multilingual messages into structured dates, time windows, dining halls, and capacity.
- Intent-aware matching: understanding a guest’s natural-language request before deterministic rules verify compatible live availability.
We developed the extraction behavior against an evaluation dataset created from anonymized real community messages. The labeled evaluation set became the source of truth for ambiguous intent, shorthand, dining-hall aliases, and context-dependent language. The latest evaluation reached 89.2% exact-match accuracy.
Codex accelerated product framing, data modeling, API implementation, evaluation design, responsive interface development, debugging, deployment, and iteration based on real mobile and desktop testing.
Challenges we ran into
The first challenge was understanding that availability is a continuous time window. An early version could fail to match a 5 PM request against a 3–8 PM offer. We fixed this by separating AI interpretation from deterministic interval verification.
Real community messages were another challenge. They are short, multilingual, and highly contextual. Expressions such as “jj,” “jjs,” “现在,” and “可以” cannot always be interpreted correctly without explicit rules and examples. We created an annotation guide and evaluation set rather than relying only on prompt intuition.
We also needed the AI experience to be reliable during a live demonstration. GPT-5.6 returns strict structured output, while safe fallbacks and deterministic validation prevent malformed inference from breaking the booking flow.
Finally, building a responsive product under hackathon time constraints required repeated real-device testing. The booking filters, campus selector, calendar, availability cards, and contact flow all needed to work across desktop and mobile layouts.
Accomplishments that we're proud of
We are proud that TapIn is a complete, deployed product rather than only an AI demonstration.
A user can publish availability in natural language, search using a flexible request, receive ranked matches, reserve a valid time, lock the slot, and contact the other participant—all through one coherent flow.
We are also proud that the product is grounded in demonstrated demand: more than 680 people already participate in two Columbia meal-swipe coordination groups.
Most importantly, we built an evaluation-driven AI feature from real community language and achieved 89.2% exact-match accuracy, giving us a measurable baseline for improving the system.
What we learned
We learned that AI is most useful here not as a chatbot, but as a translation layer between natural human communication and the structured data required by a booking system.
We also learned that AI interpretation and deterministic product rules should complement each other. GPT-5.6 handles flexible, ambiguous language; application logic verifies hard constraints such as time windows, dates, party size, dining halls, and remaining capacity.
Finally, real evaluation data shaped the product itself. It exposed edge cases that synthetic examples missed, including shorthand, omitted capacity, flexible time ranges, mixed languages, and the difference between a dining location and a meetup location.
What's next for TapIn
The next step is to test TapIn with the existing Columbia communities and measure successful reservations, time-to-match, cancellations, and no-shows.
We plan to add opt-in email notifications, improve trust and identity features, and continue expanding the multilingual evaluation set.
Longer term, TapIn can support other campuses with similar meal-access systems. Each campus would receive its own dining-hall vocabulary, access rules, community board, and evaluation set—allowing the same coordination engine to adapt to local campus needs.
Built With
- api
- cloudflare
- cloudflare-d1
- codex
- drizzle-orm
- git
- github
- gpt-5.6
- openai
- openai-responses-api
- react
- resend
- tailwind-css
- typescript
- vinext
- vite
- waitz
Log in or sign up for Devpost to join the conversation.