How I work

I start by getting clear on the problem rather than the feature list. Who uses this, what breaks today, and what has to be true for the thing to be worth building.

That usually means reading whatever already exists — the current codebase, the data model, the support tickets — and asking the questions that surface constraints early. Auth boundaries, tenancy rules, and anything real-time are worth finding now rather than halfway through.

I come back with a plan: what I’d build first, what I’d deliberately leave out, and where the risky parts are.

I build in slices that ship. Rather than finishing the frontend and then starting the backend, I take one real path through the product — interface, API, data — and get it working end to end, then repeat.

Types are shared across the stack so the frontend and the API can’t quietly disagree, and tests get written alongside the code rather than bolted on before a deadline. I use AI coding tools throughout; they make the mechanical parts faster, they don’t replace the review.

You see it running as it goes. No long silences followed by a big reveal — it’s easier to change direction in week two than in week ten.

Shipping is the start of the interesting part. I care about how the thing behaves once it has real traffic on it — slow queries, race conditions, the edge cases nobody hit in staging.

Before launch I go through the boring checklist properly: accessibility, error states, loading states, what happens on a bad network. These are the parts that get skipped under deadline pressure and they’re the parts users actually notice.

After launch I’d rather hand over something you can maintain than something that only I understand. That means readable code, written decisions, and a working local setup.