Your portfolio often gets harder to build at exactly the point your work gets more serious.

A small client may be happy for you to publish the finished website, dashboard or campaign. A larger company may give you access to internal systems, customer data, unreleased products, commercial numbers or proprietary processes, then require you to keep them confidential.

A few projects later, you have an awkward problem: your strongest work is missing from your portfolio.

That does not automatically mean the project must disappear from your professional story. It means you need to separate two questions:

1. What are you legally and contractually allowed to disclose?

2. Within that boundary, how can you still prove what you contributed?

The first question comes before the second.

Anonymizing a client name, blurring a screenshot or putting a case study behind a password does not automatically make disclosure permitted. Your NDA, service agreement, employment agreement, statement of work, client policies and any later written permission determine what you can use.

This guide is general educational information, not legal advice. If the wording of an agreement is unclear or the consequences of disclosure are significant, get qualified advice on that specific agreement.

If you are working on your broader portfolio strategy, the existing walllet.com guides cover how to structure a strong freelance UX portfolio, choose credible data analyst portfolio projects, and present your experience when looking for software development clients and contracts. This guide deals with the harder case: what to do when the work that proves your ability cannot simply be published.

Can you put NDA work in your portfolio?

Sometimes, but there is no universal yes.

An NDA is a contract that can define what counts as confidential information, how that information may be used, whether it may be disclosed to third parties, how long confidentiality obligations last and what exceptions apply. The World Intellectual Property Organization specifically notes that NDAs may regulate access, use and disclosure, and that confidential information can include software, designs, customer lists, business plans and financial information. 

That makes the actual wording of your agreement more important than a generic rule such as “just remove the client name.”

A useful default is:

If the agreement does not clearly allow portfolio use, do not assume that changing or hiding identifying details creates permission. Check the agreement and, where appropriate, obtain written approval first.

The UK Intellectual Property Office gives similar practical guidance: an NDA is a legal agreement used to control disclosure of confidential information, and the permitted purpose of disclosure matters.

Anonymizing the client is not the same as getting permission

Suppose you worked on an unreleased financial product. You remove the company name and write:

I redesigned onboarding for a fast-growing West African fintech with more than 500,000 customers.

You have not named the company. But the combination of industry, geography, scale, project type and timing may still make the client obvious. The same problem can happen when you remove a logo but keep:

• an identifiable interface;

• a unique product feature;

• exact revenue or conversion figures;

• internal terminology;

• employee names;

• customer records;

• repository or architecture details;

• a quote from a private Slack conversation;

• launch dates that identify an unreleased product.

Anonymization reduces identifying information. It does not change the permissions in your contract. There is also a practical “mosaic” problem: several individually vague details can become identifying when combined.

Start with the contract, not the portfolio design

Before writing an anonymized case study, review every agreement that may apply to the project. Look for provisions covering:

1. The definition of “Confidential Information”

2. Publicity, marketing or portfolio rights

3. Use of the client’s name and logo

4. Intellectual-property ownership

5. Screenshots, prototypes, code, documents and data

6. Disclosure to third parties

7. Information already in the public domain

8. Confidentiality after the project ends

9. Any review or approval process before publication

Do not stop at the document titled “NDA.” Your master services agreement, employment contract, statement of work or client handbook may contain separate confidentiality or publicity clauses.

A project becoming public does not automatically cancel every restriction either. The product may have launched while research, internal metrics, source files, commercial terms or your access to them remain confidential.

Ask for permission before you anonymize and publish

If the agreement does not give you clear portfolio rights, the cleanest route is often a specific written request.

Avoid: “Can I put this project in my portfolio?”

That leaves too much undefined. Tell the client exactly what you want to disclose. For example:

Subject: Portfolio permission for [project]

Hi [Name], I’d like to create a limited portfolio case study based on my work on [project].

I would like to show my role, a high-level description of the problem, the process I used and selected outcomes. I would not publish confidential product data, customer information, internal documents or original screenshots.

Where visuals are useful, I can create new mockups with fictional data rather than reuse project files.

I can send the exact case study for approval before anything is published. Please let me know which details, if any, you are comfortable approving for public use.

If the client approves only part of the request, treat that approval literally. Permission to mention the company is not necessarily permission to show its product screens. Permission to show a screenshot is not necessarily permission to disclose performance data.

Keep the written approval with the project records.

What if the client says no?

Then the answer is no for the material they have not authorized. Do not try to outsmart a confidentiality restriction with heavier blurring, a private Notion link or a password-protected PDF.

Instead, move the proof one level away from the confidential material. You can build evidence around your capability rather than publishing the protected project itself.

Build the case study around what you did, not what the client owns

A useful confidential case study can still answer the questions a serious prospect cares about:

• What kind of problem were you responsible for?

• What was your role?

• What decisions did you make?

• What constraints did you work under?

• How did you approach the problem?

• What did you deliver?

• How did you collaborate?

