How to Build a Portfolio With No Experience

The advice given to people with no experience is usually circular. You need a portfolio to get work, you need work to have a portfolio, and somewhere in between you are supposed to start. Most guides resolve this by telling you to "create your own projects", which is correct and almost useless on its own, because the hard part was never making something — it is knowing what counts, and how to present it so a stranger takes it seriously.

So let us be precise about the actual problem. A client or hiring manager looking at your site is not asking whether you have been paid before. They are asking one question, and it is a question about risk: if I give this person work, is it likely to come back finished, on the brief, and roughly on time? Payment history is one kind of evidence for that. It is not the only kind, and it is not even the strongest kind for small first jobs.

We assume here that you already know what a portfolio website is and are only short of things to put in one. This guide covers what counts as evidence when nobody has hired you, the one labelling rule you cannot break, how to write a brief for yourself that produces something worth showing, how many projects you actually need, what to write beside each of them, and a two-week plan for getting a real site live.

What actually counts as evidence

Five sources of work will produce something a reviewer can look at. They are not equivalent — they prove different things, and one of them proves nothing at all.

The verdict column is the part people get wrong. Two of these are worth more than they look.

A few notes on the rows that need them.

The paid trial task is worth chasing harder than most beginners do, because a single small paid job converts you from "unproven" to "has worked with clients" in one step. It does not need to be big. A one-day job at a reduced rate, taken deliberately and early, buys you a real deadline, a real opinion at the end, and — if you ask well — a testimonial. Take one or two of these, not ten; the discount is a launch tactic, not a pricing strategy, and there is a separate discussion to have about what to charge once you are past it.

Volunteer work is undervalued because it is unpaid, and people assume unpaid means unserious. From the reviewer's side it is the opposite: a charity that needed a booking form fixed is a real client with real constraints and a real opinion, and the fact you were not paid does not change what the work demonstrates. What it demonstrates, specifically, is that you can work with somebody who changes their mind halfway through — which is most of the job.

The tutorial follow-along has to go. This is the one piece of advice in this guide that people resist, so here is the reasoning. Reviewers in every field have seen the popular tutorials. They recognise the same to-do app, the same weather dashboard, the same three-screen food delivery concept, and they recognise them instantly. Including one does not read as neutral — it reads as a statement that you could not find anything better to show, which is worse than showing three things instead of four. If a tutorial taught you something, keep the skill and drop the artefact.

The one rule you cannot break

Label self-initiated work as self-initiated. Every time, on the project itself, not in a disclaimer at the bottom of an About page.

Same screens, same work. Only one of them survives being checked.

The reason is not primarily ethical, though it is that too. It is that the alternative does not work. Anyone seriously considering you will spend thirty seconds checking, and a concept project attached to a real company name is trivially checkable — they open the app, they look at the live site, they notice it bears no relationship to what you have shown. At that moment they are not thinking about this project. They are re-reading everything else on your site wondering what else was implied.

Labelling costs you nothing, because nobody minds that a project was self-initiated. It also quietly earns you something: "I noticed this checkout flow was slow and rebuilt it" says that you spot problems unprompted and act on them, which is a more interesting claim about you than "a client asked me to". The wording needs more care in fields where the sample is a rebuilt document rather than a visible design — the mock inboxes and rebuilt SOPs in a virtual assistant's sample work have to say plainly that the client was invented, because nothing in the artefact itself gives that away.

Writing a brief for yourself

Most self-initiated projects are weak for the same reason: no brief. Without one there are no constraints, so there are no decisions, so there is nothing to explain — and it is the explaining that does the persuading. Before you make anything, write four lines down and do not change them afterwards:

• Who it is for. Not "users". A specific person in a specific situation: someone booking a same-day dentist appointment on a phone with one bar of signal.
• What is going wrong for them now. One sentence, stated as their problem, not as your solution. "There is no way to see which slots are actually free" — not "it needs a calendar view".
• The constraint. Give yourself a real one and honour it. Two weeks. No new brand assets. Must work without JavaScript. Must be buildable by one person. Constraints are what turn an exercise into evidence.
• How you will know it worked. Even without live traffic you can define this: fewer steps to a booking, a form a screen-reader can complete, a page that loads in under two seconds on a throttled connection.

That last line is the one that separates a portfolio project from a nice-looking artefact, and it is where invented numbers do real damage. Do not write "increased conversions by 40%" about something no user has ever touched. Write what you measured and how — "the redesigned form completes in four fields instead of eleven, and passes an automated accessibility check that the original fails" is a true, checkable, unglamorous claim, and it beats a fabricated percentage with every reader whose opinion you want.

Three projects, not ten

The instinct without experience is to compensate with volume. It backfires, for a reason worth internalising early: a portfolio is averaged, not summed. Reviewers form an impression of your standard from the whole set, and a weak piece drags that impression down further than a strong piece lifts it. Three good projects read as a person with taste. Three good projects and four filler ones read as a person who cannot tell the difference — which is a much worse thing to say about yourself, because taste is the thing that cannot be taught in a week.

Three is the number to aim for. If you have four and one is clearly weakest, you have three. Make them different from each other in a way that is legible — a different problem type, a different medium, a different constraint — so the set implies range instead of repeating one trick.

What goes beside each project

The single biggest difference between a beginner portfolio and a professional one is not the work. It is that the professional one is written. A grid of images with titles underneath asks the viewer to do all the interpretive labour, and viewers do not do it — they scroll.

Each project needs a short piece of writing next to it. Not a full case study for all three, but at least: the brief in one sentence, the constraint you worked under, the two decisions you are prepared to defend, and what you would do differently now. That last one matters more than it seems. Nothing signals judgement faster than being able to critique your own work, and nothing signals inexperience faster than presenting everything as if it came out perfect.

