Crewmate

matching · recommendation · hackathons

github ↗︎ try it here ↗︎

tami and i started building crewmate because finding hackathon teammates still felt surprisingly manual. most people were posting in discord servers, group chats, or linkedin and hoping they’d find someone before applications closed. we wanted to build something that made finding teammates a little less random.

it’s a react and typescript app on top of postgres and supabase, using row-level security to keep hackathon data scoped correctly.

the first version was pretty simple. students could create a profile, browse other participants, and send teammate invitations. after we started using it and talking to other students, the project kept growing. hackathon-specific profiles, saved teammates, email notifications, and eventually a matching service all came from solving problems we ran into along the way.

v1 profile browsing v2 invitations v3 hackathon workspaces v4 ai-assisted matching v5 recommendation scores

one thing we changed early was how profiles worked. instead of having one profile for everything, every hackathon has its own space. someone looking for teammates at hacktx probably isn’t looking for the same people they’d want to work with at treehacks or calhacks, so profiles, invitations, and teams stay tied to each event.

hackathons profiles teams invitations skills one hackathon row, everything else scoped beneath it

the matching system became the most interesting part of the project. recommendations start with a fast heuristic so results appear immediately, then a separate ai-assisted matching service looks at things like experience, interests, project ideas, and goals to produce a more complete compatibility score. if that service isn’t available, the app falls back to the heuristic so matching never stops working.

profile request skills + interests heuristic match instant, always available available refined compatibility score unavailable heuristic result stands

another problem was user-submitted hackathons. we didn’t want ten copies of the same event because people pasted different urls or slightly different names. before creating a new hackathon, the app checks existing events first, then uses ai to decide whether it’s really a new event or one that’s already in the database.

submitted hackathon url/name check existing events then ai decides match duplicate reuse existing event new create hackathon row

invitations ended up being more complicated than we expected. students can save profiles, send teammate invitations, accept or decline requests, leave hackathons, and keep everything separate for each event. a lot of the work went into making sure all of those different states stayed consistent as the project grew.

invite sent pending accepted joins the team declined can still leave later

we’re still actively building crewmate. every new hackathon gives us another excuse to improve the matching service, rethink the recommendation logic, and make finding teammates a little easier.