Rebuilding UHI Admissions:
From a Fragile Shared Database to a Production Admissions System
Role: Automations Engineer, Atrium Academy
Program: Uniswap Hook Incubator (UHI)
Scope: ~2,500+ developer applications across six cohorts (UHI-5 to UHI-11)
Stack: n8n, Airtable (database + interfaces), Typeform / Tally, Claude (Haiku), GitHub API, Google Calendar, Brevo
Overview
When I joined Atrium, the admissions team was managing developer applications by working directly inside a raw Airtable grid. I rebuilt the whole process into an ATS-style system: a controlled applicant interface, an automated assessment pipeline with a human in the loop, and a concrete + automated scoring rubric that replaced subjective judgment. The result is a pipeline one person can run across thousands of applications without losing candidates or losing data.
note: due to the PII nature within these interfaces, only screenshots containing artificial test data will be shown
The starting point
The team was working out of an Airtable database where each record was an application (not a person), and people edited candidates directly in the grid view. That setup was fragile in every direction:
Data loss was routine. It was easy to overwrite a field by clicking into the wrong record, or wipe one entirely with a stray keystroke. Records got deleted by accident.
Every cohort meant manual rebuilds. Separate acceptance emails drafted per cohort, separate automations, and calendar/Linear reminders to add and remove cohorts on specific days.
Screening ran on vibes. Candidates moved forward on a loose "strong yes / weak no / weak yes" gut call, with no rubric behind it.
No re-applicant history. Nothing linked a returning applicant to their past application.
People fell through the cracks. No SLAs, slow response times, candidates stalling in stages with nobody noticing.
The state of things made sense given the program's history. UHI had been stood up quickly to meet Uniswap's need for a gated, developer-focused program, and the admissions database had started life as a Google Sheets spreadsheet before being migrated into Airtable. That origin explained most of the mess. The team had inherited a structure built for a spreadsheet, not for managing applicants at scale.
What I built
1. An ATS-style applicant interface
Coming from an ATS (Lever and Ashby) at Kraken, I rebuilt the experience on top of Airtable interfaces so the team stopped touching raw records. Real applicant profiles instead of loose rows. Re-applicants automatically linked by email, so prior applications show up as history (something we'd never had). Locked and read-only fields to stop accidental overwrites. And button actions that fire automations straight from a profile (generate a personalized line on demand for anyone who slipped through, add an enrolled developer to all their calendar events, jump to their LinkedIn or GitHub).
2. An automated assessment pipeline (human in the loop)
An application comes in through Typeform / Tally, n8n enriches it with the candidate's GitHub activity, and Claude (Sonnet) reviews the application plus that GitHub data to produce a move-forward / hold recommendation and a drafted personalized line. Everything lands in the interface, where a reviewer sees the recommendations (both the move-forwards and the don'ts), agrees or overrides, and advances the candidate with a single click. The model does the triage at volume; a human owns the actual decision.
3. A concrete scoring rubric
I replaced the subjective calls with a four-pillar rubric, each scored 1 to 5:
Web3 and Solidity experience
DeFi and protocol experience
System design and hook understanding
Innovation potential (creativity and the strength of their hook idea)
A weighted average (out of 5) produces a single score, weighted toward Web3 / Solidity experience, the hardest thing to teach and the thing the program assumes rather than provides. The weights: Web3 + Solidity 3.5, DeFi + protocol 2.5, system design + hook understanding 2, innovation potential 2 (summing to 10). Candidates above the threshold advance. Anyone averaging 4+ gets auto-flagged as a high-potential developer and surfaces in a separate report. That report turned into a real decision-making tool: it guided how our founder-in-residence focused her time on prospective company builders, and the data I produced helped select teams for an accelerator track.
4. Operational systems layered on top
Personas: a four-type classification (company builder, upskiller, job seeker, hackathon hopper) now auto-assigned by the LLM, used to track demographics, spot trends, and shape how we positioned the program.
Attribution and referrals: where each applicant came from, captured and visible on the profile, plus a referral system that links a referred applicant back to the record of whoever referred them.
No-show management: auto-blacklist after two no-shows, with a cooldown before they can reapply or reschedule.
SLAs and stage-aging reminders: so candidates stop stalling unnoticed.
Rejection categories: structured reasons, so we can see why candidates get turned away and not just that they were.
Universal cohort workflows: one acceptance automation and one enrollment form that read the candidate's assigned cohort and start date and wire them into the right calendar events automatically. This replaced the per-cohort copies we used to draft and maintain by hand.
5. Reliability
Capped the GitHub enrichment fetches to fix out-of-memory crashes triggered by high-activity profiles, enabled execution logging on both successful and failed runs, and added guardrails to keep the LLM from cohort mismatches and reasoning leaks before any output reached the pipeline.
6. An AI interview assistant (tying it all together)
The rubric and the persona system didn't stay on paper. I built them into the interview itself.
I set up Granola to transcribe every admissions interview automatically, so the interviewer could just have the conversation instead of splitting attention to take notes. Then I wrote a custom prompt that loaded my scoring rubric directly into it, so the moment an interview ended, the transcript came back already scored: a 1 to 5 in each of the four pillars, each with a one-sentence justification citing what the applicant actually said.
It went further than scoring. The same prompt captured the talent metrics I cared about (web3 and web2 start years, whether they'd founded a company, whether they'd worked at one of the top web3 companies I was tracking), assigned a dev persona from the four I'd defined, documented the applicant's proposed hook idea in a standardized format, and drafted the two personalized lines for their acceptance email. One conversation in, a complete and consistently structured evaluation artifact out.
This is the piece that tied the whole system together. The rubric stopped being something reviewers filled in by hand and became something applied live and consistently; the personas stopped being a manual tag and got suggested straight from the conversation; and the personalized line that used to take a button click was now generated as a byproduct of the interview. Same standards, same structure, every applicant, with the interviewer freed up to actually listen.
Impact
Data loss from accidental edits and deletes was eliminated by moving everyone off the raw grid and onto a controlled interface with locked fields.
Per-cohort manual setup collapsed into universal workflows. Separate emails, forms, and calendar wiring per cohort became one automation that reads the cohort itself.
Manual calendar enrollment (four sessions a week for roughly three months per developer, done by hand whenever the automation needed a fallback) became a single button.
Subjective screening became a documented, repeatable rubric, with high-potential candidates surfaced automatically rather than spotted by luck.
Persona and scoring data fed real business decisions, from how the founder-in-residence spent her time to which teams were selected for an accelerator track.
The pipeline scaled to ~2,500+ applications across six cohorts.
Turnaround dropped from one to two weeks (and up to a month or two for candidates who fell through the cracks) to a sub-day SLA, often just a few hours.
Review capacity went from three to five people down to a single operator, and that one operator also absorbed an entirely separate line of work (the Problem First AI contracts) on top of UHI, because the automation freed up the capacity to scale beyond the program it was built for.
The clearest measure of the system's leverage is what it freed the team to do next. By collapsing what used to take a small admissions team into a pipeline one person can run, it didn't just make UHI cheaper to operate, it gave Atrium the capacity to take on a second program (Problem First AI) without adding headcount.