• What changed because of your work, if the outcome can be disclosed?

• What would you do differently now?

The final client artifact is only one form of proof. Your reasoning can be proof too.

For a UX designer, that may mean explaining how you mapped a complicated workflow, chose research methods and tested competing solutions without showing the real interface.

For a developer, it may mean explaining the architecture decision, failure condition or trade-off without publishing proprietary source code.

For a data analyst, it may mean showing how you framed a business question, validated data and designed a decision-making workflow using a synthetic dataset rather than the client’s actual records.

For a marketer, it may mean explaining the campaign structure, experimentation logic and measurement approach without revealing the company, ad account, audience data or commercially sensitive numbers.

The useful specificity should live in your decisions, not in confidential details.

Replace restricted evidence instead of deleting all the detail

The worst anonymized case studies become so vague that they prove almost nothing: “Worked with a leading company to improve the user experience and achieve strong results.”

A prospective client cannot tell what you did. A stronger case study preserves the professional substance while replacing restricted evidence.

The qualification in the second column matters.

A recreated screen is not automatically safe merely because you drew it again. If it reproduces a confidential design, unreleased workflow or protected information, recreating it does not solve the disclosure problem.

The same applies to synthetic data. Synthetic numbers are useful when you want to demonstrate an analytical method without exposing the real dataset. They should not be used to reconstruct confidential business information in a slightly altered form.

Make synthetic work visibly synthetic

Do not let a prospect mistake a rebuilt artifact for the client’s actual deliverable. Label it clearly:

Recreated portfolio visual using fictional data. Original client material is confidential.

That sentence does two jobs. It explains why the real artifact is absent and prevents you from overstating what the viewer is seeing. It can also increase trust. You are showing that you understand professional confidentiality instead of treating it as an inconvenience.

Use ranges only when the number itself can be disclosed

Changing $4.7 million to $4–5 million is not a loophole.

Neither is changing 38.7% to “around 40%.”

If performance data is confidential, rounding it does not automatically make it publishable. Ranges are useful after you establish that some form of the result may be disclosed. For example, a client may approve:

Reduced processing time by more than 20%

while declining to approve the exact internal measurement. That is a permission decision, not an anonymization trick.

Watch for details that identify the client indirectly

“Confidential SaaS client” may be sufficiently broad in one situation. “Series B healthcare SaaS company in Lagos serving 43 hospitals” may identify the company almost as clearly as its name. The same applies to:

• exact team size;

• exact project budget;

• unusual technology stacks;

• specific countries or cities;

• distinctive customer types;

• exact launch dates;

• funding stage;

• unusually precise project duration;

• named competitors;

• unique internal problems.

When you anonymize, review the whole case study as one information set rather than checking each sentence independently. Your portfolio should make your capability easier to identify, not the confidential client. Your portfolio proves the work. See how walllet.com fits the money side of international freelance work in Nigeria.

Public portfolio, private walkthrough and proof of income are three different things

This distinction matters because “I won’t put it on my website” is not the same as “I can disclose it.”

A recruiter seeing a password-protected case study is still a third party.

A prospective client seeing a private Figma file is still receiving information.

“Private” can reduce public exposure. It does not automatically create a contractual exception.

This is also why portfolio proof should not be mixed with financial evidence. Contracts, invoices, payer records and receiving statements may help establish the source of freelance income, but they usually do not belong on a public portfolio. The walllet.com guide to proof of income, proof of funds and source of funds for Nigerian freelancers covers that evidence separately.

Once a project moves from proposal to paid engagement, the administrative side matters too. The international client payment workflow for freelancers in Nigeria covers the receiving side rather than the portfolio side.

What supporting evidence can you use?

A confidential case study does not have to carry the full burden of proving your experience. Depending on what the client permits, supporting evidence can include:

A client recommendation

A short recommendation about your role, reliability or skill can establish credibility without revealing the project. Get permission before publishing the person’s name, employer or quote.

A reference

You may be able to tell a prospect that references are available at a later stage. Do not give out a client’s contact information without consent.

Public information

If the company has publicly announced the product, you can point to that public source where appropriate. But public availability of one fact does not automatically authorize you to disclose everything you learned while working on the project.

A sanitized contract excerpt

In some private verification situations, a carefully redacted contract may establish your role or relationship. That does not make the contract portfolio material. Check the agreement before sharing even a redacted excerpt.

An invoice or payment record

These can support proof of professional activity or income where legitimately required. They should be treated as financial evidence, not as attractive portfolio assets. Redact information that the recipient does not need and use an appropriate secure channel.

Seven mistakes that can turn an NDA portfolio into a confidentiality problem

1. Publishing first and asking later

Once confidential information is public, removing the page does not undo the disclosure. Get the boundary right before publication.

2. Assuming “anonymous” means permitted

Removing a company name may not remove confidential information or make the company unidentifiable.

3. Blurring a real screenshot

