Approach
Put AI at the centre by starting nowhere near it.
Almost every company I talk to has been sold the same idea: that adopting AI is a strategic decision, made at the top, arriving as a platform. It usually produces a pilot that demos well and dies within two quarters, because the thing being automated was never written down in the first place.
The version that works is smaller and starts lower. Find one task that a person does by hand every week, that follows the same steps every time, and that produces something another part of the business is waiting on. Automate that. Then use what it taught you to pick the next one.
Done in that order, AI stops being a project and becomes a property of how the company runs — which is what people mean when they say they want it at the centre. There is a ladder to it, and the rungs are not optional.
01The ladder
Four rungs, in order.
Each one is only possible because the one below it is done. That's the whole claim.
01
One shape
Most companies don't have a data problem, they have five front doors. A request that arrives by phone is handled one way, the same request by email another, the one filed in a client's portal a third. Nobody is doing it wrong — there was never one right way to do it.
The first move is always the same: pick the shape the work should take, then make every channel a translator into it. A form, a QR code, an inbound text, an hourly sync, a phone agent — five paths, one record at the end of each.
This is unglamorous and it is the whole foundation. You cannot measure what you can't count, you can't triage what isn't comparable, and you certainly can't hand any of it to a model.
At Innova, five intake channels now produce one indistinguishable service request.02
One source
The data is rarely missing. It's in a CRM, a job-management tool, an inbox, and a spreadsheet somebody maintains out of self-defence — and no two agree.
The pattern that works: one database is the hub, everything else feeds it, and everything you see is rendered out of the hub rather than read live from four places. Corrections made by a person are locked field by field, so fixing a phone number doesn't freeze the rest of that record in time.
And when the hub disagrees with the upstream system, it records the conflict and changes nothing. Software that picks a winner on your behalf is software you stop trusting the first time it picks wrong.
Innova's contact list holds our phone number and their email on the same person, on purpose.03
One bounded job for the model
By this point there's a shape to fill in and a place to put it, and the question becomes concrete: which single step of this is a person retyping something a machine could read?
Bounded means the model does one thing per call. Interpret this answer into this field. Pull the vendor and the amount out of this email. Classify this request as warranty or not. The surrounding workflow — what to ask, what happens next, who gets told — stays ordinary code you can read.
That's not a limitation, it's the reason it's reliable. The failure mode of a bounded job is one wrong field, caught by a human on the way past. The failure mode of an unbounded one is a system nobody can explain to a client.
Innova's phone agent calls a model once per turn to fill one field. The script stays a script.04
Ask the business questions
This is the payoff, and it's the part nobody can sell you up front, because the questions worth asking only become obvious once the answers are possible.
Which vendors actually reply. How long a warranty call really takes from first contact to closed. What we quoted this client eighteen months ago and what we said about it since. Where the same problem keeps coming back.
Getting here means the earlier steps were done properly. Skipping to it — which is what most AI pilots do — produces a demo that impresses in the room and is quietly abandoned within a quarter.
Ingesting Innova's mailbox through Graph backfills five years of history, not just today onward.
02How I build
Six things that are true of everything I ship.
These are the actual product. The code is downstream of them.
Count before you cut
The first week of any engagement is spent finding out what's actually true. Twice now that inventory has changed the plan entirely — including once where the obvious next step would have broken a live system used by real people.
Dangerous things ship switched off
Anything with a blast radius — a mass email, a push to your system of record, a delete — gets built visible and inert. Every action recorded, every output rendered for review, nothing leaving until a flag is deliberately flipped.
The database enforces it, not the interface
A greyed-out button is a suggestion. Rules that matter — who can book what, who owns which shift, who can see a phone number — are enforced where they can't be routed around.
Copy is not code
Text, prices, opening hours and service descriptions live in one place and are edited by you. If changing a sentence requires me, it will never be changed.
Say what happened
When a form fails to send it shows the phone number, not a success message. When a sync finds a conflict it says so. Software that hides its failures is how a business finds out about them from a customer.
Write down why
Every project I hand over comes with the reasoning, not just the code — what was considered, what was rejected, and what will break if you change it. It's the difference between owning software and hosting it.
03Working together
Three ways in.
Most engagements start with the first and end up at the third. That's not a funnel, it's just what happens once something ships and gets used.
The first week
Fixed fee, one week
I read what you have — the code, the accounts, the spreadsheets, the way a job actually moves through the office — and hand back a written inventory: what's true, what's about to break, and the two or three changes worth making first, in order.
Best when: You suspect there's a problem but the shape of it keeps moving.
A build
Fixed scope, quoted up front
One thing, defined, shipped to your real domain and used by real people. You get the repository, the deployment and a written record of every decision and why it went that way.
Best when: You already know what you need built.
Ongoing
Monthly, capped hours
The pattern most of this work settles into: something ships, it gets used, that reveals the next thing. Steady progress against a list you can reorder any month.
Best when: Software is now part of how the business runs.
The first week is the one
that changes the plan.
Every engagement so far has turned up something in that inventory that nobody knew was there. Twice it changed what got built.