Next.js-Entwicklung in Frankfurt für Banken und Versicherer

Frankfurt ist die eine deutsche Stadt, in der der schwierige Teil eines Frontend-Projekts selten das Frontend ist.

Die Käufer sind Banken, Versicherer, Asset Manager und die Zahlungsdienstleister dazwischen. Ihre IT-Auslagerung ist beaufsichtigt, und damit ist eine Zusammenarbeit nicht nur ein Vertrag zwischen zwei Firmen, sondern eine Vereinbarung, in die ein Dritter Einsicht nehmen darf. Das prägt Zeitplan, Architektur und Unterlagen, etwa in dieser Reihenfolge der Kosten.

Was Aufsicht von einer Webanwendung tatsächlich verlangt

Nicht das, was man erwartet. Um Frameworks geht es dabei fast nie.

Es geht darum, wo verarbeitet wird, wer sonst Zugriff hat, ob das Institut prüfen kann, was wir getan haben, und ob es ohne uns weitermachen kann. Der letzte Punkt ist der unterschätzte: ein Exit-Plan ist hier Vertragspflicht, und er hat eine technische Gestalt. Ein Repository, das dem Institut schon gehört, ein Build, der auf dessen Infrastruktur läuft, und eine Dokumentation, die für jemanden geschrieben ist, der nicht dabei war.

Diese Dokumentation entsteht während der Arbeit und nicht am Ende, weil die am Ende geschriebene Fassung immer die ist, die niemand liest.

Der Browser darf nicht nach draußen telefonieren

Das ist die Frankfurter Besonderheit, die am meisten überrascht, und sie reicht tiefer in eine Next.js-Anwendung, als es klingt.

Die Content-Security-Policy eines beaufsichtigten Instituts verbietet dem Browser in der Regel, etwas von einer nicht geprüften Domain zu laden. Praktisch fallen damit Google Fonts, gehostetes Analytics, Tag Manager, JavaScript von einem CDN und jeder Bilddienst weg, den das Institut nicht selbst betreibt.

Für jedes davon gibt es eine Antwort. next/font kann die Schriftdatei zur Build-Zeit mitliefern, sodass der Browser nie eine externe Domain auflöst. Analytics läuft auf einer Subdomain des Instituts oder gar nicht. Bilder optimiert das Deployment statt einer Plattform, und das ist eines der Dinge, die sich ändern, wenn man Next.js selbst betreibt.

Schwierig ist nichts davon. Als Ausgangsannahme ist alles davon billiger als als Befund in einem Pentest-Bericht.

Beraterschirme, keine Marketingseiten

Was aus Frankfurt kommt, ist überwiegend intern oder halbintern: die Kundensicht eines Beraters, ein Maklerportal, eine Onboarding-Strecke, die auch ein Compliance-Verantwortlicher benutzt, eine Reporting-Oberfläche für institutionelle Kunden.

Das sind authentifizierte Anwendungen, und damit ist die Rendering-Frage anders entschieden als bei öffentlichen Seiten. Hinter einem Login ist nichts statisch cachebar, die Sitzungsprüfung gehört dorthin, wo sie nicht übersprungen werden kann, und die Versuchung, ein gemeinsames Layout alles für jede Rolle laden zu lassen, ist der Weg, auf dem diese Anwendungen langsam werden. Welche Route wie rendert ist das erste Gespräch, nicht das letzte.

Das zweite Gespräch dreht sich meist um Identität. Das Institut hat bereits einen Identity Provider, die Anbindung läuft über SAML oder OIDC gegen etwas Internes, und die Antwort auf „können wir einen gehosteten Auth-Dienst nehmen" ist nein.

Kaufmännisch

Der Umfang steht vor Beginn schriftlich fest und wird pro Projekt kalkuliert, nicht als Tagessatz. Der Rahmen auf Länderebene - deutscher Datenschutz, die Barrierefreiheitsfrist, E-Rechnung - steht auf der Länderseite Deutschland, weil er für eine Hamburger Logistikfirma genauso gilt wie für eine Frankfurter Bank.

Abgerechnet von der Codefacture Yazılım A.Ş. in der Türkei, in Euro, per Überweisung, ohne türkische Umsatzsteuer, weil exportierte Leistungen befreit sind.