Next.js Agency Zurich — High-Performance Web for Swiss Financial Infrastructure

#Next.js Development in Zurich: Local Market Context

Zurich's financial sector runs on digital infrastructure that must meet three simultaneous requirements: performance standards expected by institutional users, Swiss data residency mandated by nLPD and FINMA, and multilingual delivery in English, French, German, and sometimes Italian. The wealth management portals at Julius Baer, the market data platforms consuming SIX Swiss Exchange feeds, the crypto custody dashboards in Crypto Valley — all demand engineering precision that generic web agencies cannot deliver.

The web work in this city divides into two populations that rarely meet. On one side, brand and communication agencies that produce beautiful marketing sites and stop at the login wall. On the other, systems integrators who deliver behind the login wall and produce interfaces that look like the parametrisation screens they grew out of. The projects that stall are the ones that need both: a client-facing surface with the polish a Bahnhofstrasse private bank expects, wired to a core banking platform through an integration layer that a security review will actually pass. That gap is where a specialised Next.js practice earns its place.

There is also a genuine technical reason React frameworks have taken over this segment rather than merely a fashionable one, and it has to do with where code runs. In the client-side single-page applications that dominated the previous decade, the browser holds the access token and calls the API directly, which means every field the API returns is one developer-tools tab away from a client's screen, and every integration credential has to be brokered through an additional gateway. With the App Router and React Server Components, the component that reads a portfolio position executes on the server, in Switzerland, and ships rendered markup. The token never enters the bundle. The core banking payload is never exposed in full to the browser — only the fields the page actually displays. For an institution operating under Article 47 of the Banking Act, that is a data-minimisation argument, not a performance one, and it is usually the argument that gets the architecture approved.

The fourth factor is language, and it is heavier than it looks. A Zurich portal typically ships in English and German at minimum, often French, sometimes Italian, with legal texts that must be signed off individually per locale and per legal entity. Teams that treat this as a translation layer bolted on at the end discover in testing that the currency and date formatting, the document templates, the PDF generation, the email notifications and the search index all needed locale awareness from the first commit.

#Platforms We Build for the Zurich Market

#Wealth management and private banking client portals

The visible part — portfolio overview, performance, transactions, document vault, secure messaging, meeting booking — is the smaller half of the work. The real engineering is in the integration contract with Avaloq, Temenos T24 or Finnova: which values are available in real time and which arrive with the overnight batch, how valuation timing is presented so a client is not shown a number the relationship manager cannot reproduce, how multi-currency and multi-custodian consolidation is computed and where, and how document entitlements inherit from the back office rather than being reimplemented in the web layer. We insist on an explicit answer to a single question early: for each field on the screen, which system is the authoritative source and what is its freshness guarantee. Projects that skip that question ship a portal that quietly disagrees with the statement.

Anything transactional — a payment instruction, a subscription order, a mandate change — needs step-up authentication and a four-eyes trail, and needs to be idempotent, because a client on a train through the Gotthard will lose connectivity mid-request and press the button again.

#Market data and analytics front-ends

Platforms consuming SIX Swiss Exchange feeds and reference data have a constraint most web teams have never encountered: market data is licensed per user and per entitlement class, and the distributor is contractually obliged to enforce and report it. Real time versus delayed, professional versus non-professional, display versus derived use — these are not settings, they are audited obligations. Which means the entitlement model has to sit in the data access layer, not in a conditional in the UI, and usage reporting has to be a first-class feature rather than something added when the licence audit is announced.

Technically, live quote surfaces favour server-sent events over WebSockets when the flow is one-directional, because reconnection semantics and proxy traversal are simpler in a corporate network. Streaming server rendering lets the page shell and static context paint immediately while the quote stream attaches, which matters when the users are traders who judge an application in the first second.

#Digital asset custody and exchange dashboards

For companies operating under the Swiss DLT Act framework, the architecture question is the split between on-chain and off-chain. Ledger data is public and can be read from anywhere; the client file that ties an address to a person is confidential and stays in Switzerland. The DLT Act's contribution was legal rather than technical — ledger-based securities recognised in the Code of Obligations, and segregation of crypto-based assets from the bankruptcy estate — but it changes what the interface must be able to evidence. Custody dashboards need to show custody arrangements, segregation status and transaction provenance in a form a regulator or an auditor can follow, alongside address screening results and the withdrawal approval flow with hardware-key confirmation. The design register is institutional, not retail: dense, precise, no gamification.

#Insurance self-service and broker portals

Swiss personal-lines claims are submitted on phones, which makes the capture flow the entire product. Image capture with client-side quality checks before upload, resumable uploads on poor mobile connections, a form that survives being backgrounded for ten minutes, and a state model that lets a claim be finished later without retyping. On the broker side the requirement inverts: dense multi-client tables, bulk operations, spreadsheet export, and single sign-on against the broker's own identity provider. Document generation belongs on the server with a versioned template library, because the policy document a customer downloaded eighteen months ago must still be reproducible exactly.

#Deep tech and ETH spinoff product surfaces

Spinoffs from the ETH ecosystem arrive with exceptional science and a front end assembled by whoever had the least to do that week. The constraint is rarely aesthetic. It is that a Series A enterprise sales cycle now includes a security questionnaire, and the web layer is where the answers are either evidence or improvisation: authentication and session handling, tenancy isolation, audit logging, dependency and vulnerability management, backup and restore, data deletion on request. We build that layer to be defensible so the scientific team never has to stop working to answer it.

#Investor relations and regulated corporate sites

