How I work

Fewer surprises, on both sides.

Every project runs the same way: understand it properly, build it in visible pieces, and hand it over in a state you could give to someone else tomorrow. Here’s what that looks like in practice.

A conversation

You tell me what you’re building and what’s in the way. I ask the awkward questions early — who the users actually are, what already exists, what has to integrate — because those are the answers that change the estimate. No charge, no obligation.

Scope and plan

I write down what I heard: the feature set, the system shape, the risky parts, and a timeline with the assumptions it rests on. If the project is large or the requirements are still moving, we start with a short paid discovery phase and produce that plan as its own deliverable.

Build, in the open

Work lands in your repository from the first week. You get regular builds you can actually install, a written update on what moved and what didn’t, and a direct channel for questions. Changes of mind are normal — we re-plan rather than pretend.

Ship

Store submission, deployment, monitoring and the unglamorous release work. I don’t consider something delivered until it’s running in production with a way to tell whether it’s healthy.

Handover

Documentation, architecture notes, credentials, and a walkthrough for whoever maintains it next — your team, a future hire, or me on a support arrangement. Everything I build is yours, and it should be legible without me.

The stack

What I build on

I default to boring, well-understood tools and choose per project rather than by habit. If your team already has a stack, I work in it.

Mobile: Flutter — one codebase for iOS and Android, with native modules where the platform demands it
Backend: Go services and HTTP/JSON or gRPC APIs — my specialty and my default
Data: PostgreSQL, migrations kept in version control, plus caching and queues where they earn their place
Delivery: Containers, CI on every commit, staged environments, automated store and server releases
Operations: Structured logging, metrics and alerting so problems announce themselves before your users do
Yours: An existing codebase, an in-house platform, a language your team already knows — tell me and I’ll adapt

Working together

Engagements

Project work

A defined build with a scope and a finish line — a new app, a new backend, or both together. Most of my work looks like this, and the plan from step two is what we agree to.

Ongoing

Continuing development, maintenance and on-call support for something already live, booked as a share of my time each month so you know I’m available when you need me.

Advisory

A short, focused engagement: review an architecture, unblock a team, or write the technical plan you need before you can hire against it. Ends in a document, not a dependency.

Terms and rates depend on the shape of the work — ask me and I’ll give you a straight answer.

Tell me about your project