How to Show Side Projects in Your Portfolio

A lot of people have side projects sitting in their files — a personal redesign, a browser extension, a photo series, a half-built app they actually shipped — and they do not know what to do with them when building their portfolio. Are they legitimate? Do clients care? Do they make you look like you have too much free time, or not enough client work?

The answer depends on what the project is, how you present it, and where you put it. Done well, side projects are often the most interesting part of a portfolio. Done poorly, they drag it down. Here is how to tell the difference.

When Side Projects Belong in Your Portfolio

Side projects earn their place in a portfolio when they demonstrate something your client work cannot — or when you do not have enough client work yet.

You want to show a skill you have not been hired for. If you are a developer who wants to take on more product design work, but none of your clients have asked for that, a well-executed personal project that shows that skill is a direct argument. It says: here is what I can do, regardless of whether I have been paid to do it yet.

Your client work is under NDA or cannot be shown publicly. This is common for agency work, enterprise software, and anything involving proprietary data. If large portions of your strongest work cannot be shown, side projects become your primary public evidence. They are not a fallback — they are the real portfolio.

You are early in your career. When you have fewer than three or four strong client projects, side projects fill the gap and demonstrate initiative that "I am still building my portfolio" does not. Every experienced freelancer started with personal projects before they had enough client work to be selective. Potential clients understand this and do not penalize it, as long as the work is genuinely good.

The project reveals your taste and interests. The best portfolios communicate not just capability but judgment — what problems you find worth solving, what aesthetic decisions you make when no client brief constrains you. A side project that you chose to build because you cared about it often communicates more about who you are than ten pieces of work delivered to someone else's specification.

Which Side Projects to Cut

Not every personal project is worth including. The same curation standard that applies to client work applies here: if the project does not represent the quality and direction of work you want to attract, leave it out.

Unfinished work. A half-built project documented incompletely sends the wrong message. Include it only if the incomplete state is clearly intentional and you can document what was built and why you stopped — an architectural pivot, a scope change you made deliberately. Otherwise, finish it first or skip it.

Projects that show skills you no longer want to use. If you spent three years doing logo design and have moved into UX, including old logo work is a mistake even if it is good. The portfolio should point forward, not backward.

Projects built purely to fill space. There is a version of a portfolio side project that is obviously performative — a quick redesign of a famous app, a spec ad for a brand that did not ask for one. These are fine as practice, but they are often recognizable as exercises rather than genuine problems solved. If a project exists mainly to show range rather than to solve something you actually cared about, experienced clients will sense that.

How to Frame Side Projects Honestly

The most common mistake people make with side projects: pretending they are client work, or apologizing for the fact that they are not.

Label them accurately. "Personal Project," "Self-Initiated," or "Side Project" are all fine. You do not need to invent a fake client name or use vague language to obscure the fact that you defined the brief yourself. Experienced clients see through this immediately, and it erodes trust in everything else on the page.

At the same time, do not lead with a disclaimer. A project description that opens with "This was just a personal project I did for fun" is doing the work of talking the client out of being impressed before they have seen anything. State what the project is, not what it is not.

The framing that works: describe the problem as you saw it, explain the decisions you made, and show the result. The fact that you defined the problem yourself is not a weakness — it demonstrates that you have initiative, taste, and enough intellectual curiosity to spend your own time building things.

Writing the Project Description

Side project descriptions follow the same structure as client work: a problem, an approach, an outcome. The only difference is that you defined the problem yourself, so you need to be clear about what prompted it.

A few things that make the description work:

State the actual problem. Not "I wanted to practice React" — that is about you, not the project. "I built this because every todo app I tried had the same pacing flaw for long lists" is about a genuine observation. One sentence of honest context is all you need.

Explain the significant decisions. What trade-offs did you make? What did you try first that did not work? Process documentation is what separates a screenshot from a case study. Even a short paragraph describing a key decision communicates more than a polished finished image alone.

Be specific about outcomes. If the project shipped and has users, include that. If it lives on GitHub and has stars or forks, include that. If it was a personal experiment with no external validation, say what you learned or what you would change. Specificity is honest; vagueness sounds like you are hiding something.

For a full breakdown of how to write project descriptions across disciplines, read Portfolio Project Description Examples — the same structure applies directly to personal work.

Where to Position Side Projects in Your Portfolio

Side projects should almost never lead. If you have three strong client projects and two personal ones, the client work goes first. Potential clients and hiring managers weight paid work more heavily, and first impressions are set by whatever they see in the first thirty seconds.

The best position for side projects is after your primary work — often as a clearly labeled section lower on the page, or as a secondary project type within a mixed gallery. Some portfolios handle this with a filter or tab that separates "client work" from "personal work." That is cleaner than mixing them without context.

One or two side projects is usually the right number. More than three suggests either that you are early in your career or that you prefer building for yourself over client work — both of which carry implications you want to manage deliberately. For broader guidance on how many projects to include and in what order, read How to Organize Your Portfolio Projects.

Making Side Projects Look as Polished as Client Work

The fastest way to undermine a personal project is presenting it at a lower visual standard than your client work. If your client case studies have clean mockups and thoughtful documentation, your side project should too.

Invest in the presentation the same way you would for paid work. High-quality screenshots, proper device mockups if relevant, clean documentation, and a consistent level of writing in the description. If the project is code-based and lives on GitHub, link to the repository and mention anything notable — stars, contributions, community interest.

For designers: Dribbble and Behance are useful references for how strong practitioners present personal and passion projects. Browse work tagged as "self-initiated" — the gap between polished and unpolished personal work is obvious, and it recalibrates your baseline quickly.

---

The people who include side projects well treat them like any other portfolio piece: curated deliberately, described honestly, and presented at the same standard as everything else. The project being personal is not the issue — the only issue is whether it demonstrates the quality and direction of work you want to be known for. If it does, it belongs. If it does not, cut it and build something better.

If you are pulling together your first portfolio and most of what you have is personal work, read How to Build a Portfolio Website When You Have No Experience — it covers how to structure a portfolio when client work is limited and how to present what you have with confidence.

mnml.page makes it straightforward to mix client and personal projects in a single clean layout — organized the way you want, without requiring any code to set up.

Tools & Resources

• GitHub — The default platform for hosting and sharing open-source side projects. If your project is code-based, link to the repository directly in your portfolio. Public repos with a README that explains the project serve as lightweight case studies in themselves.

• Dribbble — Useful for seeing how working designers present self-initiated and personal projects. Browse work tagged "self-initiated" to calibrate what a well-presented personal project looks like versus a rough one.

• Behance — Adobe's portfolio platform with strong process-documentation culture. Side projects presented here often include detailed process breakdowns — a good reference for how much context is enough when describing personal work.

• Product Hunt — If your side project has shipped and has users, consider listing it on Product Hunt. Community traction (upvotes, comments, reviews) is external validation you can reference in your portfolio to show that the project was real and resonated.

• mnml.page for Developers — Minimal portfolio builder with a block-based editor. Lets you create a clean mixed portfolio of client and side projects without needing to write or maintain any code.