None of this is a framework. It's a handful of habits I picked up building tools inside operations, mostly by getting things wrong first.
The request is rarely the real problem
Someone asks for a report. What they usually need is to know why a number moved. So before I build anything, I try to map who's going to use it, how it fails, what it costs if it doesn't exist, and what's sitting next to it that's broken too.
The best example I have started as a question about a low survey response rate. A report would have shown the number was low. Digging into how the surveys were triggered showed that a misconfigured condition had left more than 63,000 of them unsent over eight months. No dashboard was going to fix that. Fixing the trigger did.
Fix the 20% first
Not every problem deserves the same attention. A five-minute annoyance in a workflow that 50 people run ten times a day is over 40 hours of lost time, every day. That's the one I go after first, before the stuff that's more interesting to build.
It's also why I try the boring fix before the clever one. When team leads were hand-calculating evening shift pay every fortnight, my first attempt was a spreadsheet formula. It helped, but it still needed someone to clean the data by hand each time, so I built a tool that takes the raw report and does the rest.
Say something before anyone asks
Waiting for a ticket usually means waiting for the problem to get bigger. One customer saying they haven't been paid looks like a one-off, especially when the admin screen says they were. Pulling on that thread turned up a batch of payouts stuck behind a failed processing job.
Flagging something that turns out to be nothing costs me a few minutes. Not flagging something real costs a lot more than that.
Ship the working version
Rough edges in production teach you more in a week than months of polishing. Working doesn't mean perfect, it means the people using it can rely on it. Once it's there, I ship it and fix what people actually run into, not what I imagined they'd run into.
Don't defend the old plan
I've pulled tools I built. One ran in production for a while on infrastructure I was paying for myself, and the cost stopped making sense, so I shut it down until I can move it to a stack I can host affordably. Another one is getting rewritten in Rust.
Neither of those feels like failure to me. The point was never the first version. It's whether the next one is better because I didn't hang on to the original.
Build for whoever comes next
The tools I build tend to outlive my attention on them. The next person to touch one might be a teammate, an AI agent plugging into it, or me in six months having forgotten everything. So I keep the pieces separate, document how they talk to each other, and write the README, ADRs and other technical documentation for someone who wasn't in the room.
That's most of it. I'll probably write about each of these properly at some point, and I'm sure a few of them will change.