Your Portfolio Is a Product, Not a Gallery

I rebuilt my portfolio three times. The first two were galleries: here is a grid of things I made, arranged in the order I made them. Both were honest. Neither got me work.

The version you are reading this on is built differently, because I finally accepted what a portfolio is. It is not an archive. It is a sales page with a very specific job — helping one person decide, in about ninety seconds, whether to start a conversation.

Screenshots answer the wrong question

A screenshot says I touched this. It proves the pixels existed. What it cannot show is the only thing a client is actually buying: judgement under constraint.

Every project I ship contains four or five decisions that could have gone the other way. Branch-level catalogs instead of one shared list. A WhatsApp handoff instead of a payment gateway. A server proxy in front of an AI feature. Those decisions are the work. The interface is just where they became visible.

So the case study leads with the decision and uses the screenshot as evidence, rather than leading with the screenshot and hoping the reader infers a decision that was never stated.

The reader is not a developer

This is the correction that changed my writing most. The person deciding whether to hire me is usually a founder, a marketing lead, or an operations manager. They do not care that I used Prisma. They care that their staff can change a price without calling me.

That does not mean hiding the stack — technical readers exist and the stack signals competence to them. It means the stack goes in a sidebar, and the sentence in the body says what the client got.

Compare:

Built with React 18, TypeScript, Express and Prisma in a monorepo with a full admin dashboard.

against:

Three branches, each with its own prices and stock, run by the shop owner from one dashboard. No developer needed to change anything.

Same project. The second one closes.

Structure that carries a reader through

Every case study on this site follows the same five beats, because a consistent shape lets a reader skim two projects and still understand both:

1. The brief — the actual business problem, in one honest paragraph.
2. The journey — four or five decision points, each with what I chose and why.
3. The outcome — three concrete results, stated plainly.
4. The stack — for the technical reader, kept out of the way of everyone else.
5. The link — see it live, because a live URL is worth more than any claim.

The journey section is the one that took the longest to write and does the most work. It is where a reader stops evaluating my taste and starts evaluating my thinking.

Show the work you are proud of, not all of it

My archive has more projects than the site displays. Everything that did not have a decision worth explaining was cut, because a weak project does not add credibility — it averages it down.

The exception I kept is my old portfolios, listed deliberately as an archive. Showing the two versions I outgrew says something about trajectory that a polished grid cannot.

Make the next step obvious and small

A portfolio that ends with nothing to do wastes the ninety seconds it just earned. Every case study ends with a live link and a way to reach me, the contact section is one scroll from anywhere, and the ask is small — a message, not a discovery call with a calendar invite.

Test it yourself: open your portfolio, count how many seconds pass before a stranger learns what you do, who you do it for, and what to click. If it is more than ten, the design is not the problem.

The uncomfortable part

Writing a real case study forces you to admit what you actually decided, and sometimes the honest answer is "the client asked for it and I built it." Those projects are hard to write up, which is itself useful information — it tells you which work was engineering and which was typing.

Write the ones where you decided something. Those are the ones that bring you more of the work you want.