CheckdIn - vibe at your airport time

Live app: https://checkdin.vercel.app/ Code: https://github.com/himanshumantri/devpost-hackathon-build-with-basics License: MIT

Inspiration

Business travelers often have an hour or two to spare after security. Some post on WhatsApp status or in chat groups hoping to find someone else at the same airport to talk to. Founders, consultants, investors and executives would gladly use that time to try out an idea or compare notes, but they have no streamlined platform to find each other. CheckdIn tries to fix that by matching people on airport, boarding time and interests.

What it does

You pick your airport, boarding time and optional gate, add a photo and a few details, and choose your interests and the kind of place you'd like to meet (café, bar, lounge, restaurant). CheckdIn then shows up to five nearby travelers. Each card shows their photo, age (if they shared it), boarding gate, interests, favourite place and hometown, and you can open a chat to agree on where to meet.

The matching rule is simple and testable. Two travelers match when

$$\text{airport}_A = \text{airport}_B \;\wedge\; |t_A - t_B| \le 60\ \text{min} \;\wedge\; (\text{interests match} \;\vee\; \text{venues match})$$

Matches are ordered by the smallest boarding-time gap, then by interest match, then by venue match.

How I built it

I worked plan-first with the Devpost Learn Skill Pack. The agent interviewed me, and I made the decisions that went into scope.md, prd.md, spec.md and a slice-by-slice checklist.md (all in the repo's devpost/ folder). I built and verified one small slice at a time and committed after each.

Frontend: React 18 and Vite, hosted on Vercel. Backend: Python, FastAPI and Pydantic, hosted on Render. It holds the airport list, sample people and matching rules, and answers two calls: GET /api/airports and POST /api/matches. Tests: 30 pytest tests cover each matching rule, the ordering and the API. Privacy: the backend works out ages and sends only the age, never a date of birth. Photos you take stay in your browser, and chats are kept in the browser session for up to three hours.

Challenges

Demo scope - Real people finding each other live would need a shared backend, accounts and safety features. I cut all of that and used fictional sample people. Going from localhost to the web - The frontend relied on a development proxy that doesn't exist in production. I had to make the API address configurable, add CORS on the backend, and cope with Render's free tier, which sleeps when idle. Design - My first airport theme was a cartoon illustration, and it looked childish for a professional audience. I replaced it with a real, licensed terminal photo with softened contrast, and I made sure every photo has a free licence. Honesty about the demo - The people and their portraits are illustrations only. In the demo video, Sofia's chat replies are scripted.

What I learned

Writing the rules down first made the building faster and the changes safer. Because "within one hour" was in the PRD, I could point to the exact line of code and the test that enforce it. I also learned how a frontend and a backend talk to each other, and what has to change when an app moves from my laptop to the internet.

What's next

Real users finding each other, with live chat across phones A request-and-accept step before a chat opens Safety features such as blocking and reporting Real flight data and real airport venues

Built With

• agent
• agentic-coding
• claude
• javascript
• prd
• python
• python-package-index
• react
• skills
• spec