I spent 15 years scaling operations that ran on other people's code. This year, during a sabbatical, I decided to see what it felt like to build the thing myself.
I used AI tools (Claude, mostly) to build a chore-management app for my household. Nothing fancy. But a few days in, I hit the same wall I hit at Capital One when we were expanding NLP-based call monitoring: the hard part was never the automation. It was deciding what "good" looked like before you could ask a system to find it.
That's the part most people talk about when they talk about AI and operations — the friction-identification, the "teach the model what to look for" work. It's real, and it's satisfying. But it's also only step one of three, and the gap between step one and the other two is where many automation initiatives quietly die.
Here's the pattern I've used at every scale, from a 200-person monitoring org down to a chore chart:
- Identify the friction that automation can actually solve. Not everything that's annoying is an automation problem. With call monitoring, that meant defining what a compliant interaction actually sounded like across thousands of edge cases. With the chore app, it meant getting specific about what "done" really means, and where the exceptions live.
- Design something that catches issues while they're still small. A model that flags problems after they've become patterns isn't much better than the manual process it replaced. The value is in surfacing signal early enough to act on it - whether that's a compliance risk or a kid quietly redefining "I cleaned my room."
- Build the human process around the output. This is the step that gets skipped, and it's the one I actually specialize in. A model can identify 94% of monitored interactions with issues, but if there's no operational rhythm for a team to see that output, understand what it means, and act on it without it derailing the work they're already doing... you haven't built anything except a very expensive report nobody reads. Designing that digestion process - the cadence, the escalation path, the way a frontline manager actually uses the signal without drowning in it - is the unglamorous 80% of the work.
The chore app forced me to do all three steps myself, solo, at kitchen-table scale. It's a much smaller system than an enterprise monitoring org. But the three-part discipline — find the real friction, catch it early, build the human loop around it — is identical. That third step is the one I don't see talked about nearly enough, and it's the one that actually determines whether an automation investment pays off or just becomes shelfware. It's the same job: translating a messy human process into something a system can act on reliably — then watching where it breaks and fixing it before it becomes a pattern.
The app has since grown past my own household — a second one I built, for shared property bookings (Cottage Calendar - field notes coming soon on that!), now has real users outside my family too. Small products, but the same discipline that enables a scaled operational team to thrive: define intent clearly, build for the edge cases, iterate fast.
Honestly? It was fun to build both things. There's something extra satisfying about building the whole thing yourself, bugs and all, instead of specifying it for someone else to build.
But it also confirmed something: I don't really turn this instinct off. Whether it's a 24/7 monitoring operation, a regulatory complaint process, an HOA budget, or a chore chart for my own kitchen — I'm always looking for the same thing. Where's the friction, what's the pattern underneath it, and how do I build something that makes that friction disappear.