Custom permit registration software.

A permit management system is the system in which a government organisation records and supports every step of a permit: from the application by a citizen or business, through substantive assessment by one or more disciplines, to the decision and issuance of the permit, the publication of the decision and, where the decisions give rise to them, the handling of representations, objections and appeals. It is not an administrative afterthought, but the working heart of permit processing.

We design and build these systems to measure. Not as a closed package where every new permit type is a paid change request, and not as a loose form builder that never connects to anything. We build a platform in which the application portal for citizens and businesses, the assessment workflow for officials, the integration with the Digital Environment Act System and publication to DROP and Bekendmakingen.nl work together as one coherent whole. Each permit type gets its own process variant, all built on the same foundation.

Our background lies in custom software for municipalities and in broad permitting software. For us, a permit register is not a separate module but the web layer on top of a serious process architecture. The system covers the full spectrum: Environment Act permits (environmental permit, BOPA, overlap with the Wkb), municipal General Local Regulation (APV) permits (events, alcohol and hospitality, taxi, tree felling, market stalls, terraces, exemptions, parking), and sector-specific domains at implementing bodies such as the NVWA, ProRail, safety regions and environmental services. One foundation, with different process variants built on top.

A permit register operates within a tighter regulatory framework than almost any other government application. A permit is a decision with legal effect, and the process leading to it is set out in detail in regulation. That determines how the system looks on the inside.

The Environment Act is the basis for the vast majority of physical living environment permits. It brings its own procedural and technical obligations: connection to the Digital Environment Act System, use of applicable rules in STTR, submission via STAM, coherence with the environmental plan, and the out-of-plan environmental plan activity (BOPA) as a specific route. On top of that sits the Building Quality Assurance Act (Wkb). For construction activities in consequence class 1, the technical review runs through an independent quality assurer, while the spatial part remains with the competent authority. Our register lets these two paths run in parallel.

The General Administrative Law Act (Algemene wet bestuursrecht, Awb) governs the entire process: admissibility, the duty to give reasons, the right to be heard, standard and extended procedures, decision deadlines, grounds for suspension and extension, and the permit granted by operation of law where that is not excluded. Deadline monitoring is built into the system itself. The GDPR and the Dutch GDPR Implementation Act (UAVG) set requirements for purpose limitation, data minimisation and data subject rights — we actively document which data is held where, on what legal basis, and how access or correction requests are handled technically.

The Baseline Information Security for Government (Baseline Informatiebeveiliging Overheid, BIO) sets requirements for logging, access management and incident handling. In a permit register, the audit log is literally part of the legal process — who gave which advice, who signed which decision, which extension was granted. The Digital Government Act (Wet digitale overheid) and the Digital Accessibility of Government Bodies Decree (Besluit digitale toegankelijkheid overheid) require WCAG 2.1 AA compliance — a design requirement that touches every component, independently audited before going live.

The AI Act applies to your system as soon as you deploy AI components, such as a classifier for incoming applications or an AI tool for reviewing building drawings. AI that supports decisions about people's rights is almost always classed as high-risk. We treat every AI function as a separate decision chain, with its own DPIA, its own entry in the Algoritmeregister (the Dutch public algorithm register) and its own evaluation cycle. See also our wider AI development practice. Finally, we work with the standards of VNG, Geonovum and Logius: GEMMA, Common Ground and NLX for inter-organisational integrations, and Haalcentraal for querying basic registers.

We start with an intake session. The people usually at the table are the head of Permits, a representative from Administrative Law or legal quality, a delegate from the CIO office or Information Services and, depending on the scope, the Data Protection Officer and the CISO. For projects that connect directly to the DSO (Digital Government Environment for Permits), a DSO coordinator often joins too. The aim is to establish which problem is most urgent and which requirements apply to architecture, hosting, management and integrations.

This is followed by an exploration phase. Out of scope: which permit types dominate in volume, where applicants get stuck, and which requests for supplementary information come back most often. In scope: which registers, which discipline-specific counters and which integrations already exist, how legal quality currently works, and which publication steps are still manual. The end result is a functional and architectural design that we review with you, and with your legal audit role, before we start building in earnest.

The build phase runs iteratively in sprints. Each sprint delivers something usable: a working application flow for one permit type, a complete assessment flow, a DSO integration, or a publication route to DROP (the national publication platform for regulations). Code lives in a repository owned by your organisation, with a acceptance environment for the department and legal team, and a production environment that we only open once the accessibility and security audits have been approved.

Before go-live, we arrange an independent WCAG audit and, depending on scope and BIO impact, a penetration test and/or DPIA update. The report comes to you and serves as the basis for the accessibility statement and the in-control statement. For projects with greater security impact, we refer you to our approach to ISO 27001-compliant software. After going live, we can manage the system or hand it over to your IT department. On handover, we provide full documentation, a runbook and a repeatable deployment pipeline. The code is yours, and it stays yours.

The foundation is generic, but each permit type has its own process questions that shape the UX and the integrations.

Environmental permit & BOPA — The standard route under the Environment Act, connected to the DSO, applicable rules, and overlap with the Building Act for construction activities in consequence class 1. The BOPA route for activities outside the development plan has its own procedural form; the registration runs both side by side and monitors that the right advice from the right discipline arrives on time.

Events, alcohol & operating licences: Event permits are almost always multidisciplinary (municipality, police, fire service/Safety Region, GGD public health). Our flow supports sending out advice requests in parallel and template routes for recurring events. Alcohol Act and operating licences involve a BIBOB screening, with their own document set and retention periods.

Taxis, sex establishments, terraces, market stalls and APV permits: the typical APV (General Local Bylaw) categories that carry high volume and visible processing times. There is real gain to be had here from a good application portal, automated admissibility checks and template decisions, without designing away the legal room for tailored assessment.

Parking permits: Often a separate front end, linked to the parking rights register and the street permit area layer. Real-time checks by enforcement officers (BOA's) via a separate enforcement app on the same register. This is where our workflow layer takes on its own variant.

Water permits (water board): Its own General Administrative Law (Awb) deadlines, its own publication channel (Waterschapsblad, the water board gazette) and its own authority under the water board's by-laws (Keur). Often runs alongside an environmental permit with the municipality, so alignment at file level is crucial.

For the permits market, vendor dependency is a specific pain point. A suite vendor who raises the licence fee every year without a realistic route to migrate. A package from which case files can only be extracted through paid exports. A DSO connector that only works with other components from the same vendor. It is not malice; it is how the commercial model works when the architecture is not open.

Our counter-strategy is deliberately simple: no pre-selection of a vendor stack. We build on an open architecture with code ownership residing with you, using proven open-source building blocks as the foundation and domain-specific logic on top. For every integration with a commercial package we use standard APIs rather than vendor-specific interfaces, so replacing such a package does not require rebuilding your registration. The code lives in your repository and the documentation is in Dutch. For the wider context, see also our municipal website practice and the wider permits software offering.