How municipalities pay twice for their software

The biggest cost for municipal software? It's rarely in the quote. Unfortunately, municipalities only discover after a few years that they're spending far too much money on their supplier.

A software tender usually follows a fixed pattern. The municipality wants something specific. A new case management system (zaaksysteem), document management system, or integration platform. A list of requirements follows. Suppliers present their solution and prices, functionalities, timelines and implementation are compared with one another.

Very concrete elements, which fit into a decision-making process where you need to justify costs. And during demos and implementations, this kind of product often runs wonderfully smoothly. The problems tend to arise later.

When you suddenly start to feel the dependency

Take a municipality that introduces a modern case management system. Applications, documents and statuses are all neatly organised together. Staff no longer have to search, and managers finally get dashboards they can use. Everything looks sleek and well organised. A year in, an additional need arises.

Residents should be able to track the status of their permit application in real time through a portal. Just like tracking a parcel from the postal service. Or the municipality wants to combine documents from different systems to automatically summarise applications and handle them faster. In theory, that sounds straightforward. After all, the data is already there. In practice, that's often where the trouble begins.

It then turns out, for example, that document metadata is only usable within the platform itself. Workflows use their own statuses. Reports rely on fields that don't exist outside the system. The document management system uses different definitions than the case management system. And the customer contact system speaks yet another language.

So, exports need to be built. Then translation steps between systems. Then new integrations. And as soon as one supplier changes something, the whole circus starts again.

What started as an extension of service delivery grows into a separate IT project.

And that's exactly where the hidden costs of dependency appear.

Why this is almost unavoidable

The uncomfortable truth is: this usually isn't caused by bad software. It's precisely successful platforms that create dependency.

Suppliers build their platforms, understandably enough, so that everything within their own ecosystem works together smoothly. That makes implementations attractive, but it also means municipalities find it increasingly difficult to move outside that ecosystem later on. Municipalities benefit from this at first, until they want to move beyond that ecosystem.

Then it becomes clear how tightly processes, integrations, reports and ways of working have become intertwined. After a few years, it's not just software running on the platform, but a large part of the municipality's way of working too.

And then the second bill arrives. Purely for the consequences of choices made earlier. Because a municipality has unknowingly built a landscape in which everything has become dependent on everything else.

Comparing scenarios instead of prices

When choosing software, municipalities still often look mainly at today's situation.
Does the system work well? Does it fit the budget? How quickly can it go live? It gets more interesting once you look a few years ahead.

What happens if a municipality wants to give residents real-time insight in three years' time? Or if AI needs access to objections and permit applications? Or when a supplier needs to be replaced while dozens of integrations are tied to the platform? Then the comparison changes.

Imagine you have a choice between two solutions. Today they look very similar, but in the longer term they can differ enormously in cost and room to manoeuvre.

With one solution, data remains relatively accessible and integrations stay flexible to adapt. With the other, new layers of middleware, customisation and dependencies appear as soon as something changes. During a slick demo, you don't see that difference. But once you're using it, you feel it.

The most expensive software is often not in the quote

So municipalities pay for licences, implementation and management in software projects. But the biggest costs often only appear afterwards, when:

• integrations need to be rebuilt
• data isn't easily reusable
• suppliers raise their prices
• migrations turn out to be more complex than expected
• new service delivery gets stuck on existing systems

Often these scenarios aren’t exceptions.

And that's while municipalities have to deliver more digital services with less budget and less capacity. Meanwhile, residents expect a government that works just as smoothly as commercial platforms. No one understands any more why a parcel can be tracked in real time, while a permit application can vanish into a digital black hole.

Yet municipal systems are often still stuck in architectures designed primarily for stability within a single platform. Every change requires fresh budget, customisation and external expertise. And so, step by step, a municipality pays again for the same software choice.

A broader view of cost

Municipalities now often pay twice for software. First on purchase, then again once changes start costing money. There is a different way. Set up your IT landscape so that new service delivery doesn't become a multi-million-euro project. Because software is meant to make change possible, not to hold it back.

At WeAreFrank!, we look at integration and software choices the same way. We don't just ask: “Does this work well?” We also ask: “How much freedom will you have left later?”

Can you replace systems without huge migrations? Can you keep using data outside a single application? Can you adjust integrations without launching an entire project? And can you collaborate with other municipalities without rebuilding everything from scratch?

These are not theoretical architecture questions. They're questions that determine how much public money a municipality will have to spend again later.

Because that's exactly where things often go wrong. Municipalities first pay for software that supports their processes. And then pay again once that same software makes change complicated.

The real question about software isn't what it costs today. The real question is how much it costs once you want to change something later.