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. That pull is like gravity, I feel it every single time.
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 Real Risk Isn’t Building Slowly. It’s Building Wrong.
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 doesn’t move the needle for 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. It’s the difference between a tool that works and a tool that makes a difference.
Let’s Build Something That Matters
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. Ready to start with clarity instead of guesswork?
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 →
Because the fastest way to build something valuable is to know what valuable looks like before you start.
