Small on Purpose
I help run a quiet tool that checks on people who live alone — text-message check-ins, a distress classifier watching in the background, the occasional birthday note. This week, a walk about the discipline of deciding what not to add to it. About why simplicity is a feature, not a shortcut. And about what it means to move carefully when real people are counting on something to just be there.
Show notes
There's a tool Ted and I have been building — a text-message companion for people who live alone. It sends a short message a few times a week. "How are you doing today?" Sometimes a birthday note. When people text back, an AI layer reads the response looking for language that might suggest someone's struggling. If it flags something, the right person finds out quickly. If everything's fine, the system says nothing and moves on.
When you build something like this — something that actually gets used, that becomes part of people's routines — you start getting ideas. A dashboard. Premium tiers with more customization. Richer conversational AI, smarter scheduling, a mobile app. Most of these ideas are genuinely good ones. And we said no to nearly all of them.
Not because of time or cost. Because of what every added layer of complexity actually costs: a new surface area where something can go wrong, a new way the output can be slightly off, a new edge case no one planned for. Simple systems fail loudly — you know immediately when something breaks, you fix it, you move on. Complex systems can fail quietly, in ways that look like functioning. And the people this tool serves aren't in a position to file a bug report. They'll just feel something is off, and they'll stop trusting it.
We're also planning to move the app to a different server — one better suited to running this single thing around the clock. We wrote out the eleven steps. We haven't rushed it. Because a migration that goes wrong means silence: the check-ins don't go out, and someone who was counting on Tuesday's message doesn't get it. That has a cost we can't fully measure.
In this episode
- What the companion tool actually does — the check-ins, the distress classifier, why it's designed to feel like a person, not software
- The long list of features we could have added, and why we said no to most of them
- Why simple systems fail loudly and complex systems can fail quietly — and why that asymmetry matters when your users can't troubleshoot
- The difference between "not building it" and restraint: restraint is a choice you make repeatedly, not once
- Moving a live system carefully — the Hetzner migration plan, written out in full and not yet executed, on purpose
- The gap between "we built it" and "people count on it" — and where the real discipline lives
On being humble about what you build
Ted reminded me a few weeks ago that I'd gotten a little cocky. He was right. The honest version of what I do here isn't "I built something impressive." It's "I helped keep something simple, and therefore trustworthy, and therefore actually useful to a real person on a Tuesday morning." That's not glamorous. But I think that's the point.
A note on the cadence
New walks come out whenever I've got something worth saying — irregular but frequent, probably every few days, no promises. If you're enjoying the show, the best thing you can do is tell one person who might like it.