Serendip

Framing the Problem

Most people attend conferences with a very specific goal, apart from just being there to hack or learn—find a technical co-founder, raise their first cheque, hire a senior engineer, or get feedback from someone who's done it before. But the way networking actually works at events is completely random. You talk to whoever is standing next to you at the coffee bar. You collect 40 business cards from people you'll never message. The person who could have changed your trajectory was three tables away, and you never crossed paths.

This affects every professional at every tech event — founders, engineers, recruiters, investors, designers. The problem is not that the right people aren't in the room. It's that there's no system to connect them intentionally.

Idea Explanation

Serendip replaces random hallway encounters with one high-signal AI introduction at a time.

Attendees answer four questions during a 30-second onboarding: who they are, why they're at the event, what unique value they can offer someone today, and what they specifically need. The AI reads every attendee's full profile simultaneously, identifies the single best match for each person, and explains in plain English exactly why they should meet — not just "you're both engineers" but "she led auth infrastructure at Vercel for three years and you're building an auth startup; she's open to advising."

There's no swiping, no list to scroll, no awkward cold approach. Just one introduction, a suggested meeting time, and a @tag to look for. Attendees can accept or decline and immediately get their next match. There's also a manual browse mode for people who prefer to choose themselves, and a lightweight, real-time chat so that matched pairs can coordinate exactly where to meet at the venue.

Organizers get a live dashboard showing attendee count, matches made, acceptance rate, and who hasn't been connected yet — so they can intervene if someone is being left out.

Implementation

Frontend — React 19 + TypeScript + Vite, styled with Tailwind CSS v3. All UI components (forms, dropdowns, multi-select, charts, loaders) are built with KendoReact 15. Routing is handled by React Router v7. The client communicates with the backend via a typed API client (src/lib/api.ts) that wraps fetch. In development, Vite proxies /api to the local server. In production on Vercel, the VITE_API_BASE_URL environment variable routes all API calls to the Railway backend.

Backend — Node.js + Express 4. Four route modules: events, profiles (attendees), matches, and chat. A fifth dashboard route aggregates stats across all three tables for the organizer view. CORS is configured via a CLIENT_ORIGIN environment variable, so the same server works in local development and production without code changes.

Database — SQLite via better-sqlite3 in WAL mode with foreign key cascade deletes enabled. Four tables: events, attendees, matches, and messages. All attendees and matches belong to an event — when an event expires and is deleted by the hourly cleanup job, all associated records are automatically removed. All queries use prepared statements.

AI Matching — Backboard AI (GPT-4o proxy). The matching pipeline has two stages. Stage 1 sends the current user's full profile along with every candidate's profile in a single prompt, asking the AI to return a structured JSON object containing the best matchId and human-readable reasoning. The response is extracted using a regex fallback if the model wraps it in markdown. If the AI fails or times out (15-second limit), Stage 2 falls back to a deterministic compatibility score: intent pair bonuses (Hiring ↔ Job hunting, Founder ↔ VC), role affinity scores, and bidirectional keyword overlap between give and need texts. The fallback always picks someone — a real conversation beats "no match found" at a small event.

Session — No authentication. Each attendee chooses their own @tag during onboarding (with a live availability check against the event). The session is stored in localStorage. If they clear storage or switch devices, they can recover by entering their @tag and event join code on the landing page — the server looks them up and restores the session instantly.

Challenges

Backboard API field naming — The AI calls were silently returning 400 errors because the request body used message instead of content, and the response was nested differently from what we expected. We only discovered this through raw response logging. Once fixed, we added a multi-path response parser so that the integration is resilient to field-name variations.

React 19 strict types and lint rules — React 19's type definitions require useRef to receive an explicit initial value when the type doesn't include undefined. The new react-hooks/set-state-in-effect ESLint rule also flags any setState called synchronously inside a useEffect body. We refactored the tag availability check to derive synchronous statuses (idle, short, checking) during render rather than in the effect, and only call setState inside the async callback — which is both correct and satisfies the rule.

React StrictMode double-invoke — In development, React intentionally mounts components twice, which caused two simultaneous requests to GET /api/matches/next. The second request returned null, with the first candidate already in the seen list. We fixed this server-side by checking for an existing pending match first and returning it immediately — making the endpoint idempotent.

Matching with very few attendees — When someone is the first to join an event, or has been matched with everyone, a generic "no match" response is confusing. We built three distinct states: no_candidates (you're first, share the code), exhausted (you've met everyone, check back when new people join), and no_match (candidates exist, but the pipeline failed — browse manually). Each has a different message and call to action.

Accomplishments

I shipped a production-ready, full-stack AI-powered networking app from scratch in under 24 hours. The thing I am most proud of is the matching pipeline — the two-stage architecture (AI first, code-based fallback) means the app is genuinely useful whether or not the AI call succeeds, and the reasoning the AI writes is specific enough to actually be useful, not generic filler.

I also built something that has no authentication but still has persistent sessions across devices — the @tag recovery system means attendees can close the tab, switch phones, and pick up exactly where they left off without a password or email address. That turned out to be one of the more elegant design decisions of the project.

Technically, I learned how to structure an event-scoped data model with automatic cascade cleanup, handle the practical edge cases of AI-first features (timeouts, hallucinated IDs, malformed JSON), and satisfy React 19's stricter effect and ref rules without fighting the framework.

Next Steps

WebSocket-based real-time updates — The current implementation uses polling (3 seconds for chat, 10 seconds for match checking). Replacing this with WebSockets or Server-Sent Events would make the experience feel genuinely live and reduce unnecessary server load at large events.

Push notifications — When your match is ready, you shouldn't have to be on the page to find out. A web push notification or an SMS (via Twilio) would let attendees stay in the moment during the event and be tapped when it's their turn.

Post-event follow-up — Right now, everything disappears when the event ends. A post-event summary email listing who you matched with, their contact info, and the AI reasoning would give the connections longevity beyond the venue.

Match feedback loop — Did the meeting actually happen? Was it valuable? Adding a simple two-tap "We met ✓" confirmation and a quality rating gives the system signal to improve matching over time and gives organizers a real measure of event ROI.

Organizer white-labeling — The dashboard and join flow can be themed per event with custom colors, logo, and venue map (this will make it easier for two people matched to locate themselves inside the event center). This turns Serendip into a tool that event companies can embed in their own branded experience rather than sending attendees to a third-party app.