I solve difficult mobile engineering problems — quietly, and for good.

For over a decade I've built mobile applications that millions of people rely on — from native Android in Java and Kotlin, to Flutter across travel, e-commerce, lifestyle, and social products, to SDKs that other engineering teams build on. Along the way I've led architecture, mentoring, and technical direction, and I've learned where the real problems live.

My core belief is simple: most mobile problems are architecture problems wearing a performance costume. A five-second cold start, a subscription flow that converts too few people, an app that gets harder to change every quarter — these look like separate issues. Underneath, they're usually the same thing: decisions that made sense at version one, quietly compounding.

So I don't start with clever fixes. I start by measuring — making the problem visible so a decision can be defended with data rather than opinion. I favour staged, reversible change over big-bang rewrites, because rewrites are where good companies lose a year. And I care as much about leaving a team stronger as I do about shipping the fix, because the best engagement is one that doesn't need to repeat.

If that sounds like the kind of engineer you'd want on a hard problem, let's talk.