Ask what your consultant has built themselves

Twenty years in the car business taught me to tell two kinds of salespeople apart.

One knows the brochure by heart. The other has stood in the workshop and knows which models come back, and why.

Both will answer your questions well. Only one knows what the answer costs.

Technology advice works the same way. Most people selling AI advice have never had to live with it. They deliver a report, present it, and move on to the next client. Whether the recommendation survives contact with production is somebody else's problem.

We do it the other way round, deliberately.

Alongside the consulting, we build and run our own products. Real software, for a regulated market, with customers who expect it to work on a Tuesday afternoon. That means being on call, security updates, privacy, support, and all the dull things that never make it into a presentation.

We've also built our own internal tools instead of buying them. Our own customer system. Our own booking system, replacing one we used to pay for. Our own support flow.

The point isn't that we enjoy building things. The point is what you learn from having to run them afterwards.

When we swapped the bought booking tool for our own, we learned exactly what that trade costs — in both directions. We saved a licence and got something shaped to how we actually work. We also took on responsibility for the calendar syncing, the email going out, and somebody being there to fix it when it doesn't.

That's a calculation I can now do for you with numbers instead of assumptions. When I say "don't build this yourselves", it's because I've paid for that lesson.

In August we ran a security review of our own systems — the same kind we recommend to clients. It found a door standing open. We thought we'd closed it in June, but the fix hadn't done what we assumed it did. Nothing private sat behind it, and it's closed now.

But notice how we found it: not by reading our own documentation, which looked entirely correct. We found it by measuring the system that's actually running.

That distinction isn't academic. It's why we now test differently than we did in spring — across every product, not just the one.

That's how knowledge actually arrives. Not in a report, but in the moment something you were certain about turns out to be wrong.

For you as a client, it comes down to this: when we recommend something, we've usually done it ourselves first. We know how long it takes, what it costs to maintain, and where it tends to break.

And when we advise against something, it's usually because we've tried it.

Ask about it next time you're sitting across from a supplier. Not what they know. Ask what they've built themselves, and what they still run.

The answer tells you more than the reference list.