Introduction
Software should solve the problem, not preserve it. I fix the process before I write the code.
Most of my work starts before the code: understanding what a flow is for, who depends on it, and where it actually breaks. A small proof of concept settles the argument; the ones that earn their keep get hardened, shipped, and kept running in production. The habits nobody remembers choosing, like double approvals and forms that feed nothing, get removed rather than automated. Bureaucracy encoded in software is still bureaucracy, just faster.
How I work
Patterns I look for the pattern behind the one-off request. Solve it once, express the variations as metadata, and the solution scales by configuration instead of rewrites.
Ship A proof of concept is a question, not a deliverable. What survives contact with real users becomes a product: monitored, documented, and running in production.
Flow I walk the process end to end with the people who run it. The gap between the official flow and the real one is usually where the problem lives.
Users The measure of a solution is the person using it on a normal Tuesday, not the architecture behind it. If their day didn't get easier, it doesn't count.
Now
Building an AI-assisted review tool for a regulated workflow platform, where outputs have to be reliable and auditable, not just plausible.
Migrating a legacy system in financial services: new domain model, data flows, and integrations designed while the old system stays in production.
Working on identity and access across generations of systems: authentication that has to hold between platforms that were never designed to meet.
Exploring distributed consistency and long-running workflows, the transactions that have to hold across system boundaries.