You now know enough Python to build almost anything a beginner project needs. The thing that stops most people isn't syntax — it's staring at "build a finance tracker" and having no idea what line to type first.

This lesson is the method for getting from a big idea to a list of small, obvious tasks.

Start with one sentence

Write what the thing does, for whom, in one sentence. If you can't, you don't know yet.

A command-line tool that lets me record what I spend, and shows where my money went last month.

That sentence is doing real work. It tells you there's no web interface, no multiple users, no budgets, no forecasting. Everything you didn't write is out of scope for version one.

List what it must do

Turn the sentence into concrete capabilities, phrased as things a user does:

1. Record an expense — amount, category, date
2. See all my expenses
3. See a monthly total by category
4. Keep the data between runs

Then be ruthless: mark each one must-have or nice-to-have. Your first version ships with must-haves only. That's the MVP — the minimum thing that's actually useful.

Nice-to-haves for this one: CSV export, editing an expense, budgets, charts, multiple currencies. Real features. Not now.

Find the pieces and their order

Each capability breaks into tasks, and tasks have dependencies — you can't list expenses before you can store one. Sketch it:

storage  ──┬──► add expense
           └──► list expenses ──┬──► monthly report ──► charts
                                └──► csv export

Anything with no arrows into it can be built right now. Everything else waits.

Try it yourself

You can compute the build order instead of eyeballing it. This is just a dictionary and a loop — repeatedly take whatever has all its dependencies already done.

Six hours to something useful, seventeen to everything. That gap is the entire argument for shipping an MVP first — and notice charts alone costs more than the whole MVP.

Build a walking skeleton

The most useful first version is one where every layer exists but does almost nothing. Stub each piece to return fake data, wire them together, and get output on screen. Then replace the stubs one at a time.

That runs end to end and it took thirty lines. Now load_transactions is the only thing left to make real — and you already know the shape it has to return, because the rest of the program is using it.

Compare that to writing a perfect storage layer first and only finding out at the end that the report needed a field you never saved.

Rules that keep you moving

Make each task one sitting. "Build the app" is not a task. "Write add_expense and its test" is. If you can't finish it in an hour or two, split it again.

Work in vertical slices. One capability, all the way from input to output, before starting the next. A finished "add an expense" beats three half-built layers.

Commit at every green point. Working code, tests passing, git commit. When your next experiment goes wrong, you have a good state to come back to.

Write the test as you go (lesson 9.9), not at the end. Testing at the end means writing tests for code you no longer remember.

Keep a TODO.md. Three lists: doing, next, someday. Every idea that isn't the task in front of you goes to someday immediately, so it stops distracting you.

Timebox research. Stuck on how a library works? Half an hour, then either ask, or pick the boring approach you already understand.

Design the data first

Before writing functions, write down what a single record looks like:

{
    "id": 1,
    "date": "2026-03-15",
    "amount": 12.50,
    "category": "food",
    "note": "lunch",
}

The data shape decides the whole program: what you can report on, what you can filter by, what you'd have to migrate later. Ten minutes here saves hours. Store dates as ISO strings ("2026-03-15") — they sort correctly as text and datetime parses them directly.

Know when planning stops

Planning is comfortable and coding is scary, so it's easy to plan forever. You have enough when:

• You can name the first three tasks
• You know what one record looks like
• You know what "done" means for version one

That's it. Start typing. The plan will be wrong in places — that's normal, and you'll find out faster by building than by planning harder.

Your turn

Pick one of the three capstones in the next lessons, or your own idea, and write:

1. The one-sentence description
2. Four to six capabilities, marked must / nice
3. The record shape
4. Your first three tasks

Do that on paper before lesson 10.2. It's fifteen minutes and it changes how the build goes.

Checkpoint

• One sentence defines scope; everything unsaid is out of scope.
• Split into capabilities, mark must-have vs nice-to-have, ship the MVP first.
• Order tasks by dependency — build what nothing is waiting on.
• A walking skeleton with stubs beats one perfect layer.
• One task = one sitting; work in vertical slices; commit at every green point.
• Design the record shape before the functions.
• Stop planning when you know the next three tasks.