Keepio

The problem solved

My tasks lived in one app, my timer in another, and my projects nowhere at all. Nothing tied the hours I put in to what was actually moving forward — I could run session after session without knowing whether a project had advanced. Keepio starts from the project rather than the task. A clear list, one goal at a time. The Pomodoro is built in, so every session counts towards a specific project and leaves a trace behind it. Progress reads at a glance, deadlines stay in the calendar instead of becoming one more notification. Everything syncs across iPhone, iPad and Mac with no account to create.

Behind the scenes

A year of solo development, and two structural decisions I would make again exactly the same way. The first: no SPM modularisation. A single target, organised through enum namespaces — App.Project.Views.Editor, App.Todo.UseCases. The usual advice is to split into modules; on a solo project, the cost of managing those dependencies outweighed the benefit. Two external dependencies in total, one of which I wrote myself. The second: freezing schema versions rather than tidying them away. Fourteen frozen versions, V1 through V14, every one a lightweight migration, none ever deleted. When CloudKit-synced data lives on real people's devices, removing a past version means breaking the update for anyone who skipped a couple of releases. The part that hurt was cutting project sharing from the scope. The feature was built; I pulled it out of the interface to ship the release, keeping the data layer dormant and the whole implementation on a branch. Deciding to stop something that already works is harder than writing it. The business model pivoted along the way too, from a subscription to a one-off lifetime purchase, with existing subscribers keeping what they had paid for.

Lessons learned

• 01A solo project does not need the architecture of a ten-person team.
• 02You never delete a schema version: someone out there is still on the old one.
• 03Cutting a finished feature to ship is a decision, not a failure.
• 04Swift 6 strict concurrency is expensive to adopt and pays you back in bugs never written.
• 05Design tokens, no hardcoded values: that is what makes a visual redesign possible at all.
• 06A business model is tested like a feature, and corrected the same way.