Build your first
useful thing.
Your first project should solve a small, real problem. It should not need permission from an API, a database, or a giant plan before you can see it working.

The project: a three-block Focus HUD
The idea is intentionally simple: a lightweight desktop utility that keeps only three critical tasks in view. It has a focus timer, a quick scratchpad, and a local record of its state. It does not need a login, cloud sync, calendar access, or a pile of settings.
I agree with your instinct to use Python and CustomTkinter here. It gives the agent a familiar widget structure and a modern dark-mode starting point, while keeping the project local and approachable. CustomTkinter is a package you install with Python; it does not require a separate desktop runtime.
The rule: use the agent in small loops.
Do not hand an agent the whole vision and hope for the best. Give it one bounded milestone, run what it makes, and decide what should happen next. This is how you stay the builder even when the agent writes the code.
Before you build
Ask your preferred LLM to guide the setup for your computer. The details change by operating system, so let the agent inspect what you have rather than memorizing a long list of commands.
"I am on Windows and want to build a small local Python desktop app called Focus HUD. First, inspect whether Python, Git, and GitHub CLI are installed. Tell me what is missing and give me one setup step at a time. Do not start building the app until I confirm each install worked. Use a virtual environment for this project."
Once GitHub CLI is installed and you are signed in, the agent can help create a private repository, add a sensible ignore file, make the first commit, and push it. Lesson 01 explains the mental model; you still review what will be included before it is committed.
"Create a private GitHub repository named focus-hud. Initialize a Python project with a virtual environment, a README, requirements file, and an appropriate .gitignore. Show me the proposed file list before the first commit. Then commit and push it to main, and give me the repository link."
Build it in four check-ins
Each phase should leave you with something you can run and inspect. If a phase feels too big, break it down again.
Make it visible
Build a compact dark window, three task rows, priority tags, a scratchpad, and a 25-minute timer. Do not worry about saving anything yet.
Make it remember
Save the tasks, timer preference, and notes locally in a JSON file. Keep it on the computer; no account or database is needed.
Make it behave
Use the GUI event loop for the timer, add an always-on-top option, and let the app notify you when a focus block ends.
Make it shareable
Package the finished app for your own computer. Keep the source project in GitHub and the app data outside the project.
The prompt that keeps the timer honest
The most common beginner timer mistake is blocking the interface with a sleep call. A desktop interface has an event loop already; the timer needs to schedule short updates through that loop so the window stays responsive.
"Add the focus timer without freezing the interface. Use the GUI event loop and scheduled callbacks, not time.sleep() or a blocking loop. Keep start, pause, and reset testable. Explain where the timer state lives and how I can verify the window stays responsive while it runs."
Also tell the agent to use the framework's supported scaling behavior before adding custom Windows-specific code. CustomTkinter documents appearance modes and HighDPI support, so start with the framework before solving a problem you may not have.
Keep version one intentionally boring
- Three tasks
- Local JSON state
- One countdown timer
- Simple local history
- Calendar integrations
- Cloud sync or accounts
- Webhooks and automations
- Sharing data with anyone else
This is not avoiding ambition. It is how you create the win that gives you confidence for the next project.
Package only after it works
When the app behaves the way you want, ask the agent to package it with PyInstaller. It can create a single-file executable or a folder build; test the packaged result on your own machine before sharing it. A Windows app should be packaged on Windows, a Mac app on a Mac, and so on.
Teach the tool how you work.
Turn the instructions that worked once into a reusable skill for next time.
Return to the learning path ->