Skip to content
AI & Insurance · July 30, 2026 · 10 min read

Insurance software 2026:
the broker becomes the supplier

Two brokers are building the software their peers have been waiting for — and I think that's the start of a broader shift.

🤖 Agent-friendly (.md)
Illustration for article: Insurance software 2026: the broker becomes the supplier

TL;DR

  • Two brokers on the AM front page within six weeks. Henry de Cock and Mark van Maurik are building AI software for brokerages — and the trade press put both on the cover.
  • The build barrier has collapsed. Gartner predicts that by 2028, eighty percent of tech products will be built by non-professionals. Domain knowledge now outweighs code.
  • The advantage a software house cannot buy: being the target audience. A zero-day feedback loop on real clients and real policies.
  • Piggybacking is not a free lunch. Ask the same GDPR, security and continuity questions you would ask any software vendor — even a peer competitor.
  • The shift is coming from within. Not big tech or insurtechs, but the established vendors' own customer base.

Two brokers are building the software their peers have been waiting for — and I think that's the start of a broader shift.

Over the past two years I've built more working software than in my previous 35 years in insurance, without a team and without a development budget. A scanner that checks websites against legal requirements, a tool that assesses claims from photos, a Chrome plugin for forms, my entire blog site.

And this summer I saw two peers in AM (opens in new window) doing the same thing — only with a business model attached.

Two front pages in six weeks

On 18 June 2026, AM (opens in new window) profiled Henry de Cock of Alblasserwaardsche Verzekeringen, by his own description an average brokerage. De Cock builds AI agents on top of his existing CRM package. In what he says was two hours, he built a tool that turns payment reminders into personalised emails, and he lets other firms piggyback on what he builds. His estimate: eighty percent of brokerages look like his. What works for him works there too.

Six weeks later, on 30 July, the next builder appeared in AM (opens in new window). Mark van Maurik, a insurance broker for over thirty years, built Advey.ai — an intelligence layer for brokerages. His tool writes client emails after meetings, drafts advice reports, checks documents and compares policy terms. According to the article, more than 85 firms use the solution two months after launch. A time saving of around seventy percent on daily routines is what Van Maurik calls realistic.

I deliberately write "by his own account" and "according to the article." All these figures come from the builders themselves, recorded by a single journalist. That doesn't make them false, but it does make them unverified — and that distinction deserves to be named. For the point of this piece, the exact time saving barely matters. What matters is the pattern: two people from brokerage practice are building software for their own peers. And the trade press put both on the front page within six weeks.

Zooming out: this is broader than two firms

Two cases aren't a trend yet, so let's zoom out. Gartner predicts (opens in new window) that by 2028, eighty percent of tech products will be built by people who aren't professional developers. The share of builders with a non-technical background rises, according to that same forecast, from twenty to forty percent. At Vercel's v0, 63 percent of more than four million users aren't developers, Mercury (opens in new window) reports. And at Lovable, four in five users say they hold a non-technical role.

The explanation is simple: the build barrier has collapsed. Tools like Claude Code, Cursor and Lovable translate domain knowledge straight into working software. A computer science degree no longer has to sit in between. I wrote earlier that anyone can build, but not everyone has something to say. De Cock and Van Maurik are the industry version of that. They do have something to say, because they spent decades inside the processes their software now touches.

And with that, the power balance in the software market tilts. For twenty years the sequence was fixed: a software company builds a package, and firms adapt their working methods to it. Van Maurik names that mechanism himself in the AM article. Most tech companies develop something first and then ask firms to adapt. His approach reverses that, because his AI follows the broker's routines rather than the other way round. He can only do that because he executed those routines himself for thirty years.

The advantage a software house cannot buy

This is the core of why I think this will grow beyond two sympathetic pioneers. A software house can hire developers, recruit product managers and run customer panels. But one thing it cannot buy: being the target audience. De Cock tests his agents every day in his own office, on real clients, real policies and real payment arrears. Every irritation he feels is one shared by eighty percent of the market, if his estimate holds. His feedback loop lasts zero days. A traditional software house's loop runs through account managers, tickets and release schedules.

There's something else I think is typical of the insurance sector: the "conculega" culture — competitor-colleagues. In few industries is it so normal for competitors to cooperate. Brokers have shared service providers, purchasing combinations and binding authority structures for decades. They call each other conculega's, and that word barely exists in other branches. In that culture, building software for your direct competitor isn't taboo — it's a logical business model. That's exactly why a broker from the Alblasserwaard can let other firms piggyback without anyone finding it strange.

The sector thus has two properties that accelerate this movement. Thousands of small firms run almost identical processes, and there is a culture of buying from each other. Add AI tools that remove the build barrier, and you get what we're seeing now.

Two builders, two routes

Interestingly, the two builders choose very different routes, and that difference tells you something about where this movement can go.

De Cock builds agents on top of the systems he already has. He doesn't replace his CRM — he puts his own layer over it. What he makes he shares informally with firms that ask, while his brokerage remains the main activity. The AM article summarises his ambition under the headline "improve without depending on software companies." His model is that of the building craftsman: the tool serves his own firm, and others piggybacking is a by-product.

