# How to Write a Project Case Study That Gets You Hired > A step-by-step way to write a portfolio case study for a developer or design job: problem, your role, decisions, outcome. With a template and examples. By Dane Dolph. Published 2026-10-19 on the makerhandle blog. Tags: Careers, Portfolios, Guides. 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: 1. **The problem.** What was wrong, for whom, and why it mattered. 2. **Your role.** What you personally did, and who you worked with. 3. **How you got to a solution.** The options, the research, the prototype. 4. **How it solved the problem.** What you shipped. 5. **Challenges.** Constraints, dead ends, ideas you dropped. 6. **The effect.** On users, on the business, on the codebase. 7. **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](https://makerhandle.com/for/job-seekers), [makerhandle for designers](https://makerhandle.com/for/designers), and the definition of a [portfolio case study](https://makerhandle.com/glossary/case-study). Choosing which projects to write up? Read [what to put in your developer portfolio in 2026](https://makerhandle.com/blog/what-to-put-in-developer-portfolio). ## Sources - [Nielsen Norman Group: 5 Steps to Creating a UX-Design Portfolio](https://www.nngroup.com/articles/ux-design-portfolios/) - [HR Dive: Eye-tracking study shows recruiters look at resumes for 7 seconds (Ladders, 2018)](https://www.hrdive.com/news/eye-tracking-study-shows-recruiters-look-at-resumes-for-7-seconds/541582/) --- Source: https://makerhandle.com/blog/how-to-write-a-project-case-study makerhandle: makerhandle is a link in bio for makers and founders: every project with its status and revenue verified from Stripe, Paddle and more.