ENGAGEMENT MODEL / Q4 2026
AVAILABILITY AND TERMS.
How I'm set up to work: engagement shapes, what a week actually looks like, and the handful of things I won't take on. Published so nobody has to ask awkward questions over email.
//Engagement shapes#
Three formats cover almost everything. A build engagement is the main one: six to twelve weeks, one project at a time, priced in phases. A review is a fixed two-week audit of an existing frontend, ending in a written report with prioritised findings and rough effort estimates — useful when a team suspects something is wrong but can't get agreement on what. And a short collaboration, two to four weeks, for a specific hard piece: a shader, a difficult interaction, a performance rescue before a launch.
//How a week works#
I take one project at a time, which means you get genuine focus and it also means I can't start next Monday. Typical week: four days of building, one for review, writing and the unglamorous maintenance that keeps a project honest. I work asynchronously by default with two scheduled calls a week, and I'd rather send you a working branch than a status update.
//What I don't take#
Work I'd do badly or resent. That includes full-stack builds where I'd be the only engineer on a substantial backend, native mobile, anything requiring a design direction invented from scratch with no input, and projects where the interaction design is settled and non-negotiable but demonstrably won't work. I'll always say why, and I'll usually know someone better suited.
Rates depend on scope and duration and I'll quote them in writing before anything starts. No hourly billing — it rewards slowness and punishes the kind of thinking that happens away from a keyboard.