Building Slothy — What I Learned Making a Task App That Judges You

I've started and abandoned probably six task manager apps over the past two years. Not using them — building them. Each time I'd get excited about some new feature idea, over-engineer it, lose the thread of what I was actually making, and quietly close the repo.

Slothy broke that pattern. Here's why.

Starting With One Constraint

The initial idea was deliberately limited: two lists, Today and Tomorrow, nothing else. No projects, no tags, no priorities. I wrote it on a sticky note and taped it to my monitor before I opened VS Code.

This was the single best decision I made. Every feature request I gave myself got filtered through "does this require a third category or a new hierarchy?" If yes, it was out.

The Procrastination Counter Problem

The counter was the feature I was most unsure about shipping. The idea: every time you drag a task from Today to Tomorrow, its counter goes up. It never goes down. The number sits there on the card, visible every time you open the app.

My first instinct was to make it resettable — give users a "fresh start" button. But that completely defeated the point. The discomfort of seeing "deferred 7 times" on a task you've had for two weeks is the feature.

I shipped it without the reset button. Nobody has asked for one.

Midnight Reset: Harder Than It Sounds

Getting Tomorrow to reliably become Today at midnight took longer than I expected. My first approach was a simple timer set on app launch — obviously broken if the app wasn't open at midnight.

The solution I landed on:

1. On every app open, compare the stored "last active date" to today.
2. If they differ, run the migration: move Tomorrow tasks to Today, clear old Tomorrow list.
3. Schedule a local notification for midnight as a soft reminder even when the app is closed.

This covers the case where the user opens the app for the first time after midnight, which is actually the most common case. The notification is secondary — it's a prompt to open the app, not the trigger itself.

Hive Over SQLite

I chose Hive for persistence because it felt right for the data shape — simple objects, no relations, no queries. It's fast, the API is clean, and integration with Flutter's state management is straightforward.

If I added sync or multi-device support, I'd reconsider. But the whole premise of Slothy is that it lives on your device and belongs to you. SQLite would have been fine too, but Hive was faster to set up and I had no reason to reach for more.

What I'd Do Differently

The one thing I'd change: I'd write the midnight migration logic as a pure function with unit tests from day one. I ended up catching two edge cases (DST transitions, devices with incorrect system clocks) through manual testing rather than automated tests. That was preventable.

What's Next

Slothy is finished in the sense that it does what I set out to build. I'm not planning to add features. If anything, I might remove the notification scheduling to simplify the permission request flow on first launch — that's the one friction point users have mentioned.

The real value I got from building it wasn't the app. It was learning to ship something small and done instead of something ambitious and perpetually in progress.