Dogfooding software

I was talking with a friend recently about what it takes to make software successful. Specifically, indie apps and ideas.

Over the years I've waffled between two sides of a spectrum. On the one hand I want to build great interfaces based on insight from real world customers. That means running user research sessions, understanding bias, onboarding best practices, split testing, reading data, and ultimately trying to understand what people and how we can give it to them.

Those methods work, and I'm ever looking at ways to improve my skillsets in uncovering a need and finding ways to fill that need.

But then there's the other side of the equation. Scratching my own itch. And while the former, with user research and understanding data, has been something I've built a career on—you're always at a bit of a loss. You're reading tea leaves, scratching at data, talking to people, trying to understand what makes the software tick and who it's for. I'm not knocking that method. I've spent the last decade learning it and seeing its usefulness in building software that scales.

But for the indie side of me, the side that wants to make great productivity tools, or entertainment software—well I kind of want to throw all that to the side and just go with my gut (a gut that's obviously wrong at times, but also keeps learning after all these years from my failures).

When I'm trying to design an interface that meets my own need—there's something very special that happens. I ran into this last night when I was putting together some pieces on a productivity software I've been creating. I had in my mind an idea for how a button should work when pressed, what would pop up, and what would happen next. I designed it, got it up and running on my phone, tested it really quickly to validate it was correct, then moved on. That's all well and good, and part of the equation of building software. But then something special happened. I came back around a few hours later, because I needed to use the software for an actual, real world, use case—scratching my own itch, dogfooding my own software. And I ran into a wall I hadn't expected, the app acted in a way I hadn't anticipated with the need I now had.

Now, if this was productivity software I was using from someone else I'd just have to put up with it, find a workaround, and keep moving. But this was my app. So I took a note, and when I got to my computer I fixed it.

One bug squashed, one happy path restored.

For a while now I've been working on a todo app. I'll work on releasing it at some point. But the main goal has been to replace my current todo app (Things 3), one I'd been using for a decade. It's doing that. It's fully replaced it, and I'm using it every day for work, for life, for managing my life. And inevitably, when I run into an issue that could only happen in the day to day use of it, I take a note and go fix it later.

That's magical. That's software that I love. It doesn't mean it's perfect, or that it's for everyone. But it's opinionated, and it solves a real use case for me.

This is where I love what AI has unlocked. I can now use Claude or Codex and design out an idea, build it, and have it testing on a real device in days or hours. That just wasn't possible with my skillset in the past.

But, and here's where I think care and intuition will matter—when you can create an app from a single prompt, and anyone else can do it, there's of course the opportunity for a ton of crap to bubble up. And we're seeing just that.

The difference, I hope, is that you take the time to make software work for you, scratch your own itch, have an opinion. The applications should be defined as much by what they don't do, as by what they do.

Just this morning I was working on an idea, and after talking over it with a friend, decided to strip out a bunch of functionality that was half baked. Those decisions, those opinions, matter.

I'm fine if you design and code software with AI, and I'll try it—but only if you've taken the time to infuse your own life into it, your own dogfooding, your own struggles and cares. When you've molded it, used it as a tool to meet your needs; then and only then am I interested in trying it for myself.

As to all the software I've been tinkering with? Stay tuned. Hoping to release something soon. And for me, the litmus test in 2026 for whether it's worth releasing, is whether I've truly replaced existing software in my day to day and am using it for minutes or hours a day. Only then can I feel confident sharing it with the world.