Python Project
Expense Tracker CLI
An expense tracker CLI is an ideal first Python project because it exercises everything a real program needs — parsing arguments, validating input, persisting data between runs and formatting output — without any of the complexity of a web framework. You finish with a tool you will genuinely use.
The brief
Build a terminal application that records expenses and answers questions about them. It must survive being closed and reopened, reject nonsense input politely, and produce a monthly summary someone could act on.
What it demonstrates
That you can structure a program larger than one file, persist state, handle bad input without crashing, and test what you wrote.
What "done" looks like
Build all of these and the project is finished. Anything past that is in the stretch goals.
- Add an expense with amount, category, date and an optional note
- List expenses, filtered by category or date range
- A monthly summary showing total and breakdown by category
- Data survives closing the program
- Clear errors for bad input — a negative amount, an unparseable date
- Tests covering the parsing, the maths and the failure cases
How to build it
- 1
Design the data shape first
Decide the fields and their types before writing code. Changing this later means migrating every stored record.
- 2
Parse arguments
Use argparse with subcommands — add, list, summary — so the interface is discoverable via --help.
- 3
Validate input at the boundary
Reject bad amounts and dates where they enter, so the rest of the program can assume clean data.
- 4
Persist to disk
Write to CSV first. Handle the file not existing yet, and never leave it half-written if the program is interrupted.
- 5
Build the summary
Group by category and month. This is where a dict of lists beats writing the same loop three times.
- 6
Format the output
Align columns and show currency consistently. A tool people use is one whose output is readable.
- 7
Write the tests
Cover the maths, the date parsing and the empty-file case. Then refactor something on purpose to see them work.
Once it works
Only after the definition of done is met. Half-finished ambition reads worse than a small finished thing.
- Move storage to SQLite and add filtering with SQL
- Add budgets per category with a warning when one is exceeded
- Export a monthly report as CSV or a simple chart
Frequently Asked Questions
Is a CLI project impressive enough for a portfolio?
For a first project, yes — provided it is finished. A complete CLI with persistence, error handling and tests says more than an unfinished web app, because it demonstrates you can take something to done. Reviewers can also run it in ten seconds, which a half-deployed web project does not allow.
CSV or SQLite for storage?
Start with CSV — it is readable, debuggable and needs no dependencies. Move to SQLite once you want filtering and aggregation, which is a natural second version and a good excuse to learn SQL against data you understand.
How do I make this stand out?
Handle the unglamorous cases: an empty file, a corrupted row, a date in the wrong format, a duplicate entry. Robustness is what separates a tutorial follow-along from something you designed, and it is exactly what an interviewer probes.