Ten years leading product at Orange, Fiserv, BNP Paribas and Aragon — now building and operating the systems myself, directing an AI engineering team. The three most recent are in production, and real money moves through two of them.
Most consulting ends at the deck. Mine ends at a deploy — automated trading on funded accounts, a CRM a field crew opens every morning, campaigns that launch themselves when a storm crosses a postcode.
The difference matters because software only reveals its real problems once it is carrying weight. A broker's API that under-reports a position, an order that silently refuses to cancel, a margin figure the vendor documents but never sends — none of that shows up in a workshop.
I direct a team of AI engineering agents the way I used to direct people: I own what gets built and why, they own how, and every change is read by a human before it moves.
Design, implementation and adversarial review run in parallel — one agent builds, another tries to break the result. It is the reason a single person can carry three production systems, and the reason the work still gets reviewed like a team's.
Every fix starts with a test confirmed failing, and every claim traces to a production log quoted rather than paraphrased. When something cannot be proven, it gets said plainly instead of dressed up.
That discipline is what let me show a broker that their own API returned two different values for one position fifteen seconds apart — with timestamps their support could not dismiss. Anything touching money stays behind a human gate.
All three end the same way: something running in production that somebody depends on, and a person who knows how to keep it there.
An idea, a spreadsheet, or a process that only works because one person remembers it. I take it to a deployed system — and then keep operating it: releases, monitoring, the unglamorous parts nobody quotes for.
Typically 6–16 weeks to first productionSix months in, no deploy, and everyone is still polite in the status meeting. I read the code as it actually is, name what is really blocking it, and get a working version in front of users before we argue about the rest.
Starts with a two-week readFor teams adopting AI engineering and finding that speed arrived without correctness. I set the gates: what gets specified, what gets tested, what a human must read before it ships, and what never runs unattended.
Fractional, part-timeTerms. Fixed price per feature when the scope is clear; hourly when it genuinely is not. Your repository, your cloud accounts, your keys — the work is yours from the first commit, and nothing about it depends on me staying.
Ten years of shipped software sits behind these — telecom, payments, identity, open-source infrastructure. What makes this three worth showing is that I still operate them: not pilots, not prototypes, and each has users who notice within minutes when it stops.
A ladder engine placing, chasing and cancelling live orders around the clock on funded accounts, with a risk layer whose hardest gates stay in human hands, and a dashboard three people use to watch their own money.
The operating system for a Chicago disaster-restoration company — jobs, crews, documents and insurance claims in one place, with a native Android app the field teams carry. Built beside the owner over months, not delivered against a spec.
A hailstorm crosses a postcode and minutes later the contractors who serve it are advertising there — national weather alerts driving Google Ads campaigns automatically, with prepaid wallets so a customer can never overspend.
A client's dashboard showed one contract open. His broker's own platform showed eleven. Somebody was wrong, and the only way to find out who was to stop guessing.
The obvious suspect was our code, so that is where I started — and four of the five contracts reconciled to the lot. That is the point where most investigations declare a rounding problem and move on.
Instead I put a line in the log next to the number, recording what the position feed actually returned each time it was read. Fifteen seconds apart, for one unchanged position, the vendor's API returned two different quantities. One row. Nothing skipped.
That turned an argument into a report the broker could not wave away, and it changed what we built next: the platform now computes the net position from our own recorded fills, and treats the vendor's number as a claim to be checked rather than a fact to be trusted.
A number you cannot reproduce is not a measurement. It is a rumour with a timestamp.
12:03:25 positions acct•••••••net=18.0 12:03:40 positions acct•••••••net=1.0 rows emitted ....... 1 rows skipped ....... 0 our fills tape ..... unchanged
The point of every step below is that you can tell, without reading code, whether the thing is on track.
One page before anything else: what changes, for whom, and how we will both know it worked. If we cannot write that page, the project is not ready and no amount of building will make it ready.
A written plan goes first — the files, the order, the migrations, what could break. You approve that. It is the last moment where changing your mind is free, so it is the moment worth spending.
Small branches, screenshots, and a running preview you can click today. No month-long silences and no demo that only works on my machine.
Every fix begins with a test confirmed failing, so a passing test means something. Claims quote the log rather than paraphrase it. Where something cannot be proven, that gets said in those words.
Deploys, monitoring, migrations, the on-call. Anything that moves money or touches a customer stays behind a human gate — automation gets to prepare the action, a person still takes it.
Regulated payments, identity, telecom and open-source infrastructure — most of it in teams where a bad release had consequences. The three systems above are the current ones, not the first ones.
If the answer below is a problem for you, better to find out now than in week six.
It is, if nobody reads it. So the gates are the product: a written plan before code, a test confirmed failing before a fix, an adversarial review whose job is to break the change, and a human reading every diff before it moves. Speed comes from running those steps in parallel, not from skipping them.
You do, from the first commit. Your repository, your cloud, your keys, your vendor contracts. If we stop working together the system keeps running and another developer can pick it up — that is a design requirement, not a courtesy.
Fixed price per feature when the scope is genuinely clear, hourly when it is not. I would rather quote a fixed price on a small first slice than a large number on a vague one, so the first engagement is usually deliberately small.
No. I build and operate the platform; every position-level decision belongs to the account holder. Exchange access on my side is read-only, and I do not give investment advice — the trading work here is software engineering, not money management.
Strategy decks with no build attached. Staff augmentation where somebody else owns the outcome. And any project where nobody can say what "done" means — I will help you define it, but I will not start building before we have.
Austin, Texas — US Central time, authorized to work in the US, and a decade of it spent in European delivery teams, so a spread-out timezone is the normal case rather than the exception. Written updates by default; calls when a decision needs one.
Vague requirements, messy data, everyone agrees it should be automated and nobody has started. That is the one worth doing.