How to write a portfolio case study, and how many to write

A case study is the entry a reader opens after they have decided you are interesting. Writing six of them is a way of ensuring nobody reaches that decision.

ConxfolioPublished 2026-09-12

— situation, constraint, what you did, what changed.

Almost every portfolio has too many case studies and too few entries. The instinct is understandable: the work was hard, so it deserves explaining. The effect is a page where nothing can be scanned and the reader leaves before the good one.

Two case studies, and everything else as a line. That ratio is what makes a page usable.

The four parts

• The situation. Two sentences. What the organisation was, what the problem was, why it mattered then.
• The constraint. The part most case studies skip and the part that makes the work interesting. A deadline, a budget, a legacy system, a team of two, a regulator.
• What you did. Specifically, and separating your work from the team's. A reader assumes the vaguer version is the less flattering one.
• What changed. A number where one exists, a plain statement where it does not.

Three to five short paragraphs covers all four. Anything longer is a report, and a report belongs behind a link.

The constraint is the argument

Work described without its constraint sounds like every other version of the same work. "Redesigned the checkout" is a sentence anybody could write. "Redesigned the checkout without changing the payment provider, because the contract had fourteen months to run" is a sentence only somebody who was there could write, and it tells a reader more about your judgement than any outcome number.

This is also the part that survives an interview. A reader who liked your constraint paragraph will ask about it, and you will have an answer, which is the entire purpose of the exercise.

Separate your work from the team's

A case study that says "we" throughout is a case study a reader cannot use, because they are hiring one person. Name the team where the team did the work and be specific about your part: you wrote the migration plan, you ran the research, you made the call about the provider. An honest smaller claim is worth more than an ambiguous large one, and it is the version you can defend when somebody who was also there reads the page.

The confidential version

Much of the best work cannot be shown, which is the ordinary condition of a writing portfolio and common everywhere else. The case study still can be, at one level of abstraction up: the kind of organisation, the shape of the problem, the constraint, the direction of the change. "Reduced a mid-sized insurer's claims handling time by roughly a third" is publishable where the client's name and the exact figure are not.

What is not acceptable is implying you can show something you cannot, or publishing material your agreement covers. Where a proportion is safer than an absolute, use the proportion; it is accurate and it is yours to give.

Where it goes in the builder

Every entry in the portfolio builder has a details panel holding a longer description, a link, an image and tags, and that panel is where a case study lives. The entry's own outcome line stays as it is, because the line is what a scanning reader sees and the case study is what a committed reader opens.

The sheet counts how many entries are on the page section by section, so it is easy to see when the page has drifted long. Two case studies among six entries is a shape that works; six among six is not. The number of projects has the rest of the arithmetic.

One failure, told properly

A case study about something that did not work is the most memorable entry on most pages, provided it ends with what you did differently afterwards. It has to be a real failure rather than a disguised success, and it has to be one where the lesson is specific. Used once it demonstrates judgement; used twice it reads as a theme.

Check it at both widths

Long text behaves differently on a phone, and the step before publishing renders the real page at desktop and phone width. A case study that reads well in a wide column can become a wall on a narrow one, and the repair is usually a paragraph break rather than a cut. The same check catches long entry titles, which is the other thing that breaks on a narrow screen.

Write it soon after the work

The constraint paragraph is the one that decays. Six months later you remember what you built and not why the obvious alternative was unavailable, and the case study flattens into a description. Writing a few lines while the project is still recent, even into a note you never publish, preserves the part that turns out to be the valuable one.

The outcome often arrives later than the work, so the entry is usually written twice: once for what you did and once, months afterwards, for what changed. Keeping the draft somewhere you will find it again is what makes the second pass a five-minute job rather than an act of reconstruction.