If you already know what your portfolio needs to show, and to whom, that's great, read on! If not, take a look at part 1 which asks the questions you need to think about before writing a line of code.

Choose Your Solution

It will probably seem a bit counter-intuitive thinking about the solution rather than the problem - most portfolio advice first tells you to find a problem to solve. But what if the problem you find requires a solution using knowledge and skills that don't match with what your portfolio needs to show?

If you have an idea of the kind of solution you want to build, then it makes it easier to find a problem that will fit that solution. For example, I wanted to demonstrate proficiency specifically with React. For me, this meant that the solution would be primarily front end focused, using an existing API or mock data to avoid spending time setting up a full stack.

Start off with an idea of the shape of the solution - full stack, frontend/backend, the specific technology or skills you want to showcase - then start looking for problems to solve.

Finding a Problem to Solve

Even with the shape of the solution decided, this is still the part I find hardest. Knowing that I want to build something frontend-heavy in React doesn't tell me what. It narrows things down a bit, but it's still a blank page taunting me.

The most important thing for me is to find a problem that genuinely interests me. The only thing motivating me is me. Whether I'm truly invested in the solution, or the process itself excites me, there needs to be a hook that keeps me coming back.

Try to start with something you personally want solved. This is the hardest one to find. There are a lot of creative and talented people out there who may have already solved your pain point, and it's hard to find motivation when you know there's a solution already. But if there's a headache in your own life that your chosen stack could fix, give it a go.

If there isn't, try to reverse-engineer something you already use. You already understand the shape of the problem, because you're a user of the existing solution. You know what it does badly, what's missing, what you'd change if you built it yourself. Look at the features you use most, and start there - the ability to take something big and break it down into what actually matters is a skill in itself, and one that shows up more the further along you get. You're not trying to out-build the original. You're proving you understand the problem well enough to solve it your own way.

If you're still stuck, solve someone else's problem that catches your interest. This is the option most portfolio advice defaults to straight away, and it works, but only if the interest is genuine. If it's a common problem, add a twist that makes it stand out, and shows you didn't copy someone else's homework. Avoid picking a problem purely because it sounds like a good portfolio. That's how you end up with something technically competent that proves nothing.

Tried all of the above and still staring at a blank page? That's completely normal, you're not alone. Good teams don't put all the decisions on a single person, and there's no reason your brainstorming process should either. Talk it through with a colleague, a friend, or even AI. I've had useful results by asking AI to interview me about my hobbies and interests, then suggest problems in that space I might want to solve. It doesn't hand you the idea. It asks the questions you might not have thought to ask yourself.

Perfection Is the Enemy of Action

I've talked about how important it is to stop and think before jumping straight in to writing code, but at some point, you have to stop planning and start building.

When you know that someone else will be looking at your work, it's hard to resist the urge to curate that view. You only want them to see the perfect version of the developer you are. But that's not how it works in the real world. A project that shows how you can refine a solution as you go along demonstrates a lot more than one that looks perfect first time.

You don't need the perfect solution. You need a solution - something built, something that works, something you can point at and talk about in an interview. A finished, modest project beats an ambitious one that's still 60% done six months later. Even a partially functional project with a roadmap is more valuable than a project you never started.

Perhaps you'll encounter problems along the way that you don't know how to solve the “right” way yet. Acknowledge the knowledge gap, do it the “wrong” way, and add a comment to come back to it. This happens more than you think in real projects, technical debt is everywhere! An intentional choice to defer an architecture decision to keep momentum going shows more than a stalled project.

Something Is Better Than Nothing

I've focused here on a code-based project, because for most that's the most direct way to prove you can do the job. But maybe your specialisation is in building AI agents, technical documentation and training, big data and analytics - there are so many more roles in the sector than there used to be.

Pick the format that makes sense, but the lessons still apply - think about what you need to demonstrate, envision the shape of the solution, and find a problem that fits. Don't wait for the idea to be perfect, the stack to be exactly right, or the timing to feel ready.

A finished, honest, slightly rough project beats a perfect one that only exists in your head.