Next.js development for Hamburg logistics and publishing

Hamburg buys software for two quite different reasons, and the city's two industries happen to produce the same engineering problem.

The freight forwarders, shipping lines and port logistics firms need customer-facing surfaces over systems that were never designed to have one. The publishers and media houses need to put decades of archive on the public web without it collapsing under its own URL count. In both cases the interesting constraint is volume of addresses rather than volume of pages.

The data is a batch, not a feed

Most Hamburg projects start with a source system that is not a web service. A terminal operating system, a transport management system, an EDI feed, a nightly export dropped on an SFTP server.

That reality should be visible in the interface rather than hidden by it. A page that says "position as of 06:15" is trustworthy; a page that looks live over a feed updating four times a day generates support tickets every time somebody refreshes and nothing moves.

Technically it settles the caching question in a useful way. If the underlying data changes on a schedule, the page can be cached until the next batch and revalidated when it lands, which is a far cheaper design than treating every request as potentially new. What Next.js caches and when is worth reading before deciding, because the wrong default here is either a stale page nobody can clear or a page that rebuilds on every bot visit.

One URL per shipment is an SEO decision

A tracking page is the clearest example of a URL that must exist, must be fast, and must not be indexed.

It holds somebody's consignment details behind a reference number. Search engines should not have it. It should not appear in a sitemap. It should still render in well under a second for the person who pasted the number into the box, including the person doing that from a phone in a warehouse on bad signal.

Getting all three right means a deliberate robots setting on that route, exclusion from the sitemap generator rather than a filter bolted on afterwards, and a rendering strategy that does not statically cache a page keyed on personal data. Those are three separate decisions in three separate files, and the defaults get two of them wrong.

Archives that outgrow the defaults in Hamburg newsrooms

The publishing side of the city has the opposite problem: pages that should be indexed, in quantities that break the standard setup.

A sitemap file holds fifty thousand URLs, so a twenty-year archive needs a sitemap index pointing at several of them. Harder than that is the URL inflation that archives generate on their own - author pages, tag pages, year and month listings, paginated indexes - each of which is a thin page competing with the article it links to.

The fix is unglamorous and it works: decide which listings are canonical, which are paginated with proper relationships, and which should not be crawlable at all. The reasoning is in canonicals and sitemaps, and technical SEO is the engagement that usually follows.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - German data protection, the accessibility deadline, e-invoicing obligations - is on the Germany 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.