Applications: [Open / closed status to be confirmed]Deadline [Application deadline]Cohort begins [Start date]

How to build a portfolio when nobody has hired you yet

You do not need a client to have proof. You need a real problem, a documented decision and a result you can explain. Here is how to produce the first one honestly.

A portfolio of proof at the centre, surrounded by the six things that carry it into a hiring process: CV and LinkedIn, a tailored application, interview preparation, async communication, business English and remote logistics.

The most common reason a capable person stays unhired is not a missing skill. It is that they have nothing a stranger can look at. They have certificates, which prove attendance, and a CV, which is a claim. Neither is evidence.

A portfolio solves that, and you can build one before anybody pays you. What you cannot do is fake it, and you do not need to.

What a portfolio is actually for

It is not a gallery. Its job is to let somebody who has never met you answer one question: if I give this person a problem, will they handle it sensibly?

That means the interesting part is never the deliverable. It is the reasoning. Two candidates can submit an identical dashboard and only one of them can explain why those metrics, why that time period, and what they would have done if the data had said something else. That one gets hired.

Self-initiated work counts, if you are honest about it

You are allowed to choose your own problem. You are not allowed to imply that somebody paid you for it.

Label it plainly at the top: self-initiated project, no client relationship, data from a public source or from a site I built for the purpose. Nobody minds. What ends a hiring conversation is discovering the ambiguity later, and it always surfaces, usually in the interview where you are asked what the client said.

Honest framing also lets you do things a client would never approve, like publishing the version that failed.

Four projects you can start this week

A measurement plan for a business you can see

Pick a real local business with a website. Write the one page plan: the decision, the one number, the events, the thresholds. You need no access and no permission, because you are not touching their site. This demonstrates thinking, which is the scarcest thing in a junior application.

A landing page teardown with a rebuilt version

Audit a real page, in order, and write up three findings as decisions rather than observations. Then rebuild the section you criticised most and put the two side by side. The rebuild is what stops it reading as an opinion.

A small site you own, instrumented properly

Build something modest that genuinely exists: a one page site for a friend’s business, a resource for your own community. Then set up the tracking properly, including consent, and run it for six weeks. Now you have your own data, and you can say true things about real numbers instead of hypothetical ones.

A campaign you ran with your own money

A small budget, spent deliberately over two weeks, with a plan written before it started. The amount does not matter. What matters is that you have made the decisions: audience, offer, page, threshold, and what you did when the first week underperformed.

Document the decision, not just the deliverable

For each project, write down the things that are normally lost:

  • what you thought would happen before you started
  • what you decided to leave out, and why
  • where the data was weak and how you handled it
  • what happened that you did not expect
  • what you would do differently with twice the time

That last one is the question you will be asked in the interview. Having already answered it in writing is the difference between sounding thoughtful and sounding rehearsed.

How to write a case study somebody will finish

Keep it to one page and use the same five headings every time:

  • Situation. Two sentences. What existed and what was wrong with it.
  • Decision. What you chose to do and what you chose not to do.
  • Work. The specifics, briefly. Screenshots are useful here, paragraphs are not.
  • Result. The honest outcome, including nothing happened if that is the answer.
  • What I would change. Written before anybody asks.

Three case studies in that format will outperform a dozen loose project descriptions, because a hiring manager can compare them and can finish them.

What to leave out

  • Percentages with no base. An improvement of two hundred per cent from two to six is not a result, it is arithmetic.
  • Course exercises presented as projects. Everybody who took that course has the same one, and hiring managers have seen it.
  • Client work you cannot show. If it is under an agreement, say so in one line and move on. Do not describe it vaguely at length.
  • Tool logos as a substitute for evidence. A row of platform badges tells a manager nothing about whether you can use any of them.

Where to put it

Somewhere that opens in one click, with no login and no access request. A simple site you control is best, because you keep it when a platform changes. A public document is acceptable if the permissions genuinely work for a stranger, which you should verify from a browser you are not signed into.

Then link it from the first line of every application and every profile, because a portfolio nobody can find is the same as not having one.

Start before you feel ready

The first case study will be the worst one, and publishing it is still the right move. It exists, it can be improved, and it puts you ahead of every equally capable person who is waiting until they have something impressive.

The people who get hired remotely are rarely the most talented applicants. They are the ones whose evidence arrived first.