How to Build Your First AI Project

Finished beats impressive

The most common way a first portfolio project fails is not that it was too hard. It is that it was too big, and it is still sitting half built in a folder six weeks later while you apply for jobs with nothing to show.

An unfinished ambitious project is worth nothing to a reader. A small finished one is worth a great deal, because it can be opened, understood and questioned. So scope it smaller than feels impressive. Then, if you still have energy afterwards, extend it. That order matters. Almost nobody manages it the other way round.

One workflow, start to finish

Pick one workflow. Not a platform, not a suite of tools, not a thing that could grow into a business. One task, from the moment it starts to the moment it produces something usable.

If your problem is drafting weekly parent updates, version one takes a list of notes and produces draft letters. It does not have a login screen. It does not store anything. It does not handle the edge case where a parent has changed address. It does the main path, all the way through, and stops.

The end-to-end part is what makes it evidence. Half a workflow polished to a shine tells the reader nothing about whether you can make something actually work.

Write down what done means, before you build

This is the step people skip, and skipping it is why projects never end. Without a written definition of done, you are relying on a feeling, and the feeling never arrives, because there is always one more thing you could improve.

So define it in advance, in writing, in a form you can test.

Here is the project I want to build for my portfolio: [describe it in a few sentences].
Help me scope version one so it can be finished in about ten hours by one person.
Give me:

A definition of done written as three to five checks I can tick, each one testable
A list of things I should deliberately leave OUT of version one
The single riskiest part, meaning the part most likely to eat all my time
Be strict. Assume I will underestimate how long everything takes.

Keep that list somewhere you will see it. When you get the urge to add a feature, look at the out list. If your new idea is on it, you already decided.

Building it: rough first, better second

Get something ugly working end to end as fast as you can, even if every step is manual and the output is poor. Then improve one step at a time. This feels wrong if you are careful by nature, but it is the difference between finishing and not.

The reason is simple. An end-to-end rough version teaches you where the real difficulty is, and it is almost never where you expected. People spend two evenings perfecting step one and then discover step four was the hard part all along.

Keep a rough log as you go. A few lines a day, including the things that went wrong. You will need this in the next lesson, and reconstructing it from memory afterwards produces a much duller and less honest write up.

That distinction matters more than anything else in this lesson. AI can produce the whole thing in one go. If you let it, you have a demo you cannot explain, and explaining it is the entire test.

When you get stuck

You will get stuck. Everyone does. The trick is to notice quickly and change what you are doing instead of grinding.

Set yourself a rule: thirty minutes on the same error without progress means you stop and do one of four things. Reduce the problem to a smaller version that you can get working. Ask specifically rather than generally. Cut the feature and note the reason. Or leave it overnight, which solves an embarrassing proportion of problems.

I am stuck on one step of a project I am building myself.
What I am trying to do: [describe]
What I tried: [list what you tried, in order]
What happened instead: [describe]
Do not rewrite the whole thing. Instead:

Give me the three most likely causes, most likely first
Tell me one small test for each that would confirm or rule it out
Only then suggest a fix for the most likely cause
If you need information I have not given you, ask for it before answering.

Knowing when to stop

The last hour of a project is the most dangerous one, because improving something is more comfortable than declaring it finished. Go back to the checks you wrote in week one and be literal about them.

Here is the definition of done I wrote before I started, and here is what my project currently does.
For each check, tell me plainly whether it is met, partly met, or not met. Do not be generous.
Then tell me one of two things:

the smallest remaining work needed to meet the unmet checks, or
that I am finished and should stop building
Do not suggest improvements or extra features. I did not ask for those.
MY DEFINITION OF DONE:
[paste]
WHAT IT CURRENTLY DOES:
[describe]

Finish it. Then stop. The write up is next, and it matters more than another evening of polish.