How I work

I look for the gaps in a system before I look for what to build next. Most of my best work starts with something nobody assigned: a workflow that does not hold up, a screen that never got a second pass, an edge case the product missed. I hunt those down and close them.

Once I understand the problem, I move decisively. I would rather ship a directionally right version this week and adjust it than spend a month getting one direction perfect. Over-engineering worries me more than picking an imperfect first version.

Before I lock a direction, I like to iterate fast and conversationally: rough versions, quick feedback loops, talking through trade-offs out loud rather than writing them into a doc nobody reads. If there is a simpler path to the same outcome, I will push back and say so, even late in the process.

I do my best work on high-energy teams with open, direct feedback. I would rather hear "this is wrong" plainly than sit through a diplomatic run-around.

Craft still matters to me past the point where something works. What I build should feel like you're doing something, not watching it.