Next.js development for Frankfurt financial institutions

Frankfurt is the one German city where the hard part of a front-end project is rarely the front end.

The buyers are banks, insurers, asset managers and the payment firms that sit between them. Their IT outsourcing is supervised, which means an engagement is not simply a contract between two companies - it is an arrangement that somebody else is entitled to inspect. That reality shapes the schedule, the architecture and the paperwork, in roughly that order of cost.

What supervision actually asks of a web application

Not what people expect. The questions are rarely about frameworks.

They are about where data is processed, who else touches it, whether the institution can audit what we did, and whether it can continue without us. The last one is the most underrated: an exit plan is a contractual requirement here, and it has a technical shape. A repository the institution already holds, a build that runs on their infrastructure, and documentation written for somebody who was not in the room.

We write that documentation during the work rather than at the end, because the version written at the end is always the version nobody reads.

The browser is not allowed to call out

This is the Frankfurt-specific constraint that most surprises people, and it reaches further into a Next.js application than it sounds.

A supervised institution's content security policy generally forbids the browser loading anything from a domain that has not been reviewed. In practice that rules out Google Fonts, hosted analytics, tag managers, CDN-served JavaScript and any image service the institution does not run.

Each has an answer. next/font can self-host a font file at build time, so the browser never resolves an external domain. Analytics either runs on a subdomain the institution owns or does not run. Images get optimised by the deployment rather than by a platform, which is one of the things that changes when you run Next.js yourself.

None of this is difficult. All of it is cheaper as a starting assumption than as a finding in a penetration test report.

Advisor screens, not marketing pages

The work that arrives from Frankfurt is mostly internal or semi-internal: an advisor's client view, a broker portal, an onboarding flow that a compliance officer also uses, a reporting surface for institutional clients.

These are authenticated applications, which settles the rendering question in a way public marketing sites never do. Nothing behind a login is statically cacheable, the session check belongs where it cannot be skipped, and the temptation to make one shared layout fetch everything for every role is how these applications become slow. Which route renders which way is the first conversation, not the last.

The second conversation is usually about identity. The institution already has an identity provider, the integration is SAML or OIDC against something internal, and the answer to "can we use a hosted auth service" is no.

Commercially

Scope is fixed in writing before work starts and priced per project rather than as a day rate. The country-level ground - German data protection, the accessibility deadline, e-invoicing - is on the Germany market page, because it applies to a Hamburg logistics firm exactly as much as to a Frankfurt bank.

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