For SIX-listed issuers, the corporate site is a regulated surface. Ad hoc publicity rules require simultaneous availability and equal treatment: the disclosure must go out to subscribers and be published on the site at the same moment, remain accessible for a defined period, and be reachable without registration. That translates into concrete engineering — an embargoed publication mechanism with an exact release time, a subscription distribution path, archive URLs that never move, and a caching strategy that cannot serve a stale index at the moment of release. It is a small site with unusually strict requirements, and it is routinely built by teams unaware that any of this applies.

#The Engineering Standards We Hold Ourselves To

Caching, correctly. The most dangerous default in a modern React framework is aggressive caching applied to personalised data. Everything client-specific is fetched uncached on the server request path; caching and revalidation by tag are reserved for genuinely shared content. Nothing personalised is ever cached at an edge node outside Switzerland, and we verify that with tests rather than trusting configuration.

Where the code actually executes. Edge middleware is convenient for locale routing and route protection, and it runs wherever the platform decides. For a workload with a residency requirement that is a compliance question with a technical answer: authorisation decisions that need client data run in the Swiss region, and middleware is kept to what can be decided from the request itself.

No third-party fetches in the critical path. Fonts are self-hosted and served from the same origin, not pulled from a foreign CDN — a font request from an authenticated banking page discloses the client's IP address to a third country for no benefit. The same applies to analytics, tag managers and chat widgets on authenticated surfaces. A content security policy with per-request nonces and strict-dynamic makes this enforceable rather than aspirational, alongside HSTS, a restrictive Permissions-Policy and a referrer policy that does not leak paths.

Performance as a contract. We hold delivery to a largest contentful paint under 1.2 seconds on the reference page set, with interaction latency and layout stability measured on real user data rather than a laboratory run, on the mid-range Android hardware that a broker or a claimant actually uses. Institutional users on a corporate network with a proxy and an endpoint agent are not the fast case.

Accessibility as a requirement. WCAG 2.1 AA is the floor. For Swiss institutions serving customers in the European Union, the European Accessibility Act has applied to banking and e-commerce services since June 2025, which moves accessibility from good practice to an obligation with an owner. We test with keyboard and screen reader on the real flows — login, payment instruction, claim submission — not on the marketing pages.

Operability. Structured logging with client-identifying fields scrubbed at source, distributed tracing through the integration layer so a slow page can be attributed to the core banking call that caused it, health and readiness endpoints, and a documented recovery objective consistent with the operational resilience expectations your supervisor applies to critical business functions. We run production services against a 99.5% availability commitment.

Environments with no production data. Preview and staging environments run on synthetic fixtures. A pull request preview containing real client positions is an incident waiting for an audit to find it.

#How a Build Runs

We work in five stages over a typical 8 to 12 weeks to first production release. Discovery fixes scope, locales, the authoritative source for each data field, and the regulatory constraints that will shape the architecture — hosting and outsourcing documentation included, because for a supervised institution the choice of hosting provider is an outsourcing decision with audit and subcontractor implications before it is a technical preference. Architecture spike attacks the riskiest integration first, in week one: the core banking authentication handshake, the market data entitlement model, the identity provider federation. Vertical slice delivers one complete journey end to end — real authentication, real data, real deployment pipeline — so that the hard problems surface while there is still time. Hardening covers penetration testing against an application security verification standard rather than a checklist, load testing at realistic concurrency, accessibility audit and the documentation pack. Launch and run brings monitoring, an on-call path, and an evolution backlog owned jointly.

#The Mistakes That Cost Zurich Projects Six Months

Treating data residency as a hosting checkbox. Residency is a property of every dependency: the database, the object storage, the mail relay, the error tracker, the font, the CAPTCHA, the session store. One forgotten error-reporting SDK sends stack traces containing client identifiers abroad. We inventory every outbound destination and put it in the documentation.

Fetching sensitive data from the browser out of habit. Teams port a client-side data-fetching pattern into a server-rendering framework and rebuild the exposure they were meant to eliminate.

Designing screens before designing the data contract. Interfaces drawn against imagined data produce three months of rework once the real freshness, granularity and error states arrive. The integration contract precedes the mockups.

Localisation as a phase. Retrofitting locale awareness into routing, formatting, documents, notifications and search costs several times what building it in costs, and the legal texts always arrive last anyway.

Assuming one deployment platform fits everything. Managed platforms are excellent for marketing sites and non-regulated products. For workloads carrying client-identifying data under Swiss supervision, deployment on Swiss infrastructure with contractual residency and inspection rights is usually the only version that survives the risk review. Both can coexist in one project; pretending the distinction does not exist does not.

#Why Nehos in Zurich

• 47 specialists in AI, data and cloud with 200+ projects in production since 2014 — the team that scopes your platform is the team that builds it, with no handover to an offshore delivery centre.
• Financial integration experience with the platforms this city runs on, including the data lineage work that precedes any portal.
• Compliance artefacts delivered with the code — residency inventory, outsourcing documentation, security test evidence, accessibility audit.
• Measured performance, held to a largest contentful paint under 1.2 seconds and a 99.5% availability commitment in production.
• English, German, French and Italian delivery, with locale handling designed in rather than translated on.
• A free 30-minute audit of your existing platform or your integration plan, with a straight answer on feasibility.

Related areas we cover: Next.js development in Zurich and Switzerland, financial portal engineering, wealth management portal development, SIX Swiss Exchange data integration, DLT Act compliant digital asset dashboards, headless web development in Zurich, and web applications with Swiss data residency.

Continue with the Nehos Zurich hub overview and the Nehos Next.js development service — full detail. Where the platform needs intelligence built in, see AI agency Zurich — AI integration for web platforms. For Romandy, see Next.js agency Geneva — French-speaking Switzerland.

The questions below are the ones Zurich technical teams ask most often before a first engagement.