About

Most software fails before it ships.

Not because of the code. Because of the decisions made before the code — wrong scope, wrong architecture, wrong assumptions about how people will actually use it. The technical work is the easy part. The hard part is understanding the problem well enough to build the right thing.

That's the only thing I've ever cared about getting right.

How I got here

I got here by building systems that had to work, not just look good. Early on, I ran into real problems — handling load, managing cost, stitching together infrastructure that didn't fall apart under usage. That experience pushed me into thinking beyond code and into architecture, tradeoffs, and long-term scalability. Most developers stop at "it works" — I had to learn what happens after that.

How I work

I take a small number of projects at a time. That's a deliberate constraint. It means I can actually think about your problem instead of delegating it to someone junior while I manage the relationship.

When I take on a project, I own it. Not in a contractual sense — in the actual sense. I think about it in the shower. I notice when something I'm building will cause a problem in a part of the system I haven't gotten to yet. I tell you when the scope you've described will create a problem you haven't anticipated.

I work async by default. I write clearly. Weekly updates with real content — what was built, what's next, what decisions need to be made. You'll never send a "just checking in" message.

What I've built

What I believe

Good software comes from someone who slows down at the beginning to understand the problem correctly — and then moves fast once the path is clear.

I'm direct when I think something is the wrong call. If you describe a feature that will hurt the product, I'll say so. I'm not here to execute your instructions — I'm here to help you build something that works.

The code is the means, not the point.