How we built a viral hiring platform on GitHub

Most hiring workflows cost you money every step of the way. You pay to post a job, pay an ATS to manage applicants, and pay a recruiter to shortlist them. At the end of it, you have a list of strangers whose only qualification is that they found your listing.

We replaced all of it with a public GitHub repository and a single issue template — and the system now promotes Holdex to thousands of people without us doing anything.

The repo is open source: github.com/holdex/t....

Applications are issues

Every job application at Holdex is a public GitHub issue.

A candidate visits the repository, clicks Apply next to the role they want, and fills in a structured form — position, name, Telegram, portfolio, LinkedIn, short pitch. When they submit, a GitHub issue is created with a URL that belongs to them.

That URL is the candidate's application. It is searchable. It is linkable. It is public.

Most hiring systems give candidates a confirmation email and a black hole. We give them a URL they can share.

The mechanic that makes it spread

Once a candidate has their application URL, we ask them to share it with their network and collect 👍 reactions.

The leaderboard in the README ranks every applicant by reaction count, updated three times a day. Top candidates per role are reviewed first.

This is where the distribution happens. A candidate who wants to rise on the leaderboard has one lever: share their application with people who know them and ask for support. Every time they do, Holdex's name reaches someone who has never heard of us — through a trusted source, attached to a concrete context.

We are not paying for that reach. The candidate is generating it voluntarily, in their own interest.

What the mechanic selects for

The reaction count does not measure technical skill. That is intentional.

Collecting 👍 reactions requires a candidate to send a message to their contacts, write a post, or start a conversation. These are not passive acts. Someone who cannot do any of them — who applies and waits — will stay at the bottom of the list.

What the mechanic selects for is initiative and network strength. In a team that works asynchronously across time zones, both matter. A person who can activate their network to support a public application is demonstrating, directly, that they know how to communicate and move people to act.

The hiring signal is embedded in the mechanism itself. We do not have to assess it separately.

Zero infrastructure

There is no ATS. There is no paid job board. There is no recruiter commission.

The issue template is a YAML file in .github/ISSUE_TEMPLATE/. The leaderboard is a JavaScript function that calls the GitHub API and rewrites a section of the README. The cron job runs three times a day on GitHub Actions. The entire system runs on tools we were already using.

For a DeFi team or a Web3 protocol, this is not a minor detail. Engineering resources are scarce. The hiring system should not compete for them. A YAML file and a 200-line script does not compete for anything.

The compounding effect

A traditional job posting reaches whoever sees it on the day it goes live. Reach decays immediately and goes to zero when the listing closes.

This system works differently. Every application that goes up is a permanent public record. Every candidate who shares it creates new exposure. The longer the repo runs, the more content it accumulates and the more distribution the previous applications have already generated.

The leaderboard is also a signal to potential applicants. When a protocol founder is evaluating whether to hire through Holdex, or when a developer is deciding whether to apply, they can see how many people are competing, what the application format looks like, and how the process works — all in public, before they commit to anything.

That transparency reduces friction and filters out candidates who expect a traditional process.

Why this fits the way we operate

We are an embedded product team. The people we hire need to understand how to work in public, build on GitHub, and function in systems where decisions are visible and traceable.

A hiring system built on GitHub is not just a cost decision. It is a filter. Candidates who are uncomfortable with public-by-default will self-select out before they apply. Candidates who thrive in that environment will find the format familiar.

The same principle behind our client engagement workflow — everything on GitHub, everything visible, everything traceable — runs through how we hire. The tooling matches the culture.