I build the software businesses run their day on — and, increasingly, the AI that sits inside it. Most of my work starts the same way: a process that runs on a spreadsheet, a shared inbox and one person's memory, which worked at ten a week and is quietly failing at four hundred.
What I do differently is treat the uncertain part of a system as a design problem rather than an afterthought. A model that reads an invoice will sometimes be wrong. The question that decides whether the software gets used is what happens next — whether there is a confidence score that routes the document somewhere, whether a reviewer can see the original page beside the extracted value, and whether the business can later explain why a number was accepted. That is the part demos skip and the part production cannot.
Alongside the independent practice, I have worked on applied machine learning at a foundation, backend systems for a consumer community product, and remote data science work for a company based in Canada — which is where the habit of explaining a model output in business terms came from. I am now working full-time as an AI engineer, building on that same experience in production systems, and I am also part-way through two concurrent degrees — computer science and data science — the second one being why the statistics in this work get taken seriously rather than assumed.
I work alone, on purpose. One engineer who has held the data model, the interface and the deployment in their head at the same time makes better decisions than a handoff chain, and there is nobody to point at when something is wrong.