Client work can be strange when you are trying to show what you can do. The best projects are often the ones you cannot talk about directly. They have real users, real pressure, messy requirements, and enough business context to make the engineering decisions interesting.
The mistake is trying to force confidential work into a portfolio anyway. That usually produces a vague case study that says nothing useful, or it leaks details that should have stayed private. Neither option is worth it.
I prefer a cleaner approach: show the shape of the skill, not the private artifact.
If a project taught me how to reason about workflows, I can write about workflow design in general. If it pushed me into data modeling, I can build a small public example that demonstrates the same tradeoff. If the hard part was deployment, I can explain the deployment checklist without naming the company or describing their internal systems.
That still gives a reader useful evidence. They can see how I think. They can see whether I care about maintainability. They can see if I understand product constraints. They do not need screenshots from a private dashboard to learn those things.
Public work also creates a healthier record. A repo, a tiny demo, a blog post, or a cleaned-up experiment can say: this is how I solve problems when there is no confidential context attached.
The portfolio version of this is simple:
- keep private client names private
- use public repos and public demos where possible
- write about patterns, not protected implementation details
- describe outcomes carefully without inventing numbers
- show taste through the page itself
The strongest proof is not always a logo wall. Sometimes it is a small public project with readable code, a thoughtful post, and a clear explanation of the tradeoffs.