Then write one of the three up properly, at around eight hundred words, and link to it prominently. One real case study is worth more than three summaries, because it is the only artefact that demonstrates how you think rather than what you produced.

The rest of the site

Two pages carry disproportionate weight when you have no track record.

The About page is where a reader decides whether they want to work with you, having already decided whether you are capable. Do not use it to apologise for being new. State what you do, who for, what you did before this (a previous career is context, not a liability), and what you are working towards. Three hundred words, first person. There is a fuller treatment in our guide to writing the About page.

The contact section should make the next step obvious and small. A visible email address beats a form for most freelancers, and either beats a link to a social profile. The most common failure here is not friction, it is absence: a surprising number of new portfolios never state plainly that the person is available for work.

Everything else — the services list, the tools grid, the testimonial slot — can wait until you have something true to put in it. An empty testimonial carousel with a placeholder quote is worse than no testimonial section.

If you are changing careers, not starting one

Most people who say they have "no experience" mean no experience in this field. That is a materially different position, and treating it like a blank slate throws away the strongest evidence you have.

Work backwards from what the new work actually requires. A teacher moving into UX has spent years watching people fail to understand something and adjusting the explanation in real time, which is user research done under harder conditions than most usability tests. A nurse moving into product work has triaged competing priorities under time pressure with real consequences. An accountant moving into data work has been cleaning other people's messy inputs for a decade. None of this belongs on your site as a paragraph about transferable skills — that phrasing is dead on arrival — but it belongs in the specific claims you make.

Concretely: pick your self-initiated projects inside the domain you are leaving. A former nurse who redesigns a shift-handover tool is not a beginner making a concept project; they are the only person in the applicant pool who knows what actually goes wrong at handover. That is a real advantage and it is visible in the work, in the questions the project asks, and in the constraints it takes seriously. Domain knowledge is the one thing a career changer has that a graduate does not, and it is worth more than the year of experience you are missing.

Two practical notes. Keep the previous career on the site as context — a one-line mention on your About page is enough, and hiding it makes the gap look like something worse. And check what you are permitted to show: internal documents, patient-adjacent material and anything commercially sensitive from a previous employer usually cannot be published, regardless of the fact that you made it. Both notes apply equally to the CV that carries the link, where the previous career belongs as a dated role rather than as an explanation — our free CV builder will lay one out in a single column without an account.

Where to put it

Use one template and spend your effort on the work inside it. Building a bespoke portfolio site from scratch at the start of a career is a trap that has consumed a lot of people's first three months, and the resulting site is rarely better than a good template — it is just later. Budget is not a reason to delay either: our own free portfolio website templates publish to a subdomain without a card, and several other builders will do the same.

Whatever you use, three things matter. It should be on a URL that is yours rather than a profile inside somebody else's product, so the traffic and the ranking accrue to you. It should be reachable at a name you can say out loud, which is worth the annual cost of a custom domain once you are past the first draft. And it should be fast on a phone, because that is where a meaningful share of first views happen.

A two-week plan

This is a realistic schedule for someone doing this around a job.

• Days 1–2. Decide what you want to be hired for, narrowly enough that a brief follows from it. Write the four-line brief for project one. Do not open a design tool yet.
• Days 3–7. Build project one. Honour the constraint. Keep a running note of decisions and the things you rejected — you will not remember them later, and they are the raw material for the write-up.
• Days 8–9. Write project one up properly. Eight hundred words, following a structure rather than freewriting.
• Days 10–11. Assemble the site: hero line, three projects, the case study, About, contact. Use a single template and do not design a site from scratch — a bespoke portfolio built by someone at the start of their career is a project that eats the projects.
• Day 12. Publish it. Live and imperfect beats perfect and unpublished, and the deadline is what stops project one becoming project four.
• Days 13–14. Send it to five people who will be honest, ask them what they think you do, and fix whatever they got wrong. Then start using it — a portfolio is an input to getting clients, not a substitute for asking.

Four things not to do

Do not write "aspiring". Aspiring designer, aspiring writer, aspiring developer. You either do the thing or you do not, and the qualifier invites the reader to discount everything after it. If you have made three projects, you are a designer with three projects.

Do not lead with the courses you have taken. Certificates describe input; a portfolio is about output. List them somewhere if you like, below the work.

Do not hide the dates. Recent work with a visible date reads as momentum. People notice missing dates and assume the worst about them, which is usually less generous than the truth.

Do not wait for the site to be finished before showing anyone. The version you publish in week two will be replaced in month three regardless. The only version that never gets replaced is the one that never went live.

---

How we put this guide together

The five-source framework, the three-project recommendation and the two-week plan are our own guidance, drawn from what we see working on portfolios built with Bunfolio and from the consistent shape of the question when people ask it — almost always by someone who has more usable material than they think, arranged in a way that hides it.

We have deliberately not attached figures to claims like "reviewers spend thirty seconds checking". Numbers of that kind circulate widely in portfolio advice and are rarely traceable to a study anyone can read; where we give a duration in this guide it is a description of behaviour we have observed, offered as a rule of thumb rather than a measurement.

The advice to label concept work honestly, to write about the work rather than only display it, and to publish under your own name is consistent with Google's guidance on creating helpful, reliable, people-first content, which asks who produced the content and whether it demonstrates first-hand experience. The Northwind Bank example is invented, as is every piece of sample copy here.

Related reading: how to build a freelance portfolio website that wins clients, how to write a portfolio case study, and how to get your first freelance clients, and the teaching portfolio if you are training as a teacher and evidencing coursework against a standards framework.