By Glenn Brouwer – CEO & Founder of Inspech
When I explain today why, at Inspech, we deliberately choose dedicated tooling for road inspection, I often notice that the conversation doesn’t really start in the present. It starts earlier. With expectations formed years ago. With promises that sounded logical at the time, but unfolded differently in practice.
That’s no one’s fault. But it does help to pause and reflect on it.
A few years ago, there was a strong belief in our domain: that it should be possible to manage the entire public space with a single system. One tool that could handle everything. Traffic signs, lighting poles, benches, pavements, waste bins, and, of course, the road surface itself. From an IT perspective, this made sense. From a management perspective as well. Fewer systems, fewer contracts, one dashboard, one source of truth.
I still understand that line of thinking. In fact, I took it seriously myself.
But road inspection did not fit that promise as neatly as expected.
A road surface is not a static asset. It changes continuously. Damage develops gradually, is highly contextual, and requires interpretation. Two cracks can look similar and still indicate something entirely different. That is what makes road inspection a profession. And that profession cannot be reduced to a generic asset category without losing something essential.
What followed was subtle, but significant. Road inspection became just another component within broader platforms designed primarily for overview, not depth. Technically, the software worked. But in the daily reality of inspectors, friction emerged. Classifications were too coarse. Context was missing. Corrections took time. Too often, the system felt like it was adding work rather than reducing it.
For inspectors, this was frustrating. Not because they resist digital tools, but because their expertise was not being properly supported. For organizations, a different issue arose. Reports became harder to explain, more difficult to defend, and more likely to trigger discussion than decision-making. In a domain where safety, liability, and public funds intersect, that is not a minor issue.
Gradually, a sense of caution set in. Not just towards software, but towards AI as well. Many of these platforms were — explicitly or implicitly — positioned as “smart,” “automated,” or “the next step.” When those promises fell short, what remained was something I consider entirely reasonable: skepticism.
That skepticism lasted a long time. And frankly, it was justified.
What I find interesting is what we are seeing now. Conversations are opening up again. People are willing to take another look. Not out of excitement, but out of cautious curiosity. Something has shifted in how we collectively perceive AI.
The widespread public adoption of generative AI has played a role in that shift. Not because generative AI directly relates to road inspection (it doesn’t) but because it challenged a core assumption: that AI simply doesn’t work in practice. Apparently, it can. And that creates space for nuance.
What helps is that the conversation has changed. Less about replacement. Less about all-in-one solutions. More about support. About explainability. About control.
Perhaps that is the most important lesson of the past years. Not every form of efficiency can be scaled. And not every scalable solution is responsible. Road inspection is not a niche because it is small, but because it is deep. It requires tooling that acknowledges that depth. Tools that strengthen the profession rather than abstract it. Tools that help inspectors work faster without removing judgment from the process.
Looking back today, I don’t see failure. I see a learning phase. A period in which we pursued something that seemed logical, but ultimately did not do justice to the complexity of the field. I understand the caution that followed. And that is precisely why I believe it is important to keep telling this story.
Not to prove a point. But to better understand why trust takes time.
And why, in certain domains, dedicated tooling is not a luxury, but a prerequisite.