Working together
Ten years of enterprise product work sits behind this page, from a global Linux estate to government cloud at a million API requests a minute. What I sell now is the same judgement applied to your problem, at a size I can finish.
Most of my work starts with one question: what is still manual, or still on a spreadsheet, that would take real hours and real money to get right?
Four things I get hired for
- Automating a process that is manual today. Re-keying between systems, a form that should fill itself in, an approval chain that lives in someone's inbox, a spreadsheet that has quietly become business-critical. At aZaaS I delivered enterprise business process automation products with UX, dev and QA teams; the tools on this site are the same work, smaller. This is the job where the payback is easiest to see, because the hours are already being spent.
- Systems that have to be provably right. Rules engines and calculations where being close is not good enough, and reporting where every number traces back to the record it came from. My family-benefits calculator carries 129 tests for exactly this reason; Parsnips refuses to let a model write a quotation at all, because a wrong one would discredit the whole thing. If your problem has an edge case that keeps biting, this is the work.
- Records and workloads at volume. A big pile of unstructured material that needs a system around it, and a pipeline that keeps running without anyone driving it. I have run Government Commercial Cloud platforms at a million API requests a minute at peak, grown a global Linux estate 30%, and turned an 800-page manual into 372 structured sections. Where a model is the right tool for part of it, that is part of the design, and it stops where the evidence stops.
- When compliance and day-to-day usability pull against each other. Four years holding strict IT compliance together with what people actually need to get their work done, on a global estate. A lot of internal tooling fails on this and only this, so it is worth naming early and designing around rather than discovering late.
What I'm not: I don't do design-only work, I don't run marketing, and I won't take on a project where I can't see the problem clearly enough to know when it's solved. What I take on is self-contained and clearly scoped, often weeks rather than months. There is a version of a bigger problem that fits in that shape, and it is worth a conversation to find it. If it's not a fit, I'll say so, and you'll have a straight answer quickly.