5 October 2026·22 min readPortfolioCareer changeEvidenceCloud & AI

Build One Project That Grows Up

By Esperance Brooks5 October 2026

Almost every portfolio guide tells you to build three to five projects. It's the wrong shape of advice. A hiring manager reading your GitHub isn't counting repositories — they're looking for evidence that you can make a decision and live with it. Five projects started from five tutorials show five beginnings. One project carried through six honest versions shows a person growing up in public. This guide walks that arc, gives you the scenarios to put your project through, and ends by putting the projects you already have on trial. Your answers save in your browser as you go.

The graveyard

You know the folder. A URL shortener. A weather dashboard. A to-do app with auth. A “serverless” thing from a YouTube series. Each one stops at the moment it worked — which is exactly the moment the interesting questions start. Nobody abandoned them out of laziness. They were finished, in the only sense the tutorial defined.

Here's the problem with that definition. The market is not short of people who can get something working. It is short of people who can be trusted with something that is already running. In the UK's AI Labour Market Survey, 35% of organisations reported at least one hard-to-fill AI vacancy, and the top two reasons were candidates lacking work experience (31%) and lacking technical skills (30%) [3]. Read that honestly: the gap employers name first isn't knowledge. It's the behaviours that only appear after the demo works.

110

Applications per hire at technology employers

SmartRecruiters 2025

140

Applications per UK graduate vacancy — a 30-year high

ISE 2025

31%

Hard-to-fill AI roles blamed on candidates lacking work experience

DSIT 2025

91%

US recruiters who have spotted candidate deception

Greenhouse 2025

The reframe this guide runs on

A portfolio is not a gallery of things you made. It is a changelog of judgement — the record of what you chose, what it cost you, and what you did when it broke. A gallery needs many pieces. A changelog needs one subject and a long history.

Before we start: name the project you'd show an interviewer tomorrow, and the last thing you changed in it.

Choosing something worth six versions

The arc only works if the subject can carry it, and most tutorial projects can't. A URL shortener has no interesting failure modes, no data worth protecting and no cost curve. You will run out of honest versions by v2. Three qualities make a seed project survivable:

It has real data flowing through it. Something arrives, gets stored, gets read back. Data is what makes security, cost and failure real rather than theoretical.
Someone could plausibly want it. Not a market — one person. You, your team, a friend's business, a community you're in. Real users generate real requirements, and real requirements are what you'll later be asked to defend.
It gets worse under load. If ten times the traffic wouldn't change anything, there is no v5. Pick something with a queue, a database, an external API or a file store in it.

Which seed are you starting from?

Question to sit with: can my project still be interesting after it works?

v1 — Make it work

The version everyone already knows how to build, and the one that proves the least. Finish it quickly and without ceremony: the happy path, deployed somewhere a stranger can reach, and a README that says what it does. Do not spend a month here polishing. The whole point of this guide is that v1 is a starting line that most portfolios mistake for a finish line.

What to write down: the problem in one sentence, who it's for, and what you deliberately left out. That last item matters more than it looks — it's the first evidence that you make choices rather than accumulate features.

The trap at v1

Adding a second project. The urge to start something new is strongest exactly here, because v1 feels done and v2 feels like homework. Starting again is how five beginnings happen.

v2 — Make it real

Real means it stops being one process on one machine. Separate the environments so you can break one without breaking the other. Put the data somewhere durable. Give it an identity model, even a small one. Put the infrastructure in code so the whole thing can be destroyed and rebuilt — and then actually destroy it and rebuild it, because that is the test.

Two environments, and a deliberate difference between them (smaller instances, fewer replicas, test data).
Infrastructure defined in code, with state stored somewhere that isn't your laptop.
Secrets in a secret store, and a short note explaining how the application gets them without an access key.
Least-privilege access: what can this component reach, and what is it explicitly denied?
One diagram that shows the real components — including the ones you'd rather not draw.

What to write down: the diagram, and a paragraph on what changed between v1 and v2 and why. “Why” is the word doing the work. “I moved from a single instance to two environments because I kept breaking the thing I was demoing” is a better sentence than any architecture buzzword, because it's true and it's specific.

v3 — Make it defensible

This is where most portfolios stop being ordinary. At v3 you stop asking “does it work?” and start asking “why this and not the obvious alternative?” — and you answer it in writing, before anyone interviews you.

Pick two or three decisions you actually made and write a short decision record for each: the context, the options you considered, the choice, the consequence you accepted, and — the line most people omit — what would change your mind. That last line is what separates an opinion from a judgement.

ADR-003 — Queue between the API and the worker

Context    Uploads spike unpredictably; the worker is slow and occasionally fails.
Options    (a) call the worker directly  (b) a managed queue  (c) scheduled batch
Decision   Managed queue, with a dead-letter queue after 3 attempts.
Accepted   Added operational surface and ~£6/month; processing is now eventually
           consistent, so the UI must show "processing" states.
Revisit    If p95 processing drops under 2s and failures stay under 0.1% for a
           month, a direct call would be simpler and I'd take the simplicity.

Why this version earns interviews

Interviewers can't test judgement with “what is a queue?”. They test it with “why did you use one?”. A candidate with written decision records has rehearsed that conversation on paper, alone, without pressure — months before being asked.

Question to sit with: can I defend one choice in my project, including what would reverse it?

v4 — Make it survive a constraint

Everything you've built so far assumed unlimited money, unlimited time and one engineer who agrees with himself. Real systems are shaped by limits, and the ability to design inside them is the thing that reads as senior. So impose a limit on yourself — a real one, with teeth — and redesign under it.

Draw one of these and apply it honestly. The goal is not to make the system worse; it's to make the trade-off visible and defensible.

