A portfolio case study is written in seven blocks: a result headline, the context, the problem in numbers, what you built, what changed and how you measured it, inspectable evidence, and what you would do differently. Get written permission before you publish anything about a client, and never publish a number you cannot show the method behind. Those two rules — the number contract and the permission ladder — are what separate a case study a hiring manager believes from one they scroll past.
This article is about the writing. If you do not yet have projects to write about, start with how to build a portfolio without experience; if you are still deciding whether proof beats credentials at all, start with proof of work vs credentials.
Why most case studies fail
Three failure modes, in order of frequency.
No number. "Improved the lead process, streamlined the workflow, increased efficiency." The reader learns that you were present. Nielsen Norman Group makes the same point about design portfolios: final screenshots only tell part of the story, and what reviewers want is the problem, your specific role, the process and how the project affected users and the business.
A number with nothing behind it. "Increased conversion 300%." From what to what? Over what window? Compared with what? Measured how? A reader has two options — believe you or leave — and most leave.
A tour of tools. Four paragraphs about which platforms you connected and none about what stopped being broken. Tools date; problems do not.
The number contract
This is the rule MitHub applies before any number goes into a case study. Every number carries four companions.
| Companion | Question it answers | Example |
|---|---|---|
| Before | What was the baseline? | Median first contact: 19 hours |
| After | What is it now? | Median first contact: 22 minutes |
| Window | Over what period, and how many events? | 6 weeks, 1,240 leads |
| Method | Where did the number come from and who could reproduce it? | CRM timestamp diff, same report both periods |
If you can supply all four, publish the number. If you cannot supply all four, write the sentence without a number — "first contact moved from same-day to same-hour" — and you remain credible. A missing number is a gap. A number that falls apart under one question is a character problem.
Borrow the standard from advertising law, even though a portfolio is not an advert. The US Federal Trade Commission's guide for small business states that before a company runs an ad it must have a reasonable basis for its claims, meaning objective evidence, and that the proof must exist before the ad runs. Apply the same timing to yourself: gather the evidence while the project is live, not when you are writing it up six months later.
The permission ladder
The other half of credibility is the right to publish. Decide which rung you are on before you write, ideally before the project ends.
| Rung | What you may publish | How you get there |
|---|---|---|
| 1. Named and numbered | Client name, real metrics, screenshots | Written approval from someone authorised to give it |
| 2. Named, relative numbers | Client name, percentage changes only, no absolute revenue | Approval with a redaction pass |
| 3. Anonymised and numbered | "A 40-branch lending network", real metrics, no logos or identifying screenshots | Approval to describe without identifying, or a contract that permits it |
| 4. Method only | The problem shape, your approach, the architecture — no client metrics | Always available; add a client testimonial to carry the credibility |
Rung 3 is where most real work lands, and it is perfectly strong. Nielsen Norman Group's guidance for research portfolios describes the same practice: sanitise materials so companies and products are unrecognisable while your methodology still shows, ask past clients whether they will share an excerpt, and request a recommendation from clients whose work must stay confidential. A one-paragraph recommendation from a named client is often worth more than a number you had to blur.
Ask early, and ask specifically. "Would you be comfortable if I wrote this up without naming the company, using percentage changes only?" is a question people say yes to. "Can I publish this?" asked after the fact is a question people say no to, because it is vague and arrives when they have nothing to gain.
MitHub's seven blocks
1. Title = the result, not the project
Bad: Lead routing automation for a lending client. Better: Cut time-to-first-contact from 19 hours to 22 minutes across 10 branches.
The title is the only part most readers finish.
2. Context (2–3 sentences)
Who the business is at the level of shape, not identity: industry, size, how they make money, what part of the process you touched. "A multi-branch consumer lender in the south-eastern US, ten locations, selling loans to walk-in and inbound phone leads."
3. The problem, in numbers
State the leak, not the annoyance. This is where the revenue leak map belongs: step, volume, drop, cost. "Of roughly 300 inbound leads per month, 41% had no logged contact attempt within 24 hours. Branch managers were routing by hand from a shared inbox."
If you have no baseline number, say what you observed and how — "I sampled 100 records and counted" is a method, and it is enough.
4. What you built
Short. One paragraph plus one diagram. Name the decisions, not the click paths: what you chose to automate, what you deliberately left manual, where a human approves. Reviewers are reading for judgement. "I left transfer approval with the branch rep because a wrong transfer costs more than a slow one" tells them more than a list of nodes.
5. What changed — and how you know
Apply the number contract. Then add the sentence almost nobody writes: what else might explain the change. "Two new branches opened in the same window, so volume rose; I compared per-branch medians rather than totals." Naming a confound is the strongest credibility signal in the whole document, because it proves you tried to disprove yourself. That instinct is the scientific-method loop from the faculty's Operate chapter.
6. Evidence a stranger can check in five minutes
Pick two or three: a short screen recording of the system running, a redacted before-and-after report, an architecture diagram, a link to a repository or a template, a named testimonial. Evidence that requires a meeting to understand is not evidence.
7. What you would do differently
Two or three honest lines. This block is why senior people read to the end. "The error handling was an afterthought and cost us a weekend; I now write the failure path first."
A worked example (hypothetical)
The following is an illustrative example written to show the format. It is not a MitHub client result.
Cut time-to-first-contact from 19 hours to 22 minutes across 10 branches Context. Imagine a multi-branch consumer lender in the south-eastern US, ten locations, selling instalment loans to inbound phone and web leads. I worked on inbound lead handling for nine weeks. Problem. Leads landed in a shared inbox and were routed by hand. In a sample of 200 records from the previous quarter, 41% had no logged contact attempt within 24 hours, and 12% had none at all. Branch managers estimated 30–60 minutes a day on triage. What I built. A webhook from the web form into the CRM, a routing rule using branch postcode with a round-robin fallback, and an automated first-touch attempt within two minutes. Transfer to a human stayed manual: a mis-transferred borrower costs more than a slow one, so the rep approves every handover. What changed. Median time-to-first-contact went from 19 hours to 22 minutes, measured as the difference between the lead-created and first-activity timestamps in the CRM, over six weeks and 1,240 leads, using the same saved report for both periods. Records with no contact attempt within 24 hours fell from 41% to 4%. Two branches opened during the window, so I compared per-branch medians rather than totals. Evidence. A 90-second recording of a test lead moving through the system; the saved CRM report with names redacted; the routing diagram. What I would do differently. I did not build a dead-letter queue for failed webhook calls until week seven. Eleven leads were lost before I did. I now build the failure path before the happy path.
Roughly 300 words. Everything checkable. No client identified.
Where MitHub case studies fit
MitHub publishes case studies for its talent, but only at the end of a chain, and the chain is the point: the company paid → the talent delivered → MitHub audited the work → MitHub approved it → the company confirmed it was satisfied → the client agreed to publication. Six gates, and any one of them can stop it.
That is deliberately harder than self-publishing, and it is why a MitHub case study means something different from a portfolio page. The audit step checks the number contract; the client-agreement step is the permission ladder made formal. The your case study chapter of the Faculty of Revenue Reverse Engineering walks through it, and the whole learn, build, prove, earn sequence exists to produce one.
Writing your own case studies well is how you get ready for that chain. Every habit above — baselining before you change anything, asking for permission early, recording evidence while the system is live — is something you have to do during the project, not after.
Pre-publish checklist
- Does the title state a result?
- Does every number have a before, an after, a window and a method?
- Have I named at least one alternative explanation for the result?
- Do I have written permission for the rung I am publishing on?
- Is practice work labelled as practice work?
- Can a stranger verify something in under five minutes without contacting me?
- Is my specific role clear, including what other people did?
- Have I removed every sentence that only lists a tool?
- Would the client be comfortable reading this?
- Is there one honest line about what went wrong?
Three to five case studies built this way will outperform any certificate list on a CV, and they give you something a credential never can: material you can talk about for twenty minutes under questioning. Put the strongest one in your LinkedIn featured section — see how to optimise LinkedIn for remote jobs — and keep the rest on one page you control.