Let's see about this Claude Code. Installing and writing a chores app
- Ken Munson
- Apr 17
- 4 min read
Building a Personal Chore Planner with Claude Code, Python, and a Little SQLite Education.
Sometimes the best projects start with the simplest frustrations. I wanted a better way to track chores - not a generic to-do app, not a complicated project management tool, but something that looked like a real calendar and understood the rhythms of recurring tasks. But even more than that, I wanted to give this Claude Code thing a try after hearing so much hype around it.
In about an hour, using Claude Code as a collaborative coding partner, we built exactly that from scratch. Oh and, that hour includes downloading, installing, and learning the basics of Claude Code and also writing a pretty descent chores (To-do) app. How was it? It was amazing. I've seen A LOT of tech, including a lot of AI tech. This was actually amazing - it was one of the rare things that actually lived up to the hype. It took about 15 minutes to do the actual code part and get it running. Here is what the UI looks like:

The install was beyond easy. It is literally just this command in a PowerShell window:
irm https://claude.ai/install.ps1 | iex.
To start it, just type claude at the PS prompt and you are rolling. Tip - create a directory that you want to use with Claude Code and change to that directory before starting - that is where it will save the things you create and that is where Claude will have default access to files without asking. If you have an existing codebase or place where you keep files that you might want Claude Code to have access to, maybe that is the right place to run it from.
The App - Starting with the Right Questions
See screen shot below. Before writing a single line of code, we spent time getting the requirements right. What views did I want? What data did a chore need? What recurrence patterns mattered — just weekly, or also "every 3 days"? Should completed chores be archived or just deleted? It sounds obvious, but this kind of upfront conversation is exactly where solo projects usually go sideways. Having a back-and-forth to nail down the scope — month and week views, name/duration/notes per chore, no reminders for now, single-device local use — meant the implementation that followed had no ambiguity to guess at.
Choosing the Stack
Since Python is my home turf, that anchored the backend. Flask was the natural fit: lightweight, beginner-friendly, and capable enough to serve both a REST API and the HTML page itself. For the database, we chose SQLite — a file-based database that ships built into Python's standard library. No server to install, no credentials to manage. Your entire dataset lives in a single .db file sitting in your project folder. I had been curious about SQLite for a while, and this turned out to be an ideal introduction: a real database with real SQL, but with zero infrastructure overhead. On the frontend, FullCalendar.js (paired with Bootstrap 5 for the modal dialogs) gave us a Google Calendar-quality UI almost for free.
How the Pieces Fit Together
The architecture is straightforward. Flask serves an index.html page that loads Full Calendar in the browser. When the calendar renders - or when you switch between Month and Week view — it fires a request to /api/chores with the visible date range. Flask queries SQLite for all chores, runs each one through a recurrence engine that expands the rules into individual dates, and returns a JSON list of events. Full Calendar takes that list and paints the calendar. Adding, editing, and deleting chores hits separate API endpoints that write back to SQLite. The whole loop is clean: the browser owns the display, Flask owns the logic, SQLite owns the data.
Running It Locally
Getting it running took one command: pip install flask, followed by python .\app.py. Flask starts a local web server on port 5000, the SQLite database file is created automatically on first run, and the app is immediately usable at http://localhost:5000. No Docker, no cloud accounts, no environment variables. For a personal tool that lives on one machine, that simplicity is a feature. The entire project — backend, frontend, and database logic — fits in under 300 lines of code across four files.
What This Kind of Collaboration Actually Feels Like
What struck me most wasn't the speed, though building a working calendar app in under an 15 minutes is genuinely impressive. It was the quality of the back-and-forth. Claude Code asked clarifying questions before touching the keyboard, flagged a design decision I hadn't considered (pre-generating occurrences vs. computing them on the fly), and left comments in the SQLite code specifically because I mentioned I wanted to learn that piece. It felt less like using a code generator and more like pairing with a developer who happened to type faster than anyone I've ever met — and one who remembered everything we discussed at the start of the session when writing the last line of code.
Below is that actual dialogue with Claude. And the model "was only" Sonnet 4.6.

I used 3% of my weekly cap to do this little project, which churned out a considerable amount of code. Entire session from start to finish was 1 hour 18 minutes.
Here is a video I watched that helped:




Comments