Build an AI Project That Solves a Real Problem

Find friction in something you already do

Look at your last seven days. What repeated task made you open three tabs, copy text between apps, sort the same files, or ask the same question? Pick a task you understand well enough to recognise a wrong answer. Personal projects work well because you have access to the user and can get quick feedback.

Write the job as a verb plus an object: search lecture notes, identify receipts, draft a reply, group support messages. Now describe the current steps and how often they happen. Estimate the pain without inflating it. 'It takes me five minutes twice a month' may be a real nuisance, but it may not justify a complicated AI service.

Make the first version deliberately small

Choose one input, one useful output and one person who will check it. Skip logins, subscriptions, team settings and autonomous actions until a user needs them. A project that completes one step reliably teaches you more than a dashboard around a feature that does not work.

Keep the original data visible. If your tool summarises a note, show the source passage beside the summary. If it creates a calendar suggestion, make the user confirm before writing to the calendar. Clarity and undo are part of the product, especially when the model can confidently make things up.

Choose the simplest method that gets the job done

Make a baseline with search, filters or a template. Use a language model for the part that genuinely needs flexible language, classification, summarisation or extraction. A local model may be a good fit when privacy or offline use matters. A hosted model may help if the device cannot run a good model. Let the actual needs decide.

For anything that retrieves documents, pass only relevant sources and test whether it finds the right passages. For structured data, use a schema and validate every output. If an answer can trigger an external change, add a human confirmation step and retain a clear event record.

Finish with evidence

Write ten ordinary cases, three awkward cases and two cases the tool should refuse or flag. Record acceptable outcomes before trying the model. Count how often a result is usable without repair, how long it takes and what the mistakes cost. Keep the failure examples as regression checks when you make changes.

Show the prototype to the person it is meant to help. Ask them to complete the task while you watch. Do not teach them the trick that makes your demo work. Notice the point where they hesitate or correct your assumption.

Ship a small working version. Put the run instructions in the repository, describe the known limitation, and save a short demo that reflects the real thing. A modest tool that removes a repeat annoyance is a better portfolio project than a grand promise nobody can try.