When a team publishes a hackathon submission that names your product as the API they built their demo on, files a Devpost project page that lists your SDK in the "built with" section, or writes a demo-day recap that credits your platform for shipping a working prototype in 48 hours, they have left a category of endorsement that almost no marketing-elicited testimonial can replicate. The submission was written under genuine time pressure, judged in public by people with no incentive to flatter you, archived permanently on a developer-community platform, and frequently re-shared on the builders' own social accounts for months afterward. The project page carries the team's build-time testimony, the public archive carries the judged ratification, and the surrounding context establishes that your product was chosen when speed and reliability mattered most.
Almost no developer-tools, API, SDK, or B2B platform vendor systematically extracts product mentions from public hackathon and developer-event archives. The omission is the natural extension of the same blind spots we documented in our conference talk extraction guide, our changelog and release-notes extraction guide, and our blog post and Medium article extraction guide. Conference talks cover stage-attested mentions. Changelogs cover engineering-release mentions. Blog posts cover author-attested narrative mentions. Hackathon content covers builder-attested, time-pressured, publicly judged, archive-permanent product mentions made at the exact moment a developer chose your product to ship something fast — a corner of the durable public corpus no other extraction surface reaches, and the only one where the customer's testimony is tied to a working demo that judges and the wider community could inspect.
This guide describes the extraction workflow for the hackathon and developer-event corpus.
Why a hackathon mention beats almost every marketing-elicited testimonial
A hackathon project mention has passed through filters no marketing-elicited testimonial encounters. Several properties stack to make it one of the most credible builder-endorsement formats in developer marketing.
First, the mention was made under real time pressure. Hackathon teams have hours, not weeks. When a team picks your API over an alternative, they are voting with the most scarce resource they have. A "built with" credit earned under a 48-hour clock is a far stronger signal of developer experience than any testimonial collected through a leisurely case-study interview.
Second, the project was judged in public. Submissions are scored by judges, ranked on a leaderboard, and frequently demoed live. A product mention attached to a judged, ranked project inherits a layer of third-party scrutiny that an unverified quote never carries.
Third, the artifact is archived permanently on a community platform. Devpost project pages, GitHub repos, and event recap posts persist indefinitely and are indexed by search engines. The mention is retrievable years later by any developer evaluating your product.
Fourth, the "built with" section is structured, machine-readable data. Devpost and similar platforms expose an explicit technology-stack list. Your product name sitting in that list is a clean, unambiguous, parseable endorsement — not buried prose you have to interpret.
Fifth, the builders amplify it themselves. Teams share their submissions on X, LinkedIn, and personal blogs, often tagging the tools they used. The original mention becomes a seed for organic re-shares you did not have to ask for.
The five hackathon locations where customer mentions appear
The hackathon-and-developer-event ecosystem has five primary content locations where a product mention can surface, each carrying a different credibility weight and downstream usability.
Location 1 — The Devpost "built with" technology tags
The structured "built with" list on a project page is the highest-value location because it is explicit, machine-readable, and unambiguous. If your product name is a tag, you have a verifiable, archived statement that a team chose your product to build a working demo.
Location 2 — The project narrative and "how we built it" section
The free-text narrative is where teams describe why they reached for your product and what it let them ship. These passages are the richest source of quotable, specific endorsements — "we used X because it let us skip authentication entirely and ship in an afternoon."
Location 3 — The demo-day recap and winners writeup
Event organizers and sponsors publish recaps that name winning projects and their stacks. A winning project that credits your product gives you a mention validated by both the team and the event organizer.
Location 4 — The submitted GitHub repository README
The repo README usually documents the stack and setup steps, often with a "powered by" or dependency section. This is engineering-attested and inspectable down to the commit level.
Location 5 — The builder's own post-event social and blog amplification
Teams write retrospectives and post threads. These carry first-person enthusiasm and frequently include the most candid praise, because the builder is speaking to peers, not to a vendor.
The extraction workflow
-
Identify the events and platforms. Search Devpost, MLH event archives, major sponsor hackathons, and GitHub topic tags for projects that list your product. Pull the project pages, repos, and recap posts into a working set.
-
Confirm the mention is a genuine usage credit, not incidental. A "built with" tag or a "how we built it" sentence that names your product as load-bearing qualifies. A passing reference in a list of "tools we considered" does not.
-
Capture provenance. Record the event name, date, team, project URL, judging result, and a screenshot or archived snapshot. Provenance is what lets you display the testimonial credibly and survive an authenticity challenge — see our note on how to verify testimonial authenticity.
-
Request permission and select the quote. Reach out to the team, confirm they are comfortable being featured, and pull the single most specific sentence. Specific beats generic every time: "shipped OAuth in 20 minutes" outperforms "great tool."
-
Deploy with attribution. Display the quote with the builder's name, the event, and the project link. The event context is itself social proof — it tells a prospect your product survived a real build under pressure.
Why this corpus compounds
Hackathon mentions are unusually durable. The project pages stay up, the events recur annually, and a strong showing in one year's event seeds the next. A vendor that systematically harvests, permissions, and displays hackathon endorsements builds a corpus of proof that is time-stamped, judged, and inspectable — the kind of evidence late-stage technical buyers trust most. Once you have a workflow for turning public build-time credits into embedded testimonials on your website, every event your developers touch becomes a renewable source of credible proof.