How I run a project
The Built Method
Most technology projects fail for the same reason: nobody agreed in advance on what success would look like, so everything gets declared a success.
Five steps. The fourth one is why clients call me back.
1. Find
The bottleneck you describe is rarely the bottleneck you have. I interview your people, watch the actual workflow, and review the systems before recommending anything.
2. Quantify
Every problem gets a number: dollars, hours, revenue at risk, compliance exposure. If a problem can't be quantified, it doesn't move forward. That alone eliminates most "AI opportunities."
3. Build
The smallest thing that could plausibly move that number. Weeks, not quarters. Real system, real data, real users — not a demo.
4. Validate
Before any build work starts, we agree in writing on a single number that defines success, how it will be measured, and over what period.
When the period ends, I write down whether it hit. If it didn't, my recommendation is to stop — in writing.
That's a successful engagement. You paid to find out, you found out, and you didn't spend the next eighteen months funding something that doesn't work.
5. Scale
Only systems that proved out earn more investment. Then we roll it across locations, harden it, and hand it over — you own the code, the accounts, and the documentation. You're not renting it back from me.
Section 02
Why you can believe the fourth step
I run this on my own work.
I built a predictive model, ran it for a season, and it looked excellent. Then I found a defect in how outcomes were paired to predictions. I fixed it, re-scored the full season honestly, and the edge inverted — the model was losing, not winning. I turned it off and left it off.
Separately, I ran a second model in shadow mode across 125 real events before letting it touch anything. It came in at 52.1% against a break-even of roughly 52.4%. Close enough to look like a win. I suppressed it.
Nobody was paying me to be honest about either one. That's the point.