How I work

Engineering principles

Not a poster on a wall — the defaults I return to when a decision isn't obvious.

Simple over clever.

The best solution is usually the one a teammate can understand six months from now without a walkthrough. I optimize for clarity first and reach for abstraction only when the codebase has earned it — not before.

Privacy by default.

Data you never collect can never leak. I design systems that keep sensitive information on-device wherever possible, encrypt what has to leave it, and treat every permission prompt as a promise to the person granting it.

Performance matters.

Speed is a feature, not an afterthought. Jank, cold-start delay, and dropped frames erode trust faster than a missing button — so I profile early, budget for the worst device in the fleet, and treat regressions as bugs.

Accessibility is essential.

A product that only works for some of its users isn't finished. VoiceOver, Dynamic Type, and reduced motion aren't edge cases to me — they're part of the same craft as the pixel-perfect layout.

Maintainability wins.

Software is read far more often than it's written. I favor modular architecture, honest naming, and tests that document intent, because the team maintaining this code in three years deserves the same care as the user opening the app today.

Great architecture enables fast shipping.

Speed and structure aren't in tension — they compound. A codebase with clear boundaries and well-tested modules is the reason a team can ship a feature in a day instead of a sprint. I invest in architecture precisely because I want to move faster later, not slower.

Software should be built to last.

I write code assuming it will outlive the framework it was written in, the team that shipped it, and my own memory of why a decision was made. That means documenting the non-obvious, avoiding fashionable dependencies with no exit plan, and treating deletion as a valid, healthy outcome of a design review.

Products over technologies.

Swift, CoreML, and SwiftData are tools in service of an outcome — not the outcome itself. I choose technology based on what a product and its users actually need, and I'm equally comfortable saying no to something fashionable.

User trust is earned.

Every crash, dark pattern, and broken promise spends down trust that took months to build. I treat reliability, honesty in UI copy, and respect for a user's time and data as non-negotiable, not nice-to-haves.

Technology should disappear behind great experiences.

The best compliment a product can get is that it just works. My job as an engineer is to make the machine learning model, the encryption layer, and the sync engine invisible — so what's left is an experience that feels obvious in hindsight.