Software for municipalities supports civil affairs, permits, taxation, public services and internal operations. Choosing it means considering an interconnected application landscape. Sometimes a standard package fits; sometimes an existing configuration needs changing or a separate integration is required. This guide concerns Dutch municipalities and helps define the question before comparing suppliers. Our guide to custom software covers the broader decision.
What software does a municipality need?
A municipality needs applications for its tasks and the information exchange around them. A resident sees a form or appointment, while staff assess the request, consult records and retain documents. When replacing software, consider that whole action, including what will continue outside the new system.
The following breakdown is a practical starting point for an inventory, rather than a requirement to buy a separate package for each row.
| Area | Examples of work | Question when making a change |
|---|---|---|
| Civil affairs | Resident records and related applications | Which registers and shared services are needed? |
| Public services | Forms, appointments and customer contact | Can a resident complete the whole task? |
| Permits, supervision and enforcement | Assessing applications and recording inspections | Which information must be shared between the parties? |
| Social services | Support requests and their administration | Who may use which case information? |
| Taxation and finance | Levies, payments, budgeting and accounts | Which source determines amounts and statuses? |
| Case and information management | Records, documents and archiving | How will information remain findable and usable? |
The Dutch context matters. Statistics Netherlands records 342 municipalities on 1 January 2026. Their arrangements, partnerships and operational capacity differ. Test against your own process rather than relying solely on another municipality’s reference.
How do you use the GEMMA Softwarecatalogus?
The GEMMA Softwarecatalogus contains software offerings, supplier information and applications and connections recorded by municipalities. Suppliers describe functionality, plans and supported standards. Municipalities can use the information when considering replacement, comparing options and drafting requirements.
Treat a listing as a starting point for investigation. Check which product version it describes, whether a feature is already available and what evidence supports the required standard. A listing isn’t itself an acceptance test for your environment.
For civil affairs, examples include Centric Burgerzaken and PinkRoccade’s iBurgerzaken. Centric presents its current product as a renewed version of Key2Burgerzaken. These examples aren’t a ranking or evidence of market share across all municipal software.
Should you choose a package, an integration or custom software?
Compare approaches for the same complete task. Adjusting an existing package may be sufficient. An integration can transfer information, but won’t automatically resolve unclear responsibility for a case. Custom development can fill a functional gap and brings its own maintenance and operational work.
| Approach | Investigate it when | Have the supplier demonstrate |
|---|---|---|
| Adjust existing configuration | The function exists but the working method doesn’t fit | That the changed journey handles exceptions too |
| Introduce a standard package | The package supports the required task | Behaviour, migration, integrations and operation in your context |
| Add an integration | The action fits but information transfer is missing | Access, result checking and recovery after failures |
| Build a custom component | A required function isn’t sufficiently supported elsewhere | Scope, maintainability, handover and acceptance |
Consider reuse with other municipalities too. Joint development can be worth investigating, but needs agreements about priorities, funding and support. Open-source code doesn’t remove those organisational questions.
How does Common Ground affect the decision?
Common Ground aims to separate information from the processes using it. The original VNG vision describes layers for interaction, process control, integration, services and data. It’s an architectural vision, rather than an installable product or a guarantee that every package connects immediately.
Translate that idea into questions for your assignment. Which register remains authoritative? Through which agreements and interfaces may the new application use information? Who maintains the integration, and what happens if the source is temporarily unavailable?
Ask which standards and versions are actually supported. ‘It has an API’ doesn’t establish whether the required information is available, whether writing is permitted or what conditions govern access. Our guide to connecting software discusses checks around that transfer.
How do you test an entire process with an example?
Consider a hypothetical report about a public space. A resident submits a form with a location and perhaps a photograph. The report reaches the responsible team, and the resident later wants to know what’s happening. This is a design example, not a TopDevs client case.
Have the supplier demonstrate the journey from receipt to closure. Is only one report created if someone presses submit again? Which status does the resident see if the receiving system can’t be reached? Who can correct an inaccurate location?
Check the end of the process too. Does required information remain available for records management, and is it deleted or transferred according to the agreed arrangements? Involve the person responsible for archiving. A functioning form doesn’t establish that the whole process works.
Our guide to client portals provides further design questions about tasks, permissions and statuses. For resident services, adapt those questions to the public responsibility and intended audience.
Which requirements should you consider from the start?
Agree with the responsible people which security, privacy and information-management requirements apply. Specify who may consult information, which actions are recorded and how recovery is tested. The supplier should show what the product supports and what the municipality must configure or organise.
For public bodies’ websites and apps covered by the Dutch accessibility decree, Digitoegankelijk describes obligations concerning accessibility and a published accessibility statement. Include assessment and corrective work in the plan. An accessible template doesn’t establish that the whole service, including its content and forms, is accessible.
Include users in acceptance. Have people complete the task using a keyboard and assistive technology, and investigate where guidance or support is missing. Agree who will check new content and later changes. Delivery isn’t the last time the service will change.
Which procurement procedure applies?
Have procurement staff determine the appropriate procedure for the assignment and applicable rules. PIANOo lists the 2026 and 2027 European threshold for ordinary supply and service contracts for sub-central authorities as €216,000 excluding VAT. Reaching the applicable threshold requires the European procedure. Being below it doesn’t automatically permit directly selecting a supplier.
Consider the whole estimated contract. PIANOo explains that its valuation includes the contractor’s expected income from the award. Ask procurement to establish what must be counted. A small initial development phase isn’t itself a reason to exclude the follow-on assignment.
Keep the technical trial and procurement decision separate. A successful demonstration establishes a defined technical capability; it doesn’t decide who may receive the final contract.
How do you compare costs and preserve handover options?
Compare costs over the same period and for the same service. Include implementation, licences, integrations, migration, testing and operation. Budget for staff involvement and temporary parallel use of old and new systems. Our guide to software costs helps make scope visible.
Also agree which information, documentation and rights remain available at termination. For standard software, consider usage rights and exports; for custom development, include source-code rights and component licences. An open API or code ownership doesn’t automatically make switching straightforward. Our guide to code ownership addresses the practical handover.
How do you actually get started?
Choose one complete public-service task and describe where it currently fails. Map the systems, information sources and responsibilities around it. Have staff, architecture, procurement and relevant specialists agree what a solution must demonstrate.
Want to investigate whether building custom applications fits a missing part of that process? Book a call to discuss the technical scope.
