HackAtlas — Devpost Submission

Tagline: Mapping the world's top hackathon builders. One-liner: Give us a hackathon brief, we'll find your winning team.


Inspiration

We've all been there — you find a hackathon you love, but the night before kickoff, you're scrolling Discord looking for teammates. "Looking for frontend, I have ML." Ten generic DMs later, you've got nothing. Meanwhile, somewhere out there, there's a serial hackathoner with 42 wins across 60 events who would have been the perfect teammate — but LinkedIn doesn't surface them, Devpost doesn't connect them to your specific brief, and you have no way to reach them.

We built HackAtlas because we believe the #1 predictor of who wins a hackathon isn't the idea — it's the team. And finding the right team shouldn't require luck.

What it does

HackAtlas is a Winning Team Copilot for hackathons. Give it a hackathon brief (URL or description), answer a few quick questions about yourself, and it returns:

  • An optimal 2–4 person team drawn from our graph of documented serial hackathoners, scored across 7 dimensions: Track Fit, Shipping Velocity, Hackathon Proof, Complementarity, Reliability, Demo & Communication, and Logistics.
  • Interactive team composition — click a candidate and the Role Coverage dashboard updates live, showing which roles are covered and which gaps remain.
  • Three project topic recommendations aligned with both sponsor bounties and your team's actual capabilities, with ROI and feasibility estimates.
  • Personalized outreach messages — ready-to-send DMs that reference each candidate's real past projects, so you never have to cold-message twenty strangers again.

Every recommendation is explained. Every score has evidence behind it. Every candidate card links out to a verifiable LinkedIn, Devpost, or GitHub profile. No black boxes.

How we built it

  • MeDo powered the vibe-coded frontend and the full product orchestration. We leaned into its three strengths: multi-turn chat for onboarding, plugins for external data calls, and full-stack generation for the interactive report page with radar charts, live composition analysis, and outreach drafting.
  • Bright Data Web Unlocker served as our universal data entry point. A single API let us hit public Devpost, GitHub, and LinkedIn pages reliably, with Unlocker handling the anti-bot logistics so we could focus on scoring logic.
  • LLM extraction layer turned messy HTML into structured candidate records — name, role, skills, wins, recent activity, timezone, and a short "why this candidate" summary.
  • Our own 7-dimension scoring engine combines rule-based signals (commit recency, weekend shipping density, win counts) with LLM-judged soft signals (storytelling, demo polish) to produce explainable scores instead of a black box.
  • Team composition optimizer selects the top 4 by a weighted function: 60% individual scores + 40% complementarity bonus across role coverage, stack diversity, and timezone overlap.

All Bright Data calls run server-side with the API key stored as an environment variable — zero key exposure in the client bundle.

Challenges we ran into

  • The Two Taylor Swifts bug. Our first Bright Data + LLM extraction pass occasionally produced duplicate candidates (same person surfaced via different posts, with slightly different name capitalization). We solved it with a three-layer dedupe: id-keyed React rendering, server-side Set dedup, and a runtime duplicate detector with dev-mode warnings.
  • LinkedIn's photo CDN is aggressively gated. Profile images often require authenticated sessions and can't be hot-linked. We built a three-tier photo pipeline — primary Bright Data scrape → UI Avatars initials fallback → static silhouette — so no cartoon avatars and no broken images ever reach the demo.
  • "Winner" isn't a structured field. LinkedIn doesn't label "hackathon wins." We had to infer wins from activity posts, Devpost badges, and self-descriptions — which meant writing LLM prompts that could reliably distinguish "participated" from "finalist" from "1st place."
  • Scoping under time pressure. Our first design had 12 features. We hard-froze the P0 list at the 24-hour mark (profiles, scoring, live composition, outreach) and only polished from there. Three P1 features got cut; none were missed in the demo.
  • Demo-day reliability. Bright Data can time out; venue WiFi is venue WiFi. Every API call was designed with silent fallback to seed data, so even if the network drops, the demo never breaks.

Accomplishments that we're proud of

  • Real people, not synthetic data. We mapped 12 real serial hackathoners with verifiable public profiles — Mohammed Khambhati (42/60 wins), Aryan Kyatham (7-hackathon winning streak), Raymond Loong Ng (23/38 wins), and more. Every card links to a live profile.
  • Fully explainable scoring. Every weighted score breaks down into 7 inspectable dimensions, each backed by concrete signals. Nothing is "trust us, it's AI."
  • Live team composition as the hero interaction. Selecting a candidate instantly rewrites the Role Coverage dashboard, recalculates the team score, and updates the complementarity bonus. It took serious state-design work but it's the single most "demo-worthy" moment of the product.
  • Zero cartoon avatars. We deliberately rejected Dicebear-style defaults and invested in a real-photo pipeline with professional fallbacks. Small detail, big polish.
  • Compliance as a feature, not a footnote. We treat LinkedIn strictly as enrichment, never as the primary signal. Surfacing this openly made the architecture cleaner and positioned us well against judges' usual "is this even legal?" reflex.

What we learned

  • Data pipelines eat the schedule. The interesting parts of the product (scoring, composition) are maybe 20% of the work; the boring parts (parsing HTML, deduping, caching, fallback logic) are 80%. Budget accordingly.
  • Hackathon wins correlate more with "ships" than "smart." And "ships" is surprisingly easy to detect — weekend commit density, README completeness, project maintenance — once you stop over-indexing on titles and credentials.
  • LLMs are great at extraction, terrible at dedup. Every time we asked an LLM to merge a list of scraped records, it occasionally invented new duplicates. Code-based dedup with stable ids is non-negotiable.
  • "Copilot" beats "Finder." We started as "find teammates" and pivoted to "build a winning team." Same underlying data, but the second framing made the product 10× more compelling — to ourselves, to users, and (we hope) to judges.
  • MeDo's full-stack generation is underrated. The report page — radar charts, interactive cards, live composition, outreach drafts — would have taken a full day to hand-build. MeDo gave us a working draft in minutes that we then polished, which is exactly what a 48-hour window needs.

What's next for HackAtlas — Mapping the world's top hackathon builders

  • Scale the graph. 12 candidates is just the seed. Next we'll grow to 1,000+ builders across AI, Web3, Fintech, and consumer tracks, using continuous Bright Data ingestion from Devpost, TAIKAI, ETHGlobal, and MLH.
  • Reverse matching. Today you input a hackathon, we suggest a team. Soon: input your profile, we rank upcoming hackathons by your personal win probability.
  • Consent-based onboarding. Let builders reverse-onboard themselves, control their visibility, and opt into incoming team invites — turning HackAtlas from a one-way radar into a two-sided marketplace.
  • Organizer & sponsor mode. A dashboard for organizers to spot rising talent and for sponsors to track which builders are adopting their SDKs. Same underlying data, new audience.
  • JudgeMirror. A sibling product that scores your own in-progress project against a hackathon's rubric before submission. Same explainable-scoring engine, applied to your output instead of your team.

The bigger vision: HackAtlas isn't just about winning one weekend. It's about making the global builder network legible — mapping who ships, what they ship, and who they should ship with.

Built With

Share this project:

Updates