Working Under NDA as a Freelance Engineer: What You Can Show and What You Cannot

The freelancer's portfolio problem

The better the client, the less likely you can show the work. Serious companies put an NDA in front of you before the kickoff call, and the app you spent six months on becomes something you legally cannot screenshot.

Meanwhile every prospective client asks the same question: *what have you built?*

I have shipped several projects I cannot name, including a React Native app currently live in both stores for a private client. Here is how I handle it without either lying or leaking.

Read the NDA for these four things

Most NDAs are boilerplate and fine. Four clauses are worth actually reading:

1. What counts as confidential. Good NDAs define it — code, designs, business plans, customer data. Loose ones say "all information relating to the Company", which technically includes the fact that you worked there. Ask for the definition to be narrowed to information marked or reasonably understood as confidential.

2. Duration. Two to five years is normal. Perpetual confidentiality for ordinary product information is unusual, though it is standard and reasonable for genuine trade secrets.

3. Whether you can name the client. This is the big one for freelancers, and it is negotiable far more often than people assume. Ask directly, before signing: *"Can I list you as a client by name, with no project details?"* Many say yes. Some say yes after launch. Getting this in writing up front costs one email; asking two years later is awkward and usually gets a no by default.

4. IP assignment and reusable components. If you assign all IP, make sure there is a carve-out letting you keep generic, reusable code — your own utility library, your project boilerplate, patterns you had before the engagement. Without it, you have technically signed away the toolkit you use on every project.

What you can usually talk about

Even under a strict NDA, these are normally safe — but confirm against your specific agreement:

What you cannot show: screenshots, the name, the code, the designs, customer data, and anything that lets someone identify the client by triangulation. That last one catches people out — industry plus city plus team size plus timeline can identify a company as precisely as naming it.

How to present it in a portfolio

The instinct is to leave NDA work out entirely. That is the wrong call — it makes your portfolio look thinner than your actual experience.

Give it a card like any other project, and be explicit about why there is no link:

Blurring a real screenshot is a bad idea. Blurs can be reversed, and even when they are not, you have published the layout, the navigation structure, and the branding shape. Use something you drew yourself.

Stating the constraint openly reads as professional. A client evaluating you *is* imagining their own project on that page — seeing that you take another client's confidentiality seriously is a selling point, not a gap.

Keeping proof of work, legitimately

You still need to demonstrate competence to future clients:

That last one is the workhorse. "I can walk you through the architecture on a call" converts better than a gallery, because it becomes a technical conversation instead of a slideshow.

Things I do not do

None of this is legal advice — I am an engineer, and jurisdictions differ. For anything with real money attached, have a lawyer read the agreement.

The reframe

Early on, NDA work felt like wasted portfolio material. It is the opposite: the clients who make you sign one are usually the clients who pay properly and stay for years.

Present the constraint honestly, show the engineering rather than the product, and let the depth of what you *can* discuss do the work. Prospects who ask sharp technical questions about an NDA project tend to convert better than ones who just scroll a gallery of screenshots.