Next.js in Leeds

Next.js development for Leeds health, legal and insurance

A Next.js development company working with Leeds health, legal and insurance organisations. Interfaces where no third-party script is acceptable and a URL must not carry a case reference.

Updated November 4, 2026

Working day overlap: About five hours, as in London and Manchester - three hours behind Ankara
Who buys here: Health organisations and NHS suppliers, law firms, insurers and the claims businesses around them
What that changes: Third-party scripts become unacceptable rather than undesirable, because a tag manager on a page about a condition leaks the condition
Local specifics: Case and claim references must not appear in URLs, referrers or logs, which constrains routing rather than copy

Leeds buys software for health, law and insurance, and all three carry the same consequence: the page somebody is looking at is itself sensitive information.

That is a sharper constraint than it first appears. Most privacy work is about not collecting names. Here the problem is that a URL about a specific condition, a specific claim type or a specific legal matter, read by anything other than the server, discloses something personal even with no name anywhere near it.

Nothing third-party loads in a Leeds clinical interface

The default modern web page contacts half a dozen other companies - a font service, an analytics provider, a tag manager, a session recorder, a chat widget, a CDN. For a health or legal site each of those is a disclosure.

A session recorder on a symptom checker records the symptoms. A tag manager on a page about a treatment sends the page address to an advertising network. A font loaded from another domain reveals the visitor's address to a third party on every page view. None of these require malice to cause harm, and none are defensible to an information governance review.

So these projects start from nothing loading externally. Fonts are self-hosted at build time, analytics runs on infrastructure the organisation controls, and any widget has to justify itself on its own. It is less work than retrofitting and a far shorter conversation than explaining a tag manager to a governance board.

URLs are the part people forget

The second constraint is routing, and it is where well-intentioned applications leak.

A case reference, a claim number or a patient identifier placed in a path or a query string is now in browser history, in the referrer sent to anything the page loads, in server access logs, in the office proxy's logs, in a bookmark, and in whatever screenshot somebody takes to ask a colleague a question.

The pattern that holds is an identifier that is meaningless on its own, with authorisation checked server-side on every request rather than treated as implied by having the link. Guessing should fail and sharing should not grant access. That is a decision about route design, taken before anything is built, and it is one of the few front-end choices that is genuinely difficult to retrofit.

Long forms need to survive being left

Health, legal and insurance processes produce forms that take twenty minutes, because the underlying process takes twenty minutes and pretending otherwise just moves the problem.

A form of that length held entirely in client state loses everything to a crashed tab, a session timeout or an interruption, and people do not start again. Saving each step to the server lets somebody finish tomorrow, which raises completion more reliably than any attempt to shorten the questions.

The implementation detail that matters is keeping each step a server-rendered page with its own address rather than one enormous client component, so that progress is real, the back button behaves, and the browser is not holding the only copy of anything. That is also the cheaper option in shipped JavaScript, which the client boundary explains.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - UK data protection, consent, invoicing in pounds - 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.

Frequently asked questions

Why can a Leeds health or legal site not use normal analytics?

Because the page a person is reading is itself the sensitive fact. A URL containing a condition, a treatment or a claim type, sent to an analytics provider along with a device identifier, discloses something about an individual regardless of whether a name was attached. The answer is analytics that runs on infrastructure the organisation controls and records what it needs rather than everything available, which is a smaller change than it sounds and a much easier conversation with an information governance team.

What is wrong with putting a case reference in the URL?

A URL travels further than people expect. It is in the browser history, in the referrer header sent to anything the page loads, in server logs, in a bookmark, in a screenshot pasted into an email. A reference that identifies a case belongs in a request the server authorises, not in an address that is copied around by default. The practical pattern is an opaque identifier that means nothing on its own, with authorisation checked on every request rather than inferred from possession of the link.

Our claim form takes twenty minutes and people abandon it. What helps?

Saving progress on the server, and being explicit about it. A long form held in browser state loses everything to a crashed tab, an expired session or a phone call halfway through. Saving each step server-side means a person can return the next day, which both raises completion and removes the pressure to make the form shorter than the process actually is. The related trap is a multi-step form that keeps all its state in one client component, because then every step is also a bundle.

Can you work with our information governance team?

That is the normal path here and it is better done early. The questions are consistent - what leaves the browser, what is logged and for how long, who can see it, and where it is processed. Those are answerable in writing before scoping, and answering them late is how a project acquires a four-week pause in its final fortnight.