Dogfood your own work

I recorded half a minute of nothing before I noticed.

Lotl is a Mac app I built. It captures system audio and transcribes conversations live, with nothing leaving the machine. I started it because I wanted records of my work conversations. The silence happened because macOS had denied mic permission, and when macOS denies mic permission it doesn't throw an error. It hands you all-zero audio buffers and lets you carry on. The code was fine by every measure except the one that mattered, which is that a human was sitting there talking into it.

The fix was to check permission before starting and detect silent audio at runtime. "Silence is an error state" is now one of about sixty architecture decision records in that project. I would not have found it from a bug report. I found it because I was the one talking.

Here's how I use Lotl. It's my dictation tool: I click the widget, talk, and let Claude Code interpret it. It's my main notetaker. It's basically my memory. On the side I use it to practice for meetings and interviews, and to look at my own speaking habits. I'm using it all the time, for a lot of different things.

I'm also running the production build most of the time. Not a development build. The signed, notarized app that updates itself, the same one that's in open beta at lotl.co. I install it on different computers. So when it fails, I see it fail. I see what the issues actually are. I hit every rough edge. I feel it when it breaks, and I get frustrated if I lose something.

Here's the point. A bug report tells you what broke. Using your own product tells you what's wrong. Those are different things, and the second one is where the fixes that matter live. Daily use is how I actually understand the experience, and understand the pain. There's no shortcut for it. This is the type of stuff that needs to happen.

I'd learned this before Lotl, just less deliberately. At Shopify I was a Staff engineer on the Experimentation Platform team. ExP ran A/B tests and feature flags, and every flag my team shipped went through it. Engineers across the company told us it felt like bureaucracy and slowed their pages down. Because we used it ourselves, when it was slow or buggy we felt the same thing they did, before anyone filed a ticket.

Earlier still, I ran Wedimage for about ten years, a bootstrapped SaaS out of Edmonton, while I was also doing wedding photography myself. Using it to deliver photos to my own clients surfaced something I'd missed: I didn't want to send couples there, in case they browsed and picked a different photographer. No bug report says that. Only a user does.

Repeated use also surfaces flaky code. Code that passes tests but fails in the real world is its own category of bug, and tests are structurally bad at catching it because the test is the thing that passes. Daily use is how you find it. Not a QA pass before release. Daily.

It's not always possible to dogfood. But when you can, do. And do it the way I do it with Lotl, not the polite version. Run the real production build, the one your users get, not a staging environment. Put it on more than one machine. Make your real work depend on it: your notes, your memory, whatever you'd be upset to lose. Then pay attention to the moment someone on the team hesitates before using it, or loses something and gets frustrated.

That hesitation is the bug report nobody was ever going to write.