Next.js development for Amsterdam companies

Amsterdam is two hours behind us, which puts our afternoon squarely inside your working day. Six usable hours of overlap, and no scheduling gymnastics.

The second thing is worth stating plainly because it is a real and unusual advantage: Dutch engineering teams work in English as a default, not as a concession. There is no translation layer between the people writing the code and the people reviewing it, and no quiet friction where somebody is operating in their second language all day. Of the European markets we work in, this is the one with the least of that.

Two flows that leave your page and come back

This is the local specific, and it is the same engineering problem twice.

The dominant payment method here sends the customer to their own bank and returns them afterwards. Government login, where it applies, does the same thing. In both cases the browser leaves your application and comes back, and everything React was holding is gone - the component tree unmounted, the hooks reset, the variable that knew which order this was no longer exists.

That is not a bug and there is nothing to fix in the code. A redirect is a navigation, and navigations destroy client state. What it means is that the checkout, or the login, has to be built so that losing it costs nothing.

In practice: the order exists on the server before the browser goes anywhere, in a pending state, with an identifier of your own. That identifier travels in the return URL as a path segment rather than a query parameter, because a path is a page you control and a parameter is something the customer can edit. The return page is a Server Component that loads the record by that identifier, checks it belongs to whoever is asking, and renders what the database says rather than what the URL claims.

And there is a third state beyond success and failure: the customer is back, the payment is real, and your database does not know the answer yet because the confirmation has not arrived. That screen decides whether somebody pays twice, and it is the one most teams discover in production.

The payment method itself also has no authorisation-and-capture step - it is a transfer, so the money moved or it did not, and an order model built around reserving funds and taking them later does not fit.

The accessibility statement is public

Organisations here that face the public sector publish an accessibility statement, and it describes a real audit rather than an intention.

The engineering behind it is the ordinary App Router work: focus that moves on client-side navigation, loading states that announce themselves rather than spinning silently, and form errors associated with the inputs that produced them. None of it is difficult. What is different here is that the claim is published, so it has to be true.

Commercially

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in euros, by bank transfer, with no Turkish VAT because exported services are exempt. Fixed scope agreed in writing, priced per project.

The country-level ground - the invoicing network, the regulator's reading of consent - is on the Netherlands market page.