Web application development

The first choice is the form. It determines how users find the application, how updates work and what maintenance costs. For most business applications a web application is enough: one codebase, it works on any device with a browser, and an update is available to everyone at once.

Choose a native app only when the application genuinely needs something the browser does not offer, such as working for long periods without a connection in the field, or background tasks. Otherwise you pay for two maintenance streams with no gain for the user.

We choose the stack for maintainability, not fashion. A web application that must last five years or more has to be maintainable by developers you can find yourself later on.

• TypeScript on the front end and, where it fits, on the server too, because types catch mistakes before a user does.
• Server-side rendering for pages that must load fast and stay readable without JavaScript.
• PostgreSQL as the database: open source, widely supported and extendable with PostGIS when location data comes into play.
• A documented API described in the OpenAPI Specification, so that other systems can connect without reading the code.

In the public sector the NLGov REST API Design Rules are a mandatory standard on the "comply or explain" list of Forum Standaardisatie (the Dutch standardisation forum). They must be applied when offering REST APIs that expose government information or functionality. If we build an API for a government body, we follow those rules and check the API description against them automatically in the build pipeline. If the application contains a map, a separate stack is added; it is described under GIS and digital map solutions.

For Dutch government bodies, digital accessibility is a legal duty. It stems from the EU Web Accessibility Directive, which states in Article 4:

Member States shall ensure that public sector bodies take the necessary measures to make their websites and mobile applications more accessible by making them perceivable, operable, understandable and robust.

Source: Directive (EU) 2016/2102, Article 4, EUR-Lex. In Dutch law, Article 3 of the Tijdelijk besluit digitale toegankelijkheid overheid (the Dutch Temporary Decree on digital accessibility of government) provides that government bodies make their websites and mobile applications accessible by applying standard EN 301 549. Article 4 requires an accessibility statement.

The applicable version of EN 301 549 refers to WCAG 2.1. On 3 September 2026 version 4.1.1 of EN 301 549 was published, with a reference to WCAG 2.2. That version only becomes the applicable standard after the European Commission has harmonised it; no timeline for that is known (Digitoegankelijk, the accessibility site of the Dutch government, 8 September 2026). Our starting point is therefore to build against the WCAG 2.2 success criteria at level AA now, so that a new standard does not mean a rebuild.

In practice we propose that:

• everything can be operated with the keyboard, with a visible focus indicator;
• forms have labels, and error messages are understandable and announced by screen readers;
• colour contrast and text size are in order, including at 200 per cent zoom;
• we test with a screen reader and not only with an automatic scanner, because a scanner can check only part of the criteria.

For a formal judgement you have an independent party carry out an evaluation using the W3C method WCAG-EM. That evaluation is also the basis for the accessibility statement. Online maps are a partial exception; see the GIS viewer for municipalities. What this means for municipalities in general is covered on the page about software for municipalities (in Dutch).

Government organisations do not need to have forms, buttons and tables redesigned for every application. NL Design System is an open source collection of design systems in which governments share components that have been tested for usability and accessibility. An organisation records its house style as a theme and uses the shared components with it.

For a web application that has three advantages. The accessibility of the basic building blocks has already been examined, so testing can be more targeted. Users recognise patterns from other government services. And another supplier can later carry on with the same components.

If your organisation does not have a theme yet, that can be part of the first iteration. For organisations outside government NL Design System is not mandatory, but the components and guidelines are free to use. Building your own component library only pays off when several applications will be built on it and someone keeps maintaining it. If a component is missing, a new one can be contributed back to the community.

In a web application the sign-in method is often the hardest design choice. Staff preferably sign in with the account they already have, so that a departing employee is disabled in one place. Residents or customers have different requirements, depending on which data they can see.

We also settle the following early on:

• which roles exist and what each role may see and change;
• which actions are logged, how long those logs are kept and who can inspect them;
• which security headers the server sends, such as a Content-Security-Policy that blocks the loading of unknown scripts;
• how sensitive data in the database is protected.

As a checklist we use the OWASP ASVS, at the level that suits the sensitivity of the application. For applications with personal data or a public login we recommend a penetration test by an independent party before go-live. How this fits with the agreements on code and ownership is covered under custom software development.

Designing a web application starts with the user's task, not with the screens. That is why we work in this order.

1. Tasks and users. Which task must someone complete, on which device, and what goes wrong today?
2. Clickable design. A simple prototype that you test with a few real users before any code is written.
3. Building in iterations. Every iteration is on a test environment that you can open yourself.
4. Performance and devices. We agree a load-time budget and test on the browsers and devices your users actually have.
5. Go-live and monitoring. Errors and availability are measured, so problems become visible before users call.

After go-live we look at usage: where do people drop out, which error messages occur often? That determines the next improvements, not a list drawn up in advance. These measurements do not require tracking individual visitors; aggregated data on errors and drop-off points is enough and keeps the privacy statement simple.

A web application or app needs more than a functional wish. It helps if these things are arranged early.

• Copy and its owner: who keeps instructions and help texts up to date after go-live?
• House style or an existing NL Design System theme.
• The domain or subdomain, and someone who can change DNS records.
• For native apps, a developer account in the App Store and Google Play in the name of your organisation, so that the app remains yours.
• A place to host; see cloud and data infrastructure for the trade-offs.
• In a government organisation, the person who publishes and maintains the accessibility statement.

If you are unsure whether your question is about a web application, an app or really an integration between existing systems, get in touch. A first conversation is about the task, not the technology. What you bring is a description of the users and an example of how it works now, even if that is a paper form or an email flow.

If the question is mainly about weighing options, such as buying a package against building, technology and software consultancy is a logical first step.