When I talk with clients about tech projects, I talk about Return On Investment (ROI) before I ever talk about the actual technology.
I do this to solve a problem most engineers don't even acknowledge: we love building the wrong thing really well.
I'm an engineer at heart, and my first instinct when you bring me an AI project is to open the tools and start building things.
But 25 years of experience building technology - and making every mistake it's possible to make along the way - has taught me that instinct to go straight for tools can completely derail a project before it even starts.
So I've built a different process for how I work with clients. And if you want to work with me, you need to understand that the most important engineering work happens before we write a single line of code.
It's the Technical Spec for Your Business
I work with some real engineers* - they build massive civil works like wind farms.
(* much as I hate to admit it, software engineers aren't real engineers, we rarely build anything with life or death stakes)
When a civil engineer builds a bridge, they need to know the load it's meant to carry. Foot traffic, regular cars, or 12-axle trucks carrying 85-ton windmill nacelles? Is it crossing a small stream or a wide river? Those answers determine the design.
Building an AI or automation system works the same way.
When a client wants to skip the boring business talk and get to the cool tech stuff I'll say:
"You're right, let's not waste time. Think of this part as the technical spec - but for your business."
Are we trying to save 10 hours a week or 50? Is 95% accuracy good enough, or do we need 99.999% because the cost of a single mistake is huge?
Those answers shape everything: the tools we choose, the model architecture, and how we measure success.
Bad Requirements Waste Good Money
Only two of them were actually costing real money - about €25,000 annually in staff time. The other 6 were edge cases that happened a couple of times per month.
Without that 20 minute conversation, we could have built a €50,000 system to solve a €25,000 problem. Worse, we could have over-engineered it to handle all 8 scenarios when we only needed to nail the two that mattered.
Instead, we built exactly what they needed. It paid for itself in a couple of months.
This is what happens when you treat ROI as an engineering input instead of non-essential "sales talk".
The Risk Is Building the Wrong Thing
I've seen where AI projects go wrong. Almost every failure follows the same pattern:
- The tech stack works perfectly.
- The AI does exactly what we told it to do.
- But it makes no measurable difference to the business.
The technology didn't fail. The requirements did.
By focusing on the ROI first, we de-risk the entire project and prevent this happening.
Book an ROI Mapping Session
When you're ready to build, I'll ask you to talk about your business first. Not because we're avoiding the technical work - it IS the technical work.
Those 20 minutes of ROI mapping save months of building in the wrong direction. Mapping the value is the first half of the job. The second half is whether your team expects to see any of that value themselves. That's the subject of Who gets the time AI saves? The measurement problem behind it is where is the ROI from AI.
Book a free ROI mapping session. It's a 20-minute call where we'll:
- Quantify the specific problem you're solving.
- Map the value your solution needs to deliver.
- Define what success looks like in measurable terms.
You'll walk away knowing exactly what you're building and why - before I write a line of code.
Book your free ROI mapping session