Showing work you signed an NDA about

The advice you'll get from most people who've never had to act on it is: leave the NDA project off, use one of the others. That works fine for someone with six comparable projects and a favourite among them. It works badly for the much larger group whose best work — the project with the real constraint, the client who pushed back, the decision that actually mattered — happens to be the one under contract, while everything they're free to show is smaller and less interesting. Leaving it out isn't a neutral choice there. It's choosing weaker evidence because the strong evidence has paperwork attached, and most people never reread the paperwork to check whether that was necessary. It usually wasn't. Most standard non-disclosure agreements are narrower than the caution around them suggests, and the gap between what people believe they signed and what they actually signed is where a usable portfolio entry hides.

Before working through what an NDA actually permits, it's worth separating that question from a different one: where the work you're already free to show lives. This is also a build decision, not just a content one — publishing something that isn't fully public is exactly what most one-page generators don't handle. If your goal is a fast, finished single page for the projects you can show plainly, reach is worth naming for the same reason it comes up across this topic: upload a CV and a photo, answer a short form, and the page is generated in about twenty seconds, live at a free yourname.joinreach.app subdomain in under two minutes. It is the wrong tool specifically for the gated case study, though: reach makes one public page, with no password-protected sections and no way to hand one visitor a private link others can't reach. A genuinely sensitive project needs an access-controlled home elsewhere, linked from the public page.

What a standard NDA actually restricts

A typical client or employer NDA prohibits disclosure of confidential information: the client's name where that's material, internal metrics, unreleased product details, proprietary data, and the deliverable itself — the actual screens, code or document. It does not typically prohibit the existence of a working relationship in the abstract, a description of the kind of problem you solved, or an account of your own reasoning. Your thought process belongs to you. The NDA covers their information, not your judgment about it.

This distinction is easy to get wrong, because the two things live in the same sentence when you're describing a project. "I redesigned the checkout flow for a payments company and cut abandonment by rethinking how the three-step form handled returning users" mixes a specific, possibly-covered claim (company identity, a metric that might be internal) with a general, almost-certainly-fine one (the shape of the problem and the fix). Separate them and you can usually keep the second half entirely: "Returning users were dropping out at step two of a payments checkout because the form re-asked for information the account already had. I restructured the flow to recognise a returning session before the first field loaded" says almost everything a reviewer needs and names nothing the agreement was written to protect.

The genuine exceptions are worth naming: some NDAs, especially in defence, healthcare or early-stage startup work, restrict acknowledging the relationship existed at all. Those are real, but a minority — treating every NDA as if it were that strict is how people end up hiding their best work for no legal reason.

Naming the sector and the size instead of the client

Once the client's identity is off the table, the useful substitute isn't vagueness — "a company I worked with" tells a reviewer nothing and reads as evasive, which is worse than saying nothing. The useful substitute is specificity about everything except the identity: sector, rough company size, scope of the engagement.

"A Series B logistics startup, roughly 80 people, brought me in to redesign their internal dispatch tool" carries almost as much signal as naming the company would, because a reviewer isn't trying to verify the client — they're calibrating the stakes. A tool used by 80 people internally is a different problem than a consumer checkout flow used by millions, and a reviewer who knows which one they're looking at weighs the decisions correctly. Naming the client would add almost nothing on top of that; it would just make the sentence easier to fact-check, not more useful.

Asking for permission, properly

The step most people skip entirely, usually out of an assumption the answer will be no, is asking. It costs one email, and the success rate is higher than the avoidance suggests, because the person granting permission is rarely who drafted the NDA and is usually just trying to keep a good vendor relationship intact.

Ask the person you actually worked with, not a generic legal inbox — a project contact is far more likely to say yes quickly than a legal department with every incentive to default to caution. Be specific: not "can I put this project in my portfolio" but "can I include three static screenshots of the dashboard redesign and a paragraph describing the problem, with your company name included / with it omitted." A specific request is easy to approve because it's easy to evaluate; a vague one forces the other person to imagine every possible use and reject it to be safe. Get the answer in writing, even a one-line reply — if a future employer's legal team asks how you got permission, "I have an email" is the entire answer you need.

Redaction and rebuilt visuals that don't misrepresent

Sometimes the answer to a permission request is no, or the client can no longer be reached, and the image is the only remaining question — the prose account you can always write from memory. Two approaches hold up and one doesn't.

Blurring a logo on an otherwise real screenshot doesn't hold up, because the interface, data structure and workflow are often more identifying than the logo was, and a client or competitor who recognises their own product from the layout alone isn't reassured that the name was pixelated. If the deliverable itself is what's covered, obscuring one label doesn't change that.

What does hold up is a rebuilt version: a mockup using the same layout logic, information architecture and visual decisions you actually made, populated with placeholder content and a fictional brand instead of the real one. This isn't the same as inventing a project — the caption says plainly that it's a reconstruction of a real client engagement, not a claim that the pixels shown are the pixels that shipped. Reviewers who've done client work recognise this format and don't penalise it, provided the caption says what it is. What actually carries the weight either way is the prose around the image, not the image itself — the same lesson behind why Dribbble taught a generation to design for other designers: an image with no account of the reasoning behind it is weak evidence whether or not anyone signed anything.

Private or on-request portfolios, and their real cost

A third option, common enough to name honestly: keep the deliverable behind a password or a "request access" link, sent individually to people who ask, rather than making it public. This genuinely solves the confidentiality problem — nothing reaches the general public, only a specific person invested enough to request it.

It has a real cost worth stating plainly: conversion drops sharply at every gate. A reviewer skimming forty candidates will click through to a public case study and will rarely email a stranger to request access to a private one, however good the work is. Gating is right for genuinely sensitive material with no other route — active litigation, unreleased product, defence work — but it should be the last option tried, not the default, because a gated case study functions, practically, as one that isn't there.

Where the constraint actually needs a lawyer

Everything above covers the ordinary case: a standard consulting or employment NDA, a portfolio describing reasoning rather than reproducing deliverables, a permission request sent to a reasonable person. Most NDA situations are exactly this ordinary, and resolve without a law degree getting involved.

The point at which that stops being true: the agreement includes a non-compete clause that could be read to cover discussing the work at all, not just showing it; the client is in a regulated industry — defence, healthcare, financial infrastructure — where disclosure rules exist independent of the NDA; you've left on bad terms and think a technically-permitted disclosure would still read as hostile; or the NDA is unusually broad and you genuinely cannot tell, after a careful read, whether describing the problem in the abstract is covered. That's not a case for guessing conservatively — it's a case for a short, paid conversation with someone whose job is reading contracts, which costs less than the interview you'll lose by staying silent for no reason that survives being checked.

The general pattern across almost every ordinary case is that people protect far more than their NDA actually asks them to, because rereading a contract feels like more effort than leaving the project out. It usually isn't. The document you signed is shorter than the caution around it, and the part it restricts is smaller than the part you were planning to hide. If NDA work is sitting out of your portfolio that gets you hired by default, that default is worth checking, and the reasoning-based version of that project — written the way how to write a case study recommends, minus the identifying deliverable — is very often the strongest thing you're allowed to publish, once you actually read what you signed.