Next.js development for Edinburgh financial services

Edinburgh is a financial centre with a software problem that is not a software problem.

The buyers are banks, building societies, asset managers, insurers and the fintechs that grew up next to them. What makes their projects distinctive is that the interface itself is in regulatory scope. The wording on a button, the prominence of a fee, the order in which two options appear - these are not design preferences here. They are things a firm can be asked to justify.

The copy is reviewed, and that is the schedule

On most projects, words are the fast part and code is the slow part. In Edinburgh it is reversed, and a plan that ignores this produces a project that stalls at ninety per cent.

The practical response is to separate the things that need review from the things that do not, and to start the reviewable ones early. Anything describing cost, risk, commitment or an outcome a customer might rely on goes for review in week two with placeholder layout around it. Everything else iterates freely.

The second half of the response is architectural: consequential wording belongs in content the firm can change without a deployment. The first time a figure is wrong in production, the difference between a content edit and a release cycle is the difference between an hour and a fortnight.

Behind a login, the value of server rendering changes

Almost everything worth building for an Edinburgh firm is authenticated, which removes most of the caching story. People sometimes conclude from this that the framework choice does not matter. It matters differently.

A dashboard assembled in the browser makes a request per panel, each waiting for the one before it in practice, and each shipping the code to make it. The same dashboard rendered on the server sends markup that is already correct, and the browser's job is to display it. On a bank's managed network with a proxy in the path, that difference is not subtle.

What it requires is deciding deliberately which routes are dynamic and why, rather than discovering it. The rendering model is the reference, and the common mistake in a financial dashboard is a single shared layout that fetches everything for every role, so the slowest panel sets the speed of the page.

Numbers belong on the server

This is the one firm rule on these projects, and it is about accountability rather than performance.

A projection, a fee calculation, an eligibility result or an APR computed in client JavaScript is a number the customer's browser produced. It can be read, altered and screenshotted in an altered state, and when a firm is asked to show how a figure shown to a customer was arrived at, "the browser worked it out" is not an answer.

So the calculation runs on the server where it can be unit tested and logged, and the interface renders the result. Where the client boundary sits is the mechanism, and in a regulated product the boundary is drawn by the audit question rather than by convenience.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - UK data protection, consent after divergence from the EU, invoicing - is on the United Kingdom market page.

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