Building a portfolio when your production work cannot be shown
6 minute read. Updated 2026-08-08.
You can't fix confidentiality, so stop treating it as the obstacle. The real gap is evidence of judgement, and you can build that deliberately: an anonymised case study written around a decision point, one small original project that shows a mistake and the fix, and published scoping or evaluation templates. None of it touches a client's data, and all of it shows more than a generic public-dataset demo ever will.
Confidentiality explains why, not what to do about it
Every experienced AI contractor hits the same wall: the work that would prove your competence best is the work you're contractually barred from showing. What NDAs actually permit, and how to talk about restricted work in an interview, is worth understanding in its own right and is covered elsewhere. This is a narrower question: what to build on purpose so you have something to show at all.
The mistake is treating the absence of a demo as a fixed problem rather than a solvable one. You can't show the churn model you built for an insurer. You can build and show a smaller, honest piece of evidence that demonstrates the same judgement the real project required.
What not to build
A sentiment classifier trained on a public dataset, or a wrapper around an off-the-shelf model with a chat interface bolted on, proves you can follow a tutorial. Every hirer screening candidates has seen dozens of these, and they signal nothing about whether you'd catch a mislabelled column or push back on a brief the data can't actually support.
If you're going to spend hours building something for evidence, spend them on an artefact that shows a decision, not a demo. The difference is whether someone reading it learns how you think, or just that you can call an API.
Write the case study you can't screenshot
Take a real project, strip the client name, and change the numbers and the industry detail enough that nobody could identify it. Then write up the actual decision points: what the brief asked for, what you found when you looked at the data, what you recommended instead, and why. This is a written artefact, not code, and it's the closest thing to showing your production work that confidentiality actually allows.
Structure it around a disagreement or a course correction, since that's where judgement is visible. A write-up where everything goes to plan teaches a reader nothing. One that says the brief assumed clean labels and the data had 3 competing definitions, and here's how that changed the approach, teaches them exactly what they're trying to assess.
Build one thing from scratch, deliberately, to be shown
Pick a problem type you handle often, an evaluation harness for a language model, or a data quality check that catches the kind of silent drift that breaks models in production, and build a small, clean version specifically to be public. This isn't your client work in disguise; it's a fresh build with no confidentiality attached, sized to take days rather than weeks.
Include a mistake and the fix. A version history that shows you tried an approach, found it broke on an edge case, and changed it, is worth more to a hirer than a polished result with no visible history, because it's the only part of a portfolio piece that looks like real delivery rather than a rehearsed demo.
Publish the process, not just the output
The diagnostic template you use to scope a new engagement, the questions you always ask before quoting, the checklist you run before a model goes live, are all things you can share without touching a single client's data or code. They demonstrate exactly the judgement a hirer is trying to check for, with no confidentiality problem at all.
These documents also do double duty: they're the same artefacts that make a scoped, fixed-price proposal credible to a buyer, so building them for your portfolio and building them for your commercial process is the same piece of work done once.
Let references do what the portfolio can't
No amount of deliberate portfolio building replaces a referee who can describe your actual production work, even in general terms: what the problem was, roughly what you delivered, how you behaved when it went wrong. Where the work itself is invisible, the specificity of what a referee is willing to say becomes the strongest evidence you have.
Ask referees for concrete detail rather than a generic endorsement, and choose people who watched a real decision get made, not just people who liked working with you. That specificity is what a hirer weighs against everything else in your file, and it's the piece a public portfolio genuinely cannot provide.
What to do about it
- Don't spend build time on generic public-dataset demos; they prove nothing a hirer hasn't seen dozens of times.
- Write an anonymised case study built around a decision point, not a description of a happy path.
- Build one small, original project from scratch that shows a mistake and the fix, not just a polished result.
- Publish your scoping and evaluation templates; they show judgement without touching confidential material.
- Choose referees who'll describe a real decision, since specificity there covers what no portfolio can.
- Treat the process documents you build for clients and for your portfolio as the same piece of work.
Questions people also ask
Can I show client code if I strip out identifying details?
Not without checking your contract first. Most engagement agreements restrict use of the code itself, not just naming the client, and stripping comments doesn't change that. Assume the code is off-limits unless the contract or the client explicitly says otherwise, and build separate, original artefacts instead of trying to sanitise real work.
How long should a from-scratch portfolio project take?
Days, not weeks. If it's taking longer than a small paid diagnostic would, it's grown beyond what it needs to prove and is competing with billable time for no return. Keep the scope small enough that it's finished and public, since an unfinished, ambitious project shows less than a small, complete one.
Is it worth getting a portfolio piece peer reviewed before publishing it?
Yes, particularly by someone in the same specialism who'll say plainly if the evaluation or the analysis is thin. A portfolio piece with an obvious gap that a peer would have caught does more damage than not publishing at all, because it demonstrates the exact lack of scrutiny a hirer is trying to screen for.
What if none of my past work translates into a clean portfolio piece?
That's common in this kind of work and not a sign you've done nothing worth showing. Build something adjacent rather than derivative: if your production experience is mostly pipeline reliability, build and publish a small, honest example of the kind of check that catches silent failures, rather than trying to recreate the pipeline itself.
Where the figures come from
Every rate and salary quoted in this article is a median or percentile of figures advertised in UK job postings over the six months to 8 August 2026. They are not rates paid, and the gap widens at the top of a range.
- IT Jobs Watch, UK contract rates, 6 months to 8 August 2026, read 2026-08-08.
- IT Jobs Watch, UK permanent salaries, 6 months to 8 August 2026, read 2026-08-08.