Choosing a small, finishable idea · Building AI

You are now five chapters of Python, two days of tooling, and three real Nepali examples into being a builder. The hardest thing left in Course 01 is not technical. It is choosing what to build. Most beginners get this wrong — they pick something either too big to finish or too small to learn from. This section is one quiet lesson about choosing well.

Why a small finished project beats a big unfinished one

A finished project, however small, teaches you the full shape of building: deciding scope, fighting through the boring middle, polishing the rough edges, putting it somewhere someone can see it. A half-finished big project teaches you only the beginning of one of those things. The asymmetry is enormous.

The track is paced so that, finishing this chapter, you will have one small, real, end-to-end project in your building-ai-notes GitHub repo. That single artifact is worth more than the entire vocabulary of Chapters 1 through 5.

Three properties of a well-chosen first project

Look at your idea — the one you wrote down back in Chapter 1, Section 1 — and check it against three honest questions.

1. Can you finish it in a weekend?

By “weekend” we mean about ten to fifteen hours of focused work, spread across whatever days you have. Not “the first version” — the entire thing, including writing it up.

If your idea would take a month, it is too big. The question is not “is the idea good?” — almost all your ideas are good. The question is: what is the smallest version of this idea that is still useful to someone?

Some examples of right-sizing:

❌ “Build a personal AI tutor for SEE-level students across Nepal.”
✅ “Build a Python script that takes one chapter of a Class 10 Science PDF and produces a five-question quiz in Nepali.”
❌ “Build a Nepali Khalti-statement analyser with budgeting and forecasting.”
✅ “Build a script that reads my Khalti statement CSV and prints my top three vendors of the month.”
❌ “Build the next NEPSE app.”
✅ “Build a script that fetches today’s NEPSE close, asks Claude for a 3-sentence Nepali explanation, and prints it.”

The right-sized version of each idea is often 80% of the value at 5% of the work. Almost everyone overestimates the value of the missing 95% and underestimates the friction of building it.

2. Is it a problem you understand?

The pattern of the whole track is that the Nepali-ness of the problem is your advantage. A foreign team can build something fluent and global; only you can build something that knows what a Kathmandu landlord’s rental agreement actually looks like, or that a Hetauda shopkeeper budgets in lakhs not crores.

Choose a problem you personally have, or that someone you know personally has. If you have to imagine the user, the project is harder than it looks. If the user is you, your feedback loop is instant.

3. Does it actually use what you learned?

The point of this project is not to test your Python — it is to demonstrate that you can build with the AI pieces. Your project should use at least one of:

A pre-trained model (Tesseract OCR, or a Hugging Face model)
A language-model API call (Claude, GPT, Gemini)
Real data you load from a file, an API, or scrape

If your project is just “I built a calculator”, it is too small in kind — you have used none of the AI tools the track is built around. Add a piece. A calculator that explains its answer in plain Nepali? Now you are using the tools.

Some right-sized starting points

If your Chapter 1 idea is not the right size, here are eight starting points you can adapt — chosen because each is finishable in a weekend, uses tools from the track, and produces something a real person can use.

NEPSE daily summariser. Fetch today’s NEPSE close from a public API, ask a language model to write a 3-sentence Nepali summary, print it (or send it to yourself on Telegram).
Receipt OCR helper. Take a folder of photographed receipts, run Tesseract OCR, extract the amounts, write a CSV summary of the month.
Khalti vendor analyser. Read your Khalti statement CSV, group by vendor, print your top spending categories with pandas, save a chart.
Devanagari name normaliser. Take a CSV of Nepali names entered inconsistently (e.g. some Devanagari, some Roman) and use a language model to standardise them.
Class-10 question generator. Paste a chapter of text, ask a language model for five exam-style questions in Nepali, write them to a Word-friendly file.
Local news clipper. Scrape headlines from one Nepali news site, ask a language model to cluster them into themes, print the result as a short morning brief.
Bus-route explainer. Type a starting and ending neighbourhood in Kathmandu; ask a language model to suggest which Sajha or microbus route to take, and warn about traffic patterns.
Sentiment lens on Twitter/X. Search a Nepali keyword (e.g. a politician’s name), pull the last fifty posts, ask a language model to classify each as positive/negative/neutral, plot the count.

Each is plausible in a weekend. Each demonstrates real builder skills. Each is small enough to actually finish.

Writing the brief

Before you write a line of code, write a one-paragraph brief. Aloud, in plain language. It should answer three questions:

Who is this for? “Me, when I want to read about NEPSE in Nepali.” Or: “My aunt, who runs a small kiraana store.”
What does it do? “It takes today’s NEPSE close, asks Claude to summarise in Nepali, and prints the result.”
How will you know it’s done? “When I can run python summary.py and see a Nepali paragraph in my terminal.”

That third question is the most important. It is your definition of done. Without one, projects stretch forever. With one, you have something to declare victory against.

Write your brief now, before reading the next section. Keep it short. Keep it specific. We will use it to plan the actual build.

Check your understanding

Quick check

—

A friend tells you she is going to build 'an AI app that solves Nepal's problems'. What is the most useful response, based on this section?

Encourage her — it's an inspiring vision, and ambition is the most important thing.
Gently push her toward the smallest version: 'What is one specific problem one specific person has, that the smallest version of this could help with in a weekend?'
Tell her AI cannot solve real problems and to pick a calculator instead.
Suggest she watch a tutorial on PyTorch first.

Quick check

—

You picked an idea: 'a script that summarises my Khalti statements in Nepali'. Which of the following is the best `definition of done` to keep on a sticky note while you build?

When the idea is perfect.
When my friends like it.
When `python summarise.py statement.csv` runs without error and prints a 2-3 sentence Nepali summary of the month.
When the code is at least 500 lines long.

What comes next

Brief in hand, idea sized down, you are ready to build. The next section walks you through one example all the way from empty folder to working program — the NEPSE summariser. You can either follow along with the same idea or use the structure as a guide for your own.