Building a Portfolio That Actually Gets Replies

Your portfolio has exactly one job: convince a specific person, who has a specific problem and a budget, that you can ship the thing they need.

Not "showcase your work." Not "express your personality." One buyer, one decision, one click to contact you. Everything else either serves that or costs you replies.

I rebuilt mine this year with that sentence taped to the top of the file. Here's the order I'd fix things in.

1. Three case studies, not twenty thumbnails

A grid of twenty project cards says "I have done a lot of things." A buyer doesn't care how many things you've done. They care whether you've done their thing, and twenty options makes that harder to find.

Three case studies, chosen because they're closest to the work you want more of. Everything else lives in a plain list at the bottom, or nowhere.

I cut mine down and the difference in enquiry quality was immediate. People started referencing actual projects in their first message instead of asking generic availability questions.

2. Make each case study a story with a decision in it

The default developer case study is a screenshot, a stack list, and a live link. That's a receipt, not evidence.

Each of mine now covers five things:

• The problem. What was broken or missing, in the client's language.
• The constraint. Six weeks. No backend team. Had to run offline. Constraints make the work interesting, and they're what a buyer recognises from their own situation.
• What I built. Concrete. Screens, services, pipelines.
• Decisions and why. This is the section that sells. "Postgres over Mongo because the reporting requirements were relational from day one." "Expo because the client needed OTA updates more than native modules." Anyone can list a stack. Judgement is the scarce thing.
• The outcome. A number if you have one, otherwise a sentence about what changed.

That fourth bullet is the whole game. Clients aren't buying your ability to write React. They're buying your ability to make the call they can't make themselves.

3. Name the client and name the stack

Vague portfolios read as fabricated. "A leading fintech company" reads as a lie whether or not it is one.

Get permission and use the name. Where an NDA genuinely blocks it, describe the company precisely enough to be credible: "a US travel startup, pre-seed, four people." Always name the stack, because half your buyers are technical and are scanning for a keyword before reading a sentence.

4. Put the contact route above the fold, one click away

I had my contact form at the bottom of a long scroll. A form. With four fields.

Now there's a visible way to reach me on the first screen, one click to an email or a booking link. Not a form that swallows a message into a void with no confirmation.

The person deciding whether to email you is deciding in about eight seconds, distracted, probably on a phone. Don't make them scroll for permission.

5. Write a "what I do" sentence that survives being forwarded

This is the highest-leverage sentence on the site, and most developers write the worst possible version of it.

"Freelance web developer" is not forwardable. Nobody has ever pasted that into a Slack channel on your behalf, because it identifies you as one of ten thousand interchangeable people.

"I build AI products and mobile apps end to end" is forwardable. It's specific enough that when someone in a group chat asks whether anyone knows a person who could build a chatbot over their docs, a friend of yours knows the answer is you.

Write it for the person forwarding it, not the person reading your site. Your best traffic never sees your homepage first.

6. Speed and mobile, because of where people actually read it

A meaningful share of my visitors are on a phone, and a chunk of those are checking me out between meetings, on hotel wifi, with three seconds of patience.

So: no blocking hero animation, images sized properly, fonts that don't cause a flash of nothing, and a page that renders content before decoration. Test on a throttled connection, not on your fibre.

This isn't a performance-purist argument. A slow site loses the exact visitor you most want, the busy one with a budget. I work from cafés in Southeast Asia most weeks, so I'm testing on roughly the connection my prospects read on.

7. Writing, as proof of judgement

Case studies show what you shipped. Writing shows how you think, which is what a client is actually trying to assess in a 20-minute call.

A handful of posts that take a position and defend it will do more for you than any amount of design polish. It also gives a warm lead something to read while deciding. It pairs with the channels that actually bring in a first client, because most of them end with someone landing on your site.

What nobody cares about

• Skill bar charts. "React: 90%." Against what scale, judged by whom? Signals junior instantly.
• A logo carousel of tools. Everyone has the same logos. Decoration with a loading cost.
• A hero animation that delays the content. Including, painfully, mine.
• "Passionate about clean code." Every developer says it. Zero information.

The version I have to be honest about

I built a WebGL portfolio. Three.js, custom shaders, a scroll-driven scene. I loved building it, I learned an enormous amount, and I still think it was worth the weekends.

As a sales asset it was probably a net negative.

It was heavy. On mid-range Android over café wifi it took visibly too long to become useful, and I later found it could hang outright on some phones, which I had to patch. The animation ran before the content. A prospective client on a phone got a nice gradient and a loading state where the answer to "can this person build my app" should have been.

The version that works is faster and plainer. Type, three case studies, a contact link at the top, rendering in about the time it takes to look up from your phone. It's less fun to show other developers. It gets more replies.

That's the tension nobody says out loud: your portfolio is judged by clients and admired by peers, and those audiences want opposite things. I spent months building for the one that doesn't pay me.

Build the plain one. Put the fun one on a subdomain, as a case study about itself.