Next.js development services for Dutch companies

Dutch projects usually arrive looking like any other European build, and the legal frame genuinely is similar. What is different is structural rather than regulatory: more of a Dutch user's journey happens outside your application than in most markets, and a Next.js application is unusually sensitive to that.

Two flows leave your origin entirely

Most of the Dutch market pays by iDEAL, which redirects to the user's bank. Anything touching government - and a surprising amount of private-sector work inherits it - authenticates through DigiD for citizens or eHerkenning for businesses, which also redirects.

In a server-rendered application with no client state, a redirect is unremarkable. In a Next.js application it is the one navigation that is not a client-side transition, and everything the client was holding is discarded: React state, a form in progress, a cart assembled across several steps, an optimistic update that has not been reconciled.

Three consequences worth designing for rather than patching.

The state has to survive the round trip on the server. A checkout that exists as a URL and a row - resumable by opening that URL cold - behaves correctly. A checkout that exists as React state in a wizard does not survive the first redirect, and the symptom is users returning from their bank to an empty basket.

The return is not the result. The user comes back to your returnUrl whether they paid, cancelled or closed the tab and wandered back an hour later. The authoritative answer arrives separately, on a webhook, possibly after the user is already looking at your page. A confirmation page that reads the query string and congratulates them is wrong some of the time, and the cases where it is wrong are the expensive ones.

The shape that works is a confirmation route that renders a pending state from the server and resolves when the record does - a poll, or a stream, but never a claim based on the redirect alone.

Coming back is a cold start. The return lands on a fresh server request while the user is at their most anxious. That route is the one to check your Core Web Vitals on, and it is usually the one nobody measured because it is not in the crawl.

The accessibility statement is a public artifact

Dutch public-sector bodies publish a toegankelijkheidsverklaring in a central register: a signed statement about how the site measures against the standard, what does not comply, and by when it will. It is public, it is dated, and it is written about an audit rather than an intention.

That changes the engineering economics. Accessibility stops being a quality goal somebody advocates for internally and becomes a document with your name on it. For private companies it arrives through procurement instead - a tender naming WCAG makes it a contract term, and the Netherlands has more of those tenders than most markets its size.

In a Next.js application the recurring failures are not the ones people expect. They are:

• Focus after client-side navigation. A route change that does not move focus leaves a screen reader on the old page while the visible content has changed. This is the single most common finding in an App Router audit and it is invisible to anyone using a mouse.
• Loading states that announce nothing. A loading.tsx renders a skeleton and says nothing to a screen reader, so the user hears silence and assumes the click failed - which is a different way of saying what it is not.
• Server Action errors with no association. A validation message rendered near an input but not linked to it is a message some users never receive.

All three are cheap to fix while building and awkward to retrofit across an interface that is already finished.

The address form is postcode-first

A Dutch address form asks for postcode and house number, then fills in the street and the city. Users expect it, and a form that asks them to type the street reads as foreign before they have finished the first field.

It is a small thing that reaches the component: the lookup is a request mid-form, so the fields have to accept being populated after the fact without losing what the user has already typed, and the flow needs a manual fallback for the addresses the lookup does not know. Designing that in is straightforward. Adding it to a form built around free-text street entry means rebuilding the component.

The same applies to the layout more broadly. Dutch copy is not as long as German, but it is longer than English, and an interface whose component widths were settled against English strings will find its first overflow here.

Typical engagements

Dutch work reaches us most often as commerce with a redirect problem in it - Next.js commerce with performance engineering attached, because the return journey is the route nobody measured. Where the flows already exist and behave badly, a fixed-price audit is the cheaper first step: the checkout return and the authentication callback are two specific URLs, and they can be measured rather than argued about.

Accessibility work sits inside maintenance and support when a statement has to be filed against a real audit rather than an intention. And where the build is new, application development with the redirect boundaries drawn before the first checkout screen - not after the first support ticket about an empty basket.