How to evaluate a developer's proof of work
Evaluate a developer's proof of work by reading for four things: how they scoped the problem, how they communicated, whether the work actually shipped, and the judgment behind their trade-offs. Skip the resume, open the live demo and the case study, and trust proof you can check — a working link, a real artifact, work you can attribute to them — over anything self-reported.
Why a resume can't tell you who can build
A resume answers whether someone is qualified. The only question that moves an early-stage hire is whether they can ship — and a list of job titles answers the wrong one. Proof of work answers the right one: it lets you evaluate backward from what someone actually did, instead of projecting forward from where they worked. Your job as the evaluator is to read that proof well, and to know when it's real.
The four signals to look for
The same four things predict the hire whether you read them in a portfolio or watch them in a paid trial:
- Scoping. Before the code, did they frame the problem — what they'd build, what they'd skip, what they'd verify? A one-paragraph scoping note is the clearest tell that someone can turn ambiguity into work.
- Communication. Do the case studies surface questions, blockers, and trade-offs openly, or just present a clean final result? How they narrate the work previews how the working relationship will feel.
- Shipping. Did it actually work, end to end? Is there a live demo you can click, or only screenshots? Shipped-and-reachable beats polished-and-theoretical every time.
- Judgment. What did they choose to cut, and what did they protect? Good judgment under a constraint is the rarest signal — and the one a resume never surfaces.
None of these require you to read the code. They're readable by any founder, technical or not.
How to read a case study in two minutes
A good case study follows problem-action-result, and you read it for two anchors: what was broken, and what got better. Look for a concrete problem — a real user or business issue, not “we wanted to improve engagement” — followed by the decisions and trade-offs, and closed with a measurable result. Vague impact is a flag. “Conversion improved” tells you nothing; “conversion went from 2.1% to 3.4% over six weeks after the onboarding redesign” tells you they can move a number and account for it.
Separate real proof from self-reported
A portfolio you can't check is a claim, not proof. The strongest evidence is verifiable: the link resolves, the artifact is genuinely theirs, and the work is attributed to them — a commit under their name, their profile linking back, their handle on the repo. Group work with no clear ownership, dead links, and screenshots you can't trace are all reasons to slow down. Before you weigh a claim, confirm the work behind it is real and actually theirs.
What to discount
Discount surface polish with no outcome — a redesign that looks better but moved nothing is a gallery piece, not proof. Discount long tech-stack lists with no shipped product behind them, credentials standing in for evidence, and any result you can't attribute to the person in front of you. Real-world utility outweighs visual polish for startup hiring; a working, attributable project beats an impressive-looking one you can't verify.
How joinstartup shows you verified proof
joinstartup is built so you don't have to take a portfolio on faith. Builders join by archetype — how they operate, not their job title — and their profiles carry proof of work that's been checked: the link resolves, the artifact is real, and the work is attributed to them before it's marked verified. When you want live signal rather than a record, a paid, time-boxed Starter Project or Work Trial lets you watch someone scope, communicate, and ship on your own backlog. The CV is a door; working together is the room.
Evaluate proof of work, step by step
- Open the live demo first. Click the working product before you read anything. If there's no reachable demo or repo, that's your first signal.
- Read the case study for problem → decisions → result. Look for a concrete problem, the trade-offs they made, and a measurable outcome.
- Check the four signals. Scoping, communication, shipping, judgment — all readable without touching the code.
- Verify it's real and theirs. The link resolves, the artifact is genuine, and the work is attributed to them — not borrowed or unattributable.
- If the proof is thin, run a small paid task. A scoped, paid piece of your real work surfaces the same four signals live, before you commit.
Common questions
- How do I evaluate a developer if I'm non-technical?
- Judge outcomes and behavior, not code. Did the deliverable actually work? Did they scope before building, communicate trade-offs, and hit the result they claimed? Those four signals — scoping, communication, shipping, judgment — are readable by any founder and predict the hire better than a code review you'd struggle to run.
- What should I look for in a developer's portfolio?
- A live, reachable demo; case studies with a concrete problem, the decisions made, and a measurable result; and proof you can attribute to the person. Prioritize shipped, verifiable work over visual polish or long tech-stack lists with nothing behind them.
- How do I know a portfolio is the developer's own work?
- Check attribution before you weigh the claim: a commit under their name, their profile linking back, their handle on the repo, a working link to the live artifact. Group projects with no clear ownership and screenshots you can't trace are reasons to slow down. On joinstartup, proof is verified — attributed and checked — before it's shown as such.
- Is a GitHub profile enough to evaluate a developer?
- It's a start, not the whole picture. A green contribution graph doesn't tell you whether they can scope ambiguity, communicate, and ship something real. Look for a specific, deployed project with a case study behind it — and confirm the meaningful commits are actually theirs.
- How is evaluating proof of work different from a technical interview?
- An interview measures how someone performs in an interview — recall under pressure, talking about code. Proof of work measures the job itself: scoping, shipping, and judgment on real problems. Reading proof of work (or running a paid trial) evaluates the thing you're hiring for; the interview is a proxy for it.
- What if a candidate has no portfolio?
- Give them a small, paid, scoped piece of your real work and read the same four signals live. A one-week paid trial surfaces scoping, communication, shipping, and judgment directly — and it's fair, because it's paid and real rather than an unpaid take-home test.