A blurred screenshot can still reveal the interface, layout, workflow, branding, product category or information the client never approved for publication. A genuinely rebuilt demonstration artifact is usually a cleaner portfolio technique, provided the concept you are demonstrating can itself be disclosed.

4. Keeping exact numbers because “they make the case study stronger”

Exact internal metrics can be commercially sensitive. Strong evidence is not worth a contractual breach.

5. Making the anonymized description too specific

Industry + location + scale + product + date can become a client name without ever stating one.

6. Assuming a private deck is outside the NDA

A private audience is still an audience. Check whether disclosure to that person is allowed.

7. Uploading invoices or contracts as proof that the project was real

Financial or contractual evidence has a different purpose. Keep it out of the public portfolio.

A reusable confidential case-study structure

You do not need a special writing style for an NDA project. You need a structure that proves competence without relying on protected material.

Project

Confidential [project type or broad category, only if permitted]

Add one sentence explaining the limitation:

Client identity and original project materials are confidential. This case study covers my role and working process using recreated examples.

My role

State exactly what you owned. For example:

I led UX research and interaction design for the onboarding portion of the project, from workflow mapping through prototype validation and developer handoff.

That is much stronger than:

I helped with UX.

The problem

Describe the shape of the problem without revealing protected facts. For example:

The workflow required new users to complete several dependent steps before reaching the main product.

If even that information is confidential, move up another level of abstraction.

Constraints

Explain the professional constraints that affected your decisions:

• legacy systems;

• tight delivery window;

• cross-functional dependencies;

• accessibility requirements;

• incomplete data;

• complex approval processes;

• technical limitations.

Only include constraints you are permitted to disclose.

Process

Show how you worked:

1. How you diagnosed the problem

2. What information you needed

3. What alternatives you considered

4. Why you rejected some options

5. How you tested or validated the decision

6. How you handed the work over

This is often where seniority becomes visible.

Portfolio visuals

Use explicitly labeled rebuilt or synthetic material where permitted. For example:

The following workflow is a simplified reconstruction created for this portfolio. Names, values and interface elements are fictional.

Outcome

Use only the level of result the agreement or client approval permits. That could be:

• an exact metric;

• an approved range;

• a directional result;

• a qualitative outcome;

• or no result at all.

If you cannot share the result, say so.

Business performance data is confidential, so this case study does not include outcome metrics.

A clear omission is more credible than a suspiciously vague success claim.

What I learned

This is your professional reflection, but it should not reveal confidential project information. Explain how the project changed your approach to similar problems.

Example: turning a confidential project into a useful case study

Weak version: I worked for a major fintech company on a confidential redesign that increased conversion significantly. I cannot share more because of NDA.

There is almost nothing a client can evaluate. A stronger version, assuming each detail has been cleared for disclosure:

I worked as the product designer on a confidential B2B onboarding project. My responsibility covered workflow mapping, prototype design, usability testing and engineering handoff.

The main design challenge was reducing unnecessary decisions in a multi-step setup process without removing required checks.

I compared three flow structures, tested the two strongest directions and documented the final interaction logic for implementation.

The original interface and research data are confidential. The diagrams below are portfolio reconstructions using fictional names and values.

Client identity, live product screens and performance figures are omitted under the confidentiality agreement.

The second version proves much more without pretending to show things that remain private.

Build portfolio rights into future contracts

Confidentiality becomes easier to manage when portfolio use is discussed before the project starts. For future freelance contracts, consider discussing whether you may:

• name the client after launch;

• use the client’s logo;

• display final public work;

• create an anonymized case study;

• describe your role and process;

• use approved performance ranges;

• publish a testimonial;

• submit the final case study for client review before publication.

Do not copy a generic portfolio clause from the internet and assume it works everywhere. Contract law, intellectual-property rights and confidentiality obligations depend on the agreement and applicable jurisdiction. The useful operational point is simpler: negotiate the issue before you need the portfolio piece.

What if you cannot disclose anything about the project?

Build separate proof.

Create a self-directed project that demonstrates the same skill without recreating the client’s confidential work.

If the private project required you to design a complex permissions system, build a new fictional permissions problem.

If you analyzed retention data, create a fresh dataset and demonstrate the analytical method on that.

If you designed an internal operations dashboard, invent a different business and build a new dashboard from scratch.

If you solved an infrastructure problem, create a technical example that demonstrates the engineering principle without reproducing the client architecture.

The goal is not to disguise client work as a personal project.

The goal is to demonstrate the capability independently.

That distinction protects both your credibility and the client’s information.

Legal references

The legal framework in this guide is based primarily on the World Intellectual Property Organization’s guidance on confidential information, trade secrets and contractual confidentiality, together with the UK Intellectual Property Office’s practical NDA guidance. Specific contractual rights and remedies depend on the agreement and applicable law.

Keep confidential work confidential without letting the rest of your freelance operation become harder than it needs to be. Explore how walllet.com fits into managing international freelance income in Nigeria.