01
Week 1
Frame the problem
Interviews with the people closest to the pain, a read of support tickets and analytics, then a written problem statement we both sign off on.
Process
How the work actually happens
Predictable steps, written artefacts and small releases — so progress is visible from week one.
- 02
Week 1 — 2
Model the domain
States, edge cases and permissions mapped before any UI. Most interface complexity is really unresolved domain complexity.
- 03
Week 2 — 3
Prototype narrowly
One clickable path through the riskiest flow, tested with real operators, so we learn before committing to engineering time.
- 04
Ongoing
Ship behind flags
Small, reviewable pull requests with tests, released progressively so rollout risk stays boring and reversible.
- 05
Final week
Measure and hand over
Before-and-after numbers, documentation, and a walkthrough session so the team owns the work after I leave.
Principles
What stays constant
- Reduce scope before adding people.
- Accessibility is part of done, not a later ticket.
- Written updates every week, no status meetings required.
- Leave the codebase easier to change than I found it.
Feedback
What partners say about it
“Adrian is the rare engineer who reduces scope and increases outcomes. Our console shipped early and support tickets fell by half.”
“He made accessibility non-negotiable without slowing us down. The system he left behind still guides every release.”
“Clear communication, careful trade-offs, zero drama. He is the first person I call for a critical build.”