Write Case Studies, Not Screenshots

The difference between a portfolio that gets replies and one that gets scrolled past is almost never the design. It is whether the writing explains a decision or just labels an image.

I write every project the same way now, in five parts, with one test that decides whether any given sentence survives.

The test

Would this sentence change a reader's mind about hiring me?

"Built with React and Node" does not. Everyone says it, and nobody was choosing between me and a Fortran developer.

"The shop owner changes prices himself; he has not needed me since handover" does. It is specific, it is a claim about outcomes, and it is the exact thing a business owner worries about when hiring a freelancer.

Apply that test line by line and most write-ups lose half their length and double their effect.

Part one — the brief

One honest paragraph on the actual business problem, in the client's language, before any solution appears.

A luxury florist with three branches was running every order through phone calls and DMs. They did not need a webshop. They needed their real sales process, online.

Note what is absent: no technology, no adjectives about myself, no "the client approached me to". The reader should be able to recognise their own situation here, because recognition is what makes them keep reading.

Part two — the journey

Four or five decision points, each one a choice that could have gone the other way. This is the section that does the work, and it is the section almost everyone skips.

Every step follows the same internal structure: here was the fork, here is what I chose, here is why. The "why" is the part being purchased — anyone can list what they built, but the reasoning is what a client is actually evaluating when they wonder whether you will make good calls on their project.

Choose the decisions that were genuinely contested. "I used TypeScript" is not a decision. "Each branch became its own store instead of one catalog with a location filter" is, because the obvious alternative existed and the reasoning is not obvious.

Part three — the outcome

Three concrete results. Numbers where you have them, plain facts where you do not.

Resist inventing metrics. "Increased conversions by 340%" without a baseline is a claim nobody believes. "Three branches, one codebase, zero developer involvement in daily operations" is verifiable, unglamorous, and far more convincing.

If you genuinely have no numbers, say what changed operationally. That is still an outcome.

Part four — the stack

For the technical reader, kept in a sidebar where it does not interrupt the story. It signals competence to the people who evaluate on that axis and stays out of the way of the people who do not.

Part five — the link

A live URL beats every claim above it. If the project is under NDA or offline, say so plainly rather than leaving the reader to wonder why there is nothing to click.

What to leave out

The process boilerplate. "Discovery, design, development, deployment" describes every project ever delivered and distinguishes nothing.

Feature lists. A feature list is a description of a screenshot in words.

Self-congratulation. "A beautiful, seamless, cutting-edge experience" is what someone writes when they cannot name a decision.

Projects with nothing to explain. If you cannot find four real decisions, the write-up will be padding, and a padded case study lowers the average of everything around it.

Write them while the project is warm

The details that make a case study specific — the thing you almost built, the objection the client raised, the constraint you found in week two — are gone within a month. I now write the journey section during handover, while the reasoning is still recoverable, and edit it later when I have distance.

A portfolio is not evidence that you can build things. Everyone can build things. It is evidence that you make good decisions when the requirements are unclear — and only writing can show that.

The template

Brief:    the business problem, one paragraph, no tech
Journey:  4–5 forks, each with choice + reason
Outcome:  3 concrete results, no invented numbers
Stack:    sidebar, for the technical reader
Link:     live URL, or an honest reason there isn't one

Five parts. One test per sentence. It takes an hour per project and it is the highest-return hour in freelancing.