FIVE SERVICE AREAS
WHAT I TAKE ON.
Five areas of work, described in enough detail that you can tell whether your project is one of them. Most engagements are a combination of two.
//Why these five#
They're the things I've done often enough to estimate accurately. That's the whole selection criterion. I can build a competent backend and I've shipped a React Native app, but I'd be guessing at the schedule, and a guessed schedule is worse than an honest refusal.
In practice briefs don't arrive neatly labelled. A performance engagement almost always turns into a design system conversation, because the reason a page ships four hundred kilobytes of JavaScript is usually organisational rather than technical. A WebGL piece needs interface engineering around it, or you have a beautiful scene with no way to navigate. I scope for the overlap rather than pretending the boundaries are clean.
//What's constant across all five#
Measurement before opinion. I'd rather spend two days instrumenting something than two weeks optimising the wrong layer, and I've done the second often enough to have learned it properly. Everything I hand over comes with the measurements that justified the decisions, so the next person can tell what was reasoned and what was taste.
The second constant is that I write things down. Decisions, rejected alternatives and the reasons for both. Code explains what a system does; it's nearly silent on what it deliberately doesn't do, and that's the knowledge that disappears when someone leaves.