Van Maurik went a step further and turned it into a product company. Advey integrates with common packages like Figlo and FasterForward, and according to the article also works stand-alone for firms without a CRM. He's growing toward a hundred connected firms. That's no longer a by-product — it's a software supplier in the making. That comes with everything: releases, support, a pricing model and the duty to keep developing as long as customers pay.

Both routes are legitimate, but they demand different things. The craftsman route mainly asks for curiosity and time. The product route also asks for everything software companies derive their right to exist from: continuity, security, documentation and the discipline to keep building when the initial fun wears off. My estimate is that over the coming years we'll see far more De Cocks than Van Mauriks. The first route is low-threshold; the second means a career switch. For the software houses, that's little comfort. Even a thousand building craftsmen plugging their own gaps means a thousand firms less dependent on their vendor's release schedule.

Follow me on LinkedIn

Follow my updates on AI, strategy and entrepreneurship on LinkedIn

The establishment already feels it

The most interesting detail in the De Cock article sits almost casually near the end. Max Mouwen, CEO of ANVA, recently promised to innovate more in the next three years than in the 25 years before. I read that sentence twice, because there's so much in it. An established software house that has carried brokerage administration for decades promises to do more in three years than in the quarter-century before.

You don't make statements like that when things are going smoothly. You make them when you see your customers around you starting to build, and you know every month of delay produces another Henry or Mark. The AM editors dryly noted that that promise need not be reserved for the software giants alone. That's exactly the point.

Anyone who predicted in recent years who would shake up the insurance software market almost always looked outward. Toward big tech entering the market, toward insurtechs capturing distribution. I think we looked the wrong way. The shift is coming from within — from the software houses' own customer base. The customer who waited twenty years for release schedules is no longer waiting. They're building themselves.

What this means if you run such a firm

Does this mean you should cancel your package vendor tomorrow and piggyback on a peer's tool? No — and here I step back from my own enthusiasm for a moment.

Software from a fellow broker is still software, with everything that comes with it. The Veracode GenAI Code Security Report (opens in new window) found that 45 percent of AI-generated code contains security vulnerabilities. A broker who builds a tool in two hours rarely has a security team, a test protocol or a failover plan.

And then the side that weighs heaviest in this profession: the data. Such a tool processes client conversations, policy data and sometimes medical or financial information — which makes it no longer a handy trick but a processing activity under the GDPR. Then you want to know exactly where that data sits, in the EU or outside it, and whether a data processing agreement is in place. You want to know which AI model produces the transcript of a client conversation, which model does the translation or summary, and whether that provider uses your client data to train its models. And you want to be able to explain that to your client too, because they sit across from you in the advice meeting — not across from the tool's builder. If the builder can't answer those questions, the tool by definition fails this industry's requirements, no matter how well it works. You as a firm remain responsible for the processing, and how sympathetic the builder is doesn't change that.

There's also a continuity question I miss in both articles. What happens to Van Maurik's 85 firms if he sells in three years to a party that triples the prices? And what do De Cock's piggybackers do if he ever stops? Anyone who takes an ANVA package trades freedom of movement for certainty. Anyone who piggybacks on a peer's tool does exactly the opposite. I wrote earlier about vendor lock-in with AI providers, and that analysis applies fully when your supplier happens to also be your competitor. Worse: your new supplier then looks into the processes with which you serve your clients.

So ask the questions you'd ask any software house. Where does my data sit, who has access to it, what happens in a data breach, what's the exit scenario, and who maintains this in five years? Those questions feel awkward toward a peer you meet at a conference. That's no reason not to ask them.

And if you want to be that builder yourself

The reverse lesson is at least as interesting. A self-described dead-average firm from the Alblasserwaard can do this, and a broker with thirty years of practice experience binds 85 firms to himself within two months. Then this is the question for every broker with a bit of technical curiosity: which problem do you solve manually every week that a thousand other firms also struggle with?

My own experience is that the building itself has become the easy part. My tool that assesses claims from photos cost me at most four hours of work. The scanner that checks websites against legal requirements took around sixteen hours — more involved, but it saves me at least €300 a month compared with what I'd pay if I bought this externally. It doesn't happen entirely by itself, by the way. You need to set up an API, configure a database and roughly follow what's happening. AI takes most of that work off your hands, but it helps if you understand what's being built. And if you don't understand something, you simply ask AI to explain it.

I described earlier a world of software on demand, where you ask for software and it exists. What's scarce is no longer the code, but the domain knowledge that determines what should be built. And that's exactly the one thing you have more of, after decades in this profession, than any developer in Amsterdam or San Francisco.

The two men from the AM articles understood that before the rest. They're now becoming the software suppliers of their own sector, while the established houses promise to cram 25 years of innovation into three. Watch over the next twelve months who else stands up. The third and fourth builders are somewhere comparing policy terms right now, thinking: there has to be a smarter way.

I thought the same two years ago. It cost me a laptop and a subscription.

Sources