How I stopped using complex project trackers for my design work
I was drowning in Jira tickets. Every morning I'd spend forty minutes triaging tasks that were already overdue, and half of them weren't even my responsibility. My team lead kept asking me to generate weekly reports that showed zero actionable insight. I needed something that tracked what actually mattered without adding another layer of ceremony to my day. That's when I found a Minimalist History Planner. Not the polished product you'd see in a G2 review, but a rough script I wrote myself in Python using SQLite and a simple CLI interface. Three thousand lines of code, maybe less, solving one problem: keep a clean chronological record of what changed and why, without turning task tracking into a second job.
What Minimalist History Planner actually does
The core idea is embarrassingly simple. Every time you update a task, log the before and after state with a timestamp, and store it in a local database. No dashboards. No notifications. No integrations with Slack or email unless you explicitly configure them. When you ask for history, you get a flat list of changes sorted by date, with the option to filter by project, owner, or keyword. I built mine to run on my laptop during work hours. The database lives in ~/.minimalist_history/. The script is one file, about two hundred lines. There's no web interface, no API, no way for someone to bulk-delete my entries by mistake. That last point isn't trivial, I learned that the hard way with a different tool in 2023.
The workflow I use every single day
Morning stands look like this: I open a terminal, type mh log --project=redesign --status=started, and press enter. The script records the timestamp, my user ID, the project name, and the status change. Five seconds. That's it. When I finish a task, I run mh log --task=landing-page-v2 --status=completed --notes=Merged PR #47. The database stores everything. If I need to reconstruct what happened last Tuesday, I type mh history --project=redesign --date=2024-01-16 and get a flat text output, no charts, no colors, just the raw sequence of events. I've been using this setup for fourteen months now. The database is 47 megabytes. That includes every status change, note update, and project creation for three active projects. Retrieving the full history takes about 200 milliseconds on my machine. Searching by keyword across six months of entries takes 1.2 seconds.
Get the Full Details
Where this falls apart, and what I do instead
The first problem anyone hits is data export. SQLite doesn't play nice with non-technical people. When my director asked me to share the last quarter's activity report, I spent forty-five minutes writing a quick Python script to convert the database to CSV. She looked at the file, asked what the columns meant, and put it back in her inbox unread. The second problem is collaboration. This tool works great when you're the only person reading and writing to the database. Put two people on it, and you get lock contention errors, race conditions, and silently lost updates. I tried running it with one teammate for two weeks. We lost about thirty entries to a write conflict I didn't notice until the weekend. I switched to a single-writer model where only I update the database, and everyone else uses a read-only copy I push to a shared folder on Friday afternoons. The third problem, and this is the one nobody talks about, is scope creep. Once you start adding features to a tool like this, it becomes a habit to want more. I added a notification system in month two. Removed it in month three because I was checking my phone four times an hour. I added a web dashboard in month five. Removed it in month six because maintaining the frontend took more time than the manual CLI ever did.
If you need real-time collaboration, Kanban boards, or integration with your existing project management stack, this isn't the tool. Use Linear or Notion. If you just want a clean, offline, no-nonsense record of what changed and when, this works.
The exact workaround for the lock contention issue
Here's what I learned from losing those thirty entries. SQLite uses file-level locking, which means two processes can't write at the same time. My first attempt was to add a retry loop with exponential backoff. That helped with occasional conflicts but didn't solve the structural problem. The actual fix was simpler than I expected. I set the journal mode to WAL (write-ahead logging) in the SQLite pragma, and changed the connection pool to use a single writer thread with a queue. Writes serialize automatically. Reads are still concurrent. The penalty is about 50 milliseconds of extra latency per write operation, which is invisible in practice. I also added a checksum validation step after every commit to catch silent corruption, which I thought was impossible until I saw a bitflip on a production SSD eat one of my entries.
Getting started with your own Minimalist History Planner
You don't need to write this yourself. The concept is transferable to any language, any database, any workflow. The core is a timestamped log of state changes with filtering capability. Everything else is decoration. If you want the Python version I use, it's on GitHub at a URL I'll leave here. The README has installation instructions, the database schema, and the complete list of CLI commands. The script requires Python 3.9 or later, SQLite 3.35 or later, and about ten minutes to set up. There's no package to install, no virtual environment required, no Docker container spinning up in the background. I'll be honest about one thing I haven't told you yet. The tool breaks if you delete the database file by accident. There's no backup, no recovery, no version history of the history itself. I learned that in month four when I ran rm -rf on the wrong directory during a system cleanup. Two weeks of entries gone. I now run a cron job that copies the database to a time-stamped backup folder every night at 11:30 PM. Takes about 300 milliseconds. I've restored from those backups once, in month eight, when a power surge fried the primary drive.
That's it. No final thoughts, no wrap-up. The tool works for what it does. It doesn't do everything. If you need more, build more, or switch tools. The principle stays the same: keep a clean record, stay out of the way, let the data speak for itself.
