There’s a tradition in software development of building tools for yourself — scratching your own itch. I’ve done this with Tasks, my personal task management app, and it’s taught me more about software than almost anything else I’ve done professionally.
Why I built my own task manager
I’ve tried most of them. Todoist, Things, OmniFocus, Notion, plain text files, index cards. Each has something going for it. Each has something that doesn’t quite fit. Over time, the accumulation of small friction points — a capture flow that takes one tap too many, a view that doesn’t surface what I need to see today — adds up to something that makes the tool feel like work.
So I built Tasks. It’s opinionated in ways that match how my brain works. The capture experience is fast. The interface surfaces what matters today without requiring me to manage a system. It doesn’t do everything — but what it does, it does exactly the way I want.
That last part is the point. “Exactly the way I want” is a luxury you only get when you build it yourself. And unlike shipping software for others, there’s no ambiguity about whether it’s working — you find out immediately, every single day.
What you learn when you’re the user
Most software is built by people who don’t use it in the way the users do. They’re testing it, demoing it, reviewing it — but they’re not depending on it, day in and day out, as part of their actual life. That distance between builder and user introduces blind spots that are very hard to see from the outside.
When you build your own tools, that distance collapses. I notice immediately when an interaction is slightly off. I notice when something I thought was clear turns out to be ambiguous after six months of use. I notice when a feature I was proud of shipping turns out to be solving the wrong problem.
Daily-use software is also unusually good at teaching you about performance. The apps we use habitually are the ones where we feel latency most acutely. A half-second delay you’d forgive in an app you open once a week becomes genuinely annoying in one you open twenty times a day. Tasks has made me obsessive about perceived speed — not because it’s technically impressive, but because it matters to the experience.
The philosophy behind it
There’s a version of this essay that argues you should build your own tools to have a portfolio piece, or to learn a new framework, or to fill a gap in the market. Those aren’t wrong reasons. But they’re not why I did it.
I built Tasks because I had a problem, and I knew how to build software, and I thought I could do it better for myself than anything I could find. That’s it. The learning and the portfolio value are side effects of something much simpler: caring about the thing you’re making and using it every day.
I think the best software is built by people who genuinely care whether it works. Not just technically — but really works, for the actual humans who use it, in the actual conditions of their lives. Building your own tools is one of the most reliable ways I know to develop that kind of caring attention. You can’t fake it when you’re the one it’s failing.
That sensibility — care for the user, attention to the experience, honesty about what’s working and what isn’t — is what I try to bring to everything I build. Whether it’s a task app for myself, an insulin calculator, or a dialysis tracker for people managing a life-sustaining treatment. The context changes. The care shouldn’t.
Leave a Reply