Building India's builder network
PeerX helps students find opportunities and teammates, and helps early-stage founders hire people who can actually build. I designed and shipped it as the founder and only designer.
The Problem
I was messaging the same six people for every hackathon, not because they were the best fit, but because they were the only builders I knew existed.
Students couldn't find matching opportunities, and early-stage founders needed to hire fast on a budget. Resumes don't prove you can ship, so everyone defaulted to referrals, hiring the exact same people over and over again.
What the business needed
A verified hiring marketplace where startups source pre-vetted early-career talent through provable shipped work, monetised as a subscription, not as a per-hire fee we'd never be able to enforce.
Research
30 structured interviews: 18 student builders, 12 early-stage founders, conducted over five weeks on video calls. I followed up with a card sort (n = 14) to understand how each group separated "skills" from "shipped work," because I suspected the two words meant opposite things to students and founders. They did.
The insight that changed the design
Founders didn't distrust junior candidates. They distrusted the format.Every founder I spoke to had hired a junior who couldn't do the job, and every one of them blamed the resume, not the person. One put it as: "I'd rather see one thing they finished than five things they listed." That reframed the whole product. We weren't building a better job board; we were building a way to prove delivery.
Supporting Insights
- Students couldn't find skill-matched opportunities. Listings on existing platforms ranked by popularity, which meant the same events won every time.
- Asking for a GitHub link upfront killed mobile signups. Trust had to be earned before effort was demanded, which became the onboarding fix below.
Directions I Killed
A scrolling feed of projects, Behance-style. Killed it after five user tests: students posted, nobody browsed. A feed rewards the person who posts most, not the person who ships best, and it gave founders no way to compare two candidates.
A public ranking of top builders. Tested well with the top 10% and terribly with everyone else: students below rank ~200 stopped opening the app. A single global ranking meant most users were being shown they were losing. The Ship Score kept the signal but made it a personal number, not a position.
For two weeks I reviewed profiles by hand to guarantee quality. It worked and it was completely unscalable: roughly 20 minutes per profile against a target of thousands. That failure is what forced the automated-sync decision below.
Feature Deep Dive
Deep Dive: The Onboarding Flow
Funnel analysis showed 65% of signups abandoning before profile completion. No completed profiles meant no inventory, which meant nothing to sell to founders. This was the only thing worth fixing that month.
Step two asked for GitHub OAuth and project links, before the user had seen a single opportunity or another builder. On mobile, that meant leaving the app to authenticate, and most people simply didn't come back.
I deferred the highest-friction ask instead of redesigning it. New flow: create a basic profile in three fields, browse the marketplace immediately, and hit verification only at the moment it becomes relevant, when you try to apply. Verification stopped being a gate and became a step inside an action the user already wanted to take.
Caption: Before: verification at step 2 of 5, ahead of any value. After: verification triggered by intent, at the apply action.
Drop-off 65% → 38%.
Source: PostHog funnel
Unverified profiles now sit in the marketplace, which slightly dilutes what founders see when browsing. I accepted that trade: an empty marketplace is worth less than a slightly noisy one.
Deep Dive: The Ship Score
Resumes don't work for people with no track record. Founders needed one signal they could filter on and trust.
How do you quantify "can build" across engineering, design and product roles, without rewarding volume? A designer with 3 shipped products should outrank an engineer with 40 abandoned repos.
Every verified project contributes to a single number, weighted by completion and peer verification rather than count. I renamed it from "Build Score" to "Ship Score" mid-design, because "build" tested as theoretical with founders: it describes activity. "Ship" describes delivery, which is the only thing they were actually asking about.
Caption: The score had to be legible to two audiences at once: a student who needs to know how to raise it, and a founder who needs to know whether to trust it.
The score is what made the B2B side sellable. Founders weren't paying for job posts; they were paying for the ability to filter by proven delivery. Without a signal they trusted, there was no product to charge for.
A single number hides nuance. A student who's shipped one genuinely hard thing can rank below someone who's shipped four easy ones. I'd fix that next with weighting by project complexity, which I didn't have data to model yet.
The trade-off that mattered
How to structure the Ship Score
+ High quality, genuinely bespoke matching
− ~20 min per profile. Unscalable past a few hundred users.
+ Pulls from GitHub, Behance and Figma. Score computed instantly. Scales.
− People can game it by syncing empty repos.
We needed thousands of profiles for the B2B tier to have any value, and A capped us in the low hundreds. I mitigated the gaming risk by making peer-verification the heaviest weight in the score: an unverified project counts, but barely. Volume alone can't move you.
I'd have shipped B with the peer-verification weighting from day one instead of adding it after seeing the first gamed profiles. I lost about three weeks of score credibility to that.
Working with the team
I designed alone, but I didn't ship alone, and the engineering constraints shaped the product more than my Figma files did.
The redesign I lost.
My original Ship Score visual was a radial progress ring segmented by role. My engineer told me it would take four days and be nearly impossible to make accessible or responsive at small widths. He was right on both counts. We shipped a stacked horizontal bar in half a day. It's less distinctive and it's the correct decision: the score is read at a glance in a list, not admired on a profile page.
How I handed off.
Every screen shipped with named states (default, empty, loading, error, unverified) because the first version of the profile page shipped with only the happy path and my engineer had to invent the empty state himself. He invented it wrong, and that was my fault, not his.
What I'd need from a design team.
Everything above I learned by getting it wrong first. I've never had someone senior catch it before it shipped, and that's the specific thing I'm looking for in my next role.
Where it landed
Source: Supabase + PostHog, Apr 2025 – Jul 2026
The Number I'm Not Proud Of
9,240 builders registered. About 1,100 come back in a given month, a 12% monthly activation rate.
I built for acquisition and assumed retention would follow. It didn't. When I segmented the users who did return, almost all of them had one thing in common: a real conversation with a match inside their first session. Browsing didn't predict retention. Talking did.
So the fix isn't a retention feature, it's an onboarding goal: get one match and one sent message in session one, and treat that as the completion event rather than profile completion. That's the first thing I'd ship if I went back, and it's the mistake I'd most want to avoid repeating somewhere with more users at stake.
Reflection
- What worked. Deferring friction instead of redesigning it. The cheapest fix was a sequencing change, not a UI change.
- What I got wrong. I spent a week building a comprehensive design system while match quality was still bad. I optimised for consistency before the product was worth being consistent about.
- What surprised me. Defending the design on national television forced a rule I still use: if I can't say why a feature exists in one sentence, it hasn't earned its place.
- Next. Reweighting the Ship Score by project complexity, and rebuilding onboarding around first-conversation rather than profile-completion.