Next.js in Rotterdam

Next.js development for Rotterdam port and logistics businesses

A Next.js development company working with Rotterdam port, freight and trade businesses. Portals where the account is a company rather than a person, and one person works for two of them.

Updated November 4, 2026

Working day overlap: About six hours. Rotterdam is two hours behind Ankara, so our afternoon sits inside your day
Who buys here: Port and terminal operators, freight forwarders, shipping agents, trading companies and the technology firms serving them
What that changes: The account is a company, so permissions, data and even the interface depend on which organisation the user is acting for
Local specifics: Agents and brokers routinely work for several companies, so a single person needs more than one set of permissions

A Rotterdam portal has a user model that most web applications do not: the account is a company, and the person signing in is acting on its behalf.

That sounds like a detail and it changes the structure of the application. Permissions belong to a relationship between a person and an organisation rather than to the person. The data visible on a page depends on which company is being represented. And in this market, where agents and brokers routinely handle several clients, one person legitimately holds several of those relationships at once.

Permissions belong on the server, every request

The first consequence is about where checks happen, and it is the one that produces real incidents.

It is tempting to resolve permissions in the interface - hide the button, remove the navigation item, skip the tab. That is presentation, not permission. The route still exists, it still responds, and a URL can be typed or shared or remembered by a browser.

So the check sits where the data is fetched, on the server, on every request, derived from the person and the organisation they are acting for. The interface then reflects the result rather than enforcing it. That is also what makes the application safe to extend, because the next developer adding a route inherits the check rather than having to remember it.

Which company am I acting for

The second structural piece is the one that distinguishes a Rotterdam portal from an ordinary customer login.

A broker working for three shipping lines needs to switch between them, needs to be in no doubt which one is currently selected, and needs to be unable to act for one while thinking they are acting for another. The consequences of getting that wrong are commercial rather than cosmetic - an instruction given for the wrong client.

Keeping the selection in a session only is what allows the mistake. Putting the organisation in the URL means the address and the screen always agree, a page can be shared with a colleague without ambiguity, and two browser tabs can hold two different clients without interfering. It is a routing decision with a safety consequence.

What can be cached in a portal

Almost nothing that depends on who is asking, which removes the usual performance story and replaces it with a different one.

The win in a portal is not caching pages. It is that the server renders the page already filled in, so the browser receives markup rather than a bundle that then makes six requests to discover what to display. For a logistics dashboard with several panels, that is the difference between one round trip and several.

What can be cached is the content that is identical for everybody - schedules, reference data, tariff explanations, help. Keeping those separate from the account-specific parts is what lets them be served instantly while the rest is rendered per request. Which route renders which way is the decision, and in a portal it has to be made deliberately rather than inherited.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - Dutch invoicing and e-invoicing, the accessibility statement, payment methods - is on the Netherlands market page.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in euros by bank transfer, with no Turkish VAT because exported services are exempt.

Frequently asked questions

Our Rotterdam portal users belong to companies. How does that change the front end?

Almost everything becomes conditional on the organisation rather than on the person. Which shipments are visible, which actions are permitted, which screens exist at all - and that has to be resolved on the server rather than hidden in the browser. A navigation item removed in the interface while the route still responds is not a permission; the check belongs where the data is fetched, on every request, because a URL can be typed.

Some of our users work for several companies. What does that require?

An explicit notion of which organisation the person is currently acting for, visible in the interface and present in the URL. A broker handling three clients needs to switch, needs to be certain which one they are looking at, and needs to be unable to act for one while believing they are acting for another. Keeping that choice only in a session is how somebody authorises a shipment for the wrong client - it should be in the address, so that what is on screen matches what the address says.

Should a logged-in portal page ever be cached?

Not as a page, and the detail matters because the default can surprise you. Anything that depends on who is asking has to be excluded from shared caching, which means being deliberate about which routes are dynamic rather than discovering it. What can be cached is the content that is the same for everybody - reference data, help pages, a schedule - and separating those from the account-specific parts is what keeps a portal fast.

Can we let customers invite their own colleagues?

It is usually worth it, and it is more design than engineering. Somebody at the customer needs to be able to add a colleague, set what they can do and remove them when they leave, without raising a support ticket. The parts to think about are who at the customer holds that power, what happens when that person leaves, and whether an invitation can be accepted by a different email address than it was sent to - which is the question that decides whether the feature is safe.