What to write down: the constraint, the redesign, and the sentence most candidates never write — what you gave up. “Under £40 a month I moved from a managed database to a single small instance with scheduled backups; I accepted a slower recovery time and documented it” is the sound of someone who has made peace with a trade-off.

Which context are you aiming at? The constraint that matters most changes with the employer.

v5 — Make it operable

Everything up to here can be done calmly. v5 is the version where you deliberately make your own system have a bad day, and then handle it. This is the rarest evidence in a junior-to-mid portfolio, which is precisely why it's worth the weekend.

First, make it observable: a dashboard with the two or three numbers that would tell you something is wrong, and one alert that would actually wake you. Then break it on purpose and write down what happened.

Multiply the load. Generate ten times the traffic you expected. What falls over first — and was it the thing you predicted?
Kill a dependency. Take the database, the queue or the external API away mid-request. Does the system degrade, or does it lie to the user?
Make it slow, not dead. Add 800ms to a downstream call. Slowness is the failure mode that teaches the most, because nothing alerts and everything suffers.
Watch the bill. Leave the load running for an hour and look at what it cost. Cost is a system behaviour, not an afterthought.

What to write down: a short incident note per experiment — what you did, what you observed, what you changed afterwards, and what you'd watch in production. Skills England's 2026 assessment describes digital work moving “away from routine coding and testing tasks toward oversight, verification, judgement, and communication” [5]. An incident note is all four of those on one page.

The question this version answers

“Tell me about a time something broke.” Most candidates reach for a story from a job they haven't had yet. You'll have four, with graphs, from a system you own.

Question to sit with: do I know what breaks first in my own system?

v6 — Make it legible

You now have something most applicants don't, and it is still invisible unless you make it readable in ninety seconds. v6 adds no features. It turns the history into evidence other people can consume, in the four places they'll meet it.

The README — the arc, not the feature list

Problem → who it's for → the architecture now → the decisions (link the ADRs) → what it costs → what broke and what changed. Put the current diagram near the top. A reviewer should understand how you think before they decide whether to read the code.

The changelog — the part that proves growth

A dated list of versions with one line each: what changed and why. This is the single most undervalued file in a portfolio. It shows a project that was returned to, which is the behaviour employers say they can't find.

The CV bullet — one version, compressed

Pick the version with a number in it. “Cut processing cost 38% (£52→£32/month) by moving batch work to a queue with a scheduled consumer; documented the latency trade-off in an ADR.” One sentence containing a decision, a measurement and a consequence.

The interview story — the shape it needs

Situation, the constraint, the options, your choice, what it cost, what you'd change. You are not telling them what you built; you are walking them through a decision you already wrote down months ago.

Not sure which version your project is actually at?

The free capability check maps what you can demonstrate across the capabilities your target role needs — six levels, from understanding a thing to operating it at scale — and names the specific evidence that would move you up. It's the same ladder this guide climbs.

Put your old projects on trial

Before you start a new arc, be honest about the repositories you already have. Not to delete them in shame — one of them is probably a better seed than anything you'd invent this week. Take your best existing project and answer these about it, out loud:

Now score it. Tick only what your best existing project can show today, without you adding anything first — it saves as you go.

Tick what you can defend under questioning — it saves as you go.

Which of the seven trial questions was most uncomfortable to answer — and what's the smallest change that would fix it?

Question to sit with: is my best project a beginning, or a history?

The eight-week version of this

One system, two hours a few evenings a week. Tick as you go — the point is the sequence, not the speed.

What you'll deliberately NOT do

Start a second project because the first one got hard. Add a feature instead of a version. Pick a shinier stack to avoid a constraint. Write a README that lists technologies instead of decisions. Describe something as “production-ready” that has never had a bad day.

Five projects prove you can start. One project with six versions proves you can stay.

That is the whole argument. The market is full of people who can make something work — 110 applications reach a technology employer for every hire [1], and a great many of them link to a repository that stops at v1. The scarce candidate is the one whose project has a history: a decision they defended, a limit they designed inside, a night it broke and what they changed afterwards. You don't need five of those. You need one, returned to often enough that it grew up.

Want the version of this built around your target role?

Which project, which constraints, which evidence first — that depends on the role you're aiming at and what your CV already proves. That's the free Orientation Plan: a written, personalised plan, reviewed personally and delivered within 48 hours. No card required.

Last one. Which version are you building next, and by when?

Sources

Every figure above was checked against its primary source. Where a statistic comes from one country's respondents, the text says so.

[1]110 applications per hire at technology employers; 0.7% offer rate. SmartRecruiters, Technology Benchmark Recruiting Metrics 2025. smartrecruiters.com/resources/article/technology-benchmark-rverified
[2]140 applications per graduate vacancy, the highest in three decades of the survey. Institute of Student Employers, Student Recruitment Survey 2025. ise.org.uk/knowledge/insights/552/the_application_explosion_verified
[3]35% of organisations had at least one hard-to-fill AI vacancy; top reasons: lack of work experience (31%), insufficient technical skills (30%). DSIT, AI Labour Market Survey 2025. gov.uk/government/publications/ai-labour-market-survey-2025-verified
[4]91% of recruiters have spotted candidate deception. Greenhouse 2025 AI in Hiring Report (figure from the US sample). greenhouse.com/newsroom/an-ai-trust-crisis-70-of-hiring-manaverified
[5]Digital work shifting “away from routine coding and testing tasks towards oversight, assurance, judgement, and communication”. Skills England and the Department for Work and Pensions, Sector Skills Needs Assessment — Digital and Technologies (1 June 2026). A UK desk assessment of existing evidence, not a survey. gov.uk/government/publications/skills-england-annual-skills-verified

Want the plan we're describing here? Start with your free Orientation Plan — same three-tier grounding, same standard, no shortcuts.