PriorNerds

Inspiration

While reading about Nerd Apply, I found an interview in which the founders describe one of their counselors sitting with a family and pulling up the record of a student with a 1570 SAT whom every Ivy had turned down. That one record did more to reset the family's expectations than anything she could have told them. Most admissions tools hand families a percentage instead, which nobody in the room can really check, while a past student's record gives a parent something concrete to compare against their own kid.

I wanted to build around that idea, so I decided from the start that PriorNerds would gather the evidence and leave the judgment to the counselor, which means the app never shows a chance of admission and never sorts the student into a type.

What it does

A counselor picks a student from the switcher in the top bar, or adds a new one, and fills in their grades, AP/IB courses, SAT score if they have one, intended major, activities, draft essay, preferred regions and the schools already on their list.

The school list sorts schools into Likely, Target, Reach and Not enough data based on how similar past applicants did at each one. Each card opens with what the students who got in tended to have that the others didn't, for example "More often had outdoors activities," and marks whether this student looks more like the ones who got in or the ones who didn't. The bar along the bottom of each card shows how all the similar applicants did, and clicking the card opens a panel with the full counts, a short written summary and the actual past students on both sides.

The Similar students page lays out the ten past applicants closest to this student, along with every school each of them applied to and the result at each, so a counselor can follow a whole application season for someone with a comparable profile. Each of those students also comes with a short list of what they have in common with this student and where they differ.

How we built it

I built PriorNerds with Next.js, TypeScript and Tailwind, and we kept AI out of the numbers entirely, so every count comes from a plain TypeScript engine that anyone can read.

The engine compares the student with every past applicant on GPA, course load, test scores, activity types, essay themes and intended major, and the ten closest matches fill the Similar students page. For each school, it then takes up to 25 similar students who applied there and works out what share of them got in.

A school lands in Likely when that share reaches 65%, in Target when it reaches 30%, and in Reach below that, while any school with fewer than five similar applicants goes to Not enough data. Finally, the engine splits each school's group into the students who got in and the students who didn't, and picks out the factors where the two groups differ the most, which become the patterns on the cards.

I also use the Nicrron API for two narrow jobs: reading the draft essay to tag what it's about from a fixed list of themes, and writing the short summary in each school's panel. Before the essay goes anywhere near the model, our guardrail checks it for instructions aimed at the AI and strips out emails and phone numbers, and if it finds an injection attempt, it keeps the essay away from the model and falls back to keyword matching. Once the model writes a summary, a validator checks every number in it against the counts it came from. If the model mentions a number that doesn't appear there, we throw the summary out and show a fixed template instead, with a note in the panel telling the counselor which version they're reading. Every step of a run, including guardrail flags and rejected summaries, goes to PRISM by Block Convey as traces grouped under one session.

Since there was no real admissions data, I produced 3,600 fictional applicants and about 34,000 applications across 51 real schools.

Challenges

Selective schools caused the most trouble, because at a school like Bowdoin almost none of the students similar to our test student got in, which left the engine with nobody to compare against. I ended up having the engine borrow the closest students who did get in from the wider pool, and the card shows a warning whenever it does that so the counselor knows the comparison rests on looser matches.

The essay also needed some thought, since plenty of students do robotics and write about hiking, and those two facts point in different directions. We kept the essay's themes separate from the student's activities throughout the engine, and the essay never gets a score.

What we learned

The main point was to design for a counselor who is probably going to show it to a parent, so almost every decision we made toward showing the underlying students instead of summarizing them prioritized that. We also learned how much of the work in a tool like this goes into deciding when it should say nothing at all, since the Not enough data group and the borrowed comparisons took more iteration than any screen in the app.

Built With

• nextjs
• react
• tailwind
• typescript