Build an AI portfolio that lands you a job, in 10 steps

If you want to move into AI from another profession, you know the problem: every job ad wants experience, and you only get experience with a job. You don't break out of that loop by collecting yet another certificate. You break out by showing something finished. Nobody asks an applicant with three clean projects about their degree. That's exactly what this is about. We're not building one big thing, we're building three small things that work and that someone can understand in two minutes. Set aside a quiet afternoon for it, the rest happens on the side over the coming weeks.

Step 1: Decide on a problem you actually know

The most common mistake is that people want to build the project that impresses. A chatbot for the stock market, an app that detects cancer, something big. That never gets finished, because you don't know the field and get stuck at every corner.

Instead, take a problem from your old job or your everyday life. You worked in retail? Build a tool that writes product descriptions from keywords. You worked at a law firm? Build something that boils long contracts down to three sentences. The advantage is twofold: you immediately know whether the result is good, and in the interview you can explain why the problem is real. That's worth more than any technical sophistication.

Write down in one sentence who the tool makes happy and what it takes off their plate. If you can't get that sentence out, the problem is too vague. Then find a more concrete one.

Step 2: Pick one tool and stick with it

There are too many tools, and every week a new one shows up that supposedly does everything better. Ignore that. For your first portfolio, one single tool you feel comfortable with is enough. If you can't code at all, start with a no-code approach; for that we have the playbook Claude Projects for non-coders. If you're slowly warming up to code, an AI assistant in the editor is the gentlest way in.

The point isn't which tool, it's that you don't switch midway. Every switch costs you half a day of relearning, and in that time you build nothing. I've seen people compare tools for three months and end up with not a single project.

Note down which tool you pick and why. You'll tell that story later in the interview, and "I deliberately chose one instead of trying everything" sounds like someone who delivers.

Step 3: Build the smallest version that works

Your first version should be ugly and do exactly one thing. No login, no pretty interface, no settings. If your tool summarizes contracts, then the first version takes exactly one contract and spits out exactly one summary. Done.

The reason is psychological. A finished small thing gives you momentum for the next one. A half-finished big thing drags you down until you give up. Aim to have the smallest version running in a single afternoon. If that doesn't work out, the version is still too big.

Once this mini version runs through once, you've proven the idea holds up. Everything after that is improving, and improving is easy. The jump from zero to one is the hard one.

Step 4: Put everything in a Git repo

As soon as something runs, it goes into a Git repository. Not later, now. Git is the language developers use to talk about work, and a public repo is proof that you really built something. Anyone can fake a screenshot, nobody fakes a commit history.

If Git is new territory for you, work through the playbook Git for AI quickstart first, it gets you up to speed in half an hour. The three lessons Git for AI in the first level go deeper, if you want to really understand it instead of just typing out commands.

Commit often and with honest messages. "First version that runs through" is a better commit message than "update". The history tells your story later, and a history with readable steps comes across like someone who knows what they're doing.

Step 5: Write a README a human understands

The README is the first file a recruiter or developer opens. Usually it's also the only one. Treat it like the front page of your project, not like a chore.

It needs four things in this order: what the tool does in one sentence. Who it's for. How to start it. A picture or a short example of the result. Not a dissertation, half a screen is enough. Write it so your mother understands what the thing does. If she understands it, so does the stressed recruiter clicking through fifty applications in the evening.

Avoid jargon where you can. "Summarizes contracts" is better than "uses a large language model for semantic compression". The first shows you understand the user, the second that you learned a word.

Step 6: Document what went wrong, not just the success

This is the step almost everyone skips, and it's exactly the one that sets you apart. Write in your README or a short notes section what didn't work while building and how you solved it. The AI hallucinated and invented contract clauses? Write down how you caught that. The tool was too slow? Write down what you changed.

Why this works: anyone can rebuild a tutorial. But someone who can describe where it got stuck really worked and didn't just copy. In the interview, "tell me about a problem you solved" is the most common question, and you've already written the answer down.

Two or three honest stumbling points per project are enough. That's not a weakness, it's proof that you worked under real conditions.

Step 7: Make the project visible

A repo with code is good, but most readers want to see the result without starting anything themselves. Give them that. If it's a web app, put it online; many simple hosting services cost nothing for small projects. If that's too much, record a short screen video where you use the tool for two minutes.

A visible result lowers the barrier for the viewer to zero. They don't have to install anything, understand anything, they simply see that it works. Those two minutes of effort from you spare the other person the decision of whether to even click in.

If your project is a small website and you want search engines and AI assistants to find it at all, the playbook GEO for small sites helps you with the finishing touch.

Step 8: Write a short companion post

Every project deserves a short text where you tell why you built it and what you learned along the way. Three to five paragraphs, no more. You can post it on LinkedIn, in a blog, or just drop it as a file in the repo.

This post is worth gold, because it shows two things at once: that you can build and that you can talk about it. The second skill is often more important on the job than the first. A developer who can explain their work is worth more on the team than a silent genius coder.

Write it in your own voice, not in marketing tone. "I built this because in my old job it annoyed me that..." is a better opening than "In today's fast-paced world of AI...". Real beats slick.

Step 9: Collect three projects, not thirty

Stop when you have three solid projects. I mean that seriously. Three things that work, are documented and are visible beat twenty half-finished experiments. A full profile of nothing but ruins looks like someone who finishes nothing.

Choose the three so they show different skills. One that solves an everyday problem, one that works with data or text, one that does something creative. That way you cover a range without spreading yourself thin. If you absolutely must keep building, improve one of the three instead of starting a fourth.

Quality over quantity isn't a platitude here. The viewer has ten minutes, not ten hours. In ten minutes they get through three good projects; with thirty they close up after the second ruin.

Step 10: Link everything in one place

Finally, you need a single address you can put in every application. That can be a plain portfolio page, a tidy Git profile, or a single document with three links and two sentences of explanation each. The main thing is that it's one place instead of five.

The recruiter shouldn't have to search. One address, click, click, click, and they've seen your three best things. Every extra hurdle costs you applicant attention, and you only have it for seconds.

Put this one address right at the top of your CV, directly under your name. Not hidden between the hobbies. The portfolio is your strongest argument, so put it where it's seen immediately.

What comes next

You now have three projects, documented and visible. The next step is to bring them into your CV and interview in a way that actually lands. For that, continue with the playbook Proving your AI skills credibly in CV and interview. If you notice you're missing the technical basics while building, Level 1 is the calm starting point that picks you up with no prior knowledge.