Building a portfolio when you have no client work

The advice everyone gets at this stage is the same, and it is bad: redesign something. Pick an airline app, a banking flow, a checkout page, and rebuild it the way you would have done it. It produces a portfolio in a weekend, it looks like real work, and reviewers discount it almost on sight. The usual explanation is that unpaid speculative work signals desperation, or that it is somehow dishonest to work on a problem nobody asked you to solve. Neither is quite right, and the wrong explanation leads to the wrong fix — more polish, better mockups, a case study template copied from someone who got hired.

The real reason is simpler and more useful once you see it: there was no constraint. Nobody told you the deadline was three weeks, that the backend could not change, that the client hated a previous version and would not say why, that half the users were on old Android phones. You set the brief, you set the scope, you were the client, and you were, unsurprisingly, an extremely accommodating one. A reviewer cannot tell whether you have good judgement from that, because judgement is what you do when a choice is actually costly, and in an unsolicited redesign no choice costs you anything. You can always just make it nicer.

That diagnosis points straight at the fix. The problem with substitute work is not that it is unpaid or self-assigned. It is that most of it has no constraint, and the fix is to build one deliberately, then show the reviewer exactly where it bent the work.

It's worth separating this from a smaller, easier problem people tangle up with it: where the two projects actually live once they exist. That has a fast answer and does not deserve the weeks people lose to it. reach turns a CV into a live one-page site in under two minutes — upload a résumé and a photo, pick a look, and it publishes to a free yourname.joinreach.app subdomain instantly. It won't host a multi-project case-study page — it makes exactly one page, no sub-pages, no CMS — so the write-ups themselves still need somewhere with room to breathe, usually linked from the site rather than built into it. But as the place that carries your name and the two real projects, it removes a stalling point that has nothing to do with judgement and everything to do with procrastination dressed up as design work.

The exception that proves the point

There is a version of the unsolicited redesign that works, and it is worth naming because it confirms the diagnosis rather than contradicting it. It is the redesign done against a real, stated limitation you chose in advance and held yourself to — rebuild this checkout flow, but it has to work with the existing three-field data model and cannot add a fourth field to the database, because the actual product would never get that migration approved. Or: redesign this onboarding, but the total build has to ship in one week because that is what a real team would have.

The difference is not effort. It is that a constraint like this forces trade-offs a reviewer can evaluate, the same way a real brief would. Without it you are grading your own homework. With it, even a self-assigned project produces the one thing a portfolio actually needs to show: a moment where you wanted to do something and could not, and did something else instead.

What actually earns credit, ranked

Not all substitutes are equal, and the ranking follows directly from how much real constraint each one carries.

A real project for a real person, even a small one, beats everything else. A friend's business that needed a booking page, a relative's shop that needed a menu redesigned, a local club's sign-up form that was losing people halfway through — these come with an actual client who has opinions, a budget of zero that still has to be respected, and a deadline that matters because the thing has to go live for an event or a season. What a reviewer checks for is not scale, it is whether you had to negotiate with someone else's preferences and constraints, which is the actual job.

Volunteer work for an organisation ranks close behind, for the same reason plus one more. A nonprofit, a school, a community group — these have stakeholders, existing systems you cannot simply delete, and users who are not you and will not forgive a confusing form. The extra credit comes from volunteer clients often being disorganised in exactly the way real employers are: unclear about what they want, slow to respond, prone to changing their mind halfway through. Navigating that is itself the evidence.

Internal tools — for a team you are part of, a class, a hackathon, a student org — come next. They have real users and real constraints, but the stakes are lower and the users are more forgiving than the general public, so the trade-offs you made are less costly and less convincing. Still genuinely useful, especially paired with something further up the list.

A brief with a hard, invented constraint sits below all of these but above a plain redesign, for the reason already covered. It is the fallback when you genuinely have access to none of the above, and it is far better than nothing, but a reviewer can tell the difference between a constraint you imposed on yourself and one imposed by someone who could walk away.

An unsolicited redesign with no stated constraint sits at the bottom, not because the work is bad but because it is unreadable. There is nothing in it for a reviewer to assess.

Manufacturing a constraint on purpose

If nothing above the bottom of that list is available to you right now, the move is not to wait for it. It is to build the constraint deliberately and document it as part of the project, not as an afterthought.

Pick something specific and hold to it. A deadline: one week, not one month, with the start and stop dates noted. A technical limitation: no database, a fixed set of five screens and nothing more, or it has to work without JavaScript. A user limitation: it has to be usable by someone who has never used a smartphone, or someone on a train with patchy signal. Then write down, next to the finished work, the two or three places where that constraint forced a worse-looking but more defensible decision than an unconstrained version would.

That last part is the whole exercise. A constraint nobody can see in the finished work did no work. The point is not to have suffered under a rule — it is to point at a specific place in the project and say: I wanted to do X, the constraint made that impossible, I did Y instead, and here is why Y was the right call given the limit rather than despite it. That sentence is what a reviewer is actually looking for, whether the constraint came from a client or from you.

Coursework: show the decisions, hide the classroom

Coursework is usable, and most people either omit it entirely out of embarrassment or include it with the assignment framing still attached, which is worse. Strip the grade, the rubric, the module title, the phrase "for my final project." None of that tells a reviewer anything they can use, and all of it signals that the constraint was academic rather than real, which quietly discounts everything else on the page too.

What survives the strip is the same four things any project needs: what the situation was, what you specifically decided, what a competent peer might have decided differently, and what happened. A coursework brief usually carries a real constraint — a dataset you could not change, a deadline, a technology you were required to use — so describe it the same way you would describe a client's. That a professor set it rather than a client matters far less than whether it actually shaped what you built.

Talking about a project nobody used

This is the case people mishandle worst, usually by inventing an outcome to fill the gap a project without users leaves open. It backfires immediately: the invented number is the first thing a curious reviewer asks about, and there is no honest follow-up answer for a number that does not exist.

The better move is to say the true thing plainly: this did not launch, or it launched to nobody, and here is what I would have measured if it had. That sentence, followed by the decision you would defend and the reasoning behind it, gives a reviewer everything they actually need. Outcome is only one of four things a project has to demonstrate, and reviewers weight it least for a junior candidate, because they know early work rarely proves itself in the market. What they cannot forgive is a fabricated number — not a missing data point but evidence of how you handle the gap between what happened and what you wish had happened, a much worse thing to reveal than an honest zero.

Two projects, built properly, beat six

The instinct at this stage is to compensate for thin material with volume — if one project is not quite enough, six will surely add up to something. It does the opposite. A reviewer, as covered in the piece on how portfolios actually get read, judges the set they see, not the strongest item buried in it, so four weak entries do not average out against two strong ones — they drag the two strong ones down by association and by the time it costs to find them.

Two projects, each with a real or manufactured constraint, written as a decision rather than a description, honest about what happened and what did not, will outperform a page of six things skimmed in ten seconds each. The same logic applies once client work exists, too, so the habit is worth building now rather than unlearning later. Where that work should live is covered in choosing between a GitHub profile and a portfolio site and, for anyone building the page for the first time, in what a personal website needs when you have just graduated.

The chicken-and-egg problem is real. Nobody gives you client work without a portfolio, and you cannot get a portfolio without client work. But the thing reviewers actually check for was never the client relationship itself — it was evidence you can make a defensible call under a real limit. That evidence is available to anyone willing to invent the limit and be honest about where it hurt.