How to Write a Project Case Study That Gets You Hired

A screenshot shows what you made. A case study shows how you think, and how you think is what an interviewer is trying to find out. This guide walks through writing one for a single project, whether you are a developer, a designer or somewhere in between.

makerhandle is our product and has a page format for exactly this, which we mention at the end. The method works anywhere: a README, a Notion page or your own site.

Who reads it, and how

Two kinds of people read your case study, and neither reads all of it.

Recruiters skim. The often quoted 2018 eye-tracking study by Ladders measured an average first look at a resume of about 7.4 seconds, and found that simple layouts with clear headings held attention best. Treat a case study the same way: someone should get the point from the headings and the first line under each.

Hiring managers and interviewers go deeper, but selectively. Nielsen Norman Group surveyed 204 UX professionals who hire, and wrote that very rarely will a hiring manager read a portfolio word for word. They look for the parts that answer their questions: what was the problem, what did you do, and did it work?

So write for skimming first and depth second.

The structure

NN/g's portfolio guide suggests a case study cover seven things. They translate well to engineering work:

The problem. What was wrong, for whom, and why it mattered.
Your role. What you personally did, and who you worked with.
How you got to a solution. The options, the research, the prototype.
How it solved the problem. What you shipped.
Challenges. Constraints, dead ends, ideas you dropped.
The effect. On users, on the business, on the codebase.
What you learned. And what you would do differently.

You do not need a heading for each. Most good case studies use four or five headings and let the rest live in short paragraphs.

Step 1: open with one sentence of context

Start with what the project is and who it is for, in plain words, before any stack or jargon:

A web app that lets a community food bank schedule volunteer shifts, replacing a shared spreadsheet that double-booked people every week.

A recruiter who reads only this sentence still knows what you built. Add a single line of your role and timeline under it: Solo developer, Feb to May 2026.

Step 2: be specific about your role

This is the part most often missing, and the first thing an interviewer asks about. "We built" is fine for the team's result; switch to "I" for your part.

Team of four. I designed the database schema, wrote the shift-conflict checker and set up deploys. Two teammates built the frontend; one ran user interviews.

Specific beats impressive. "I wrote the API" is believable and gives the interviewer something to ask about. "I led the full-stack architecture" on a three-week class project invites skepticism.

Step 3: show decisions, not a feature list

A list of features tells a reviewer what the project does. Decisions tell them what you are like to work with. Pick two or three moments where you had a real choice:

What were the options? "Postgres row locks or a queue."
What did you pick, and why? "Row locks: a few hundred writes a day did not justify another service."
What did it cost? "Harder to scale later; documented the limit in the README."

For designers, the same moments are the iterations: the first wireframe, what testing showed, what changed. NN/g is explicit that hiring managers want to see the messy process, not just the polished result, so include a sketch or an early screen with a caption saying what was wrong with it.

Step 4: say what happened

Every case study needs an ending. Numbers are best when you have them, and they need a baseline to mean anything. Laszlo Bock, then head of People Operations at Google, popularized a resume formula in a 2014 LinkedIn post: accomplished X, as measured by Y, by doing Z. It works for case studies too:

Cut double-bookings from about 6 a week to none in the first month, by checking conflicts in the database instead of the browser.

No numbers? Say what changed in words: it shipped, a named group used it, a maintainer merged it, you learned enough to do the next one differently. "Still in use by the food bank a year later" is a strong outcome.

Step 5: add the evidence

Under or alongside the text:

A live link if it still runs. Reviewers like to click.
Screenshots with captions. A caption says what to notice: "Conflict warning appears before the shift is saved."
A short video if the project is offline or needs hardware. Two minutes is plenty.
The source code, with a README that explains how to run it.

Step 6: cut it down

Read it as a stranger with a minute to spare. Delete anything that does not answer what, who, why or what happened. Setup instructions belong in the README. A tour of every screen belongs in the gallery. Most case studies get better at half the length.

A template you can copy

One line: what it is and who it is for.
Role and timeline: your part, team size, dates.
The problem: two or three sentences.
What I did: two or three decisions, each with the options, the choice and the trade-off.
What happened: the outcome, with a number and a baseline if you have one.
What I would change: one honest paragraph.
Links: live demo, source, video.

Putting it on makerhandle

Every project on a makerhandle page has its own page at makerhandle.com/yourname/project, built for this format. Your role and timeline sit at the top, the stack shows with logos for well-known tools, highlights hold your outcomes as one-liners, the Markdown write-up carries the story, and a gallery of up to 12 captioned images opens full size. Links to the source code, a live demo, the App Store or Google Play sit in one row. Turn on Open to work and every project page ends with a button to contact you.

It is free for five projects. See makerhandle for job seekers, makerhandle for designers, and the definition of a portfolio case study. Choosing which projects to write up? Read what to put in your developer portfolio in 2026.