Next.js development for Boston health, biotech and universities

Boston's buyers are hospitals, biotech companies, universities and the suppliers around them, and they share one property: the front end's most important job is to not leak.

That is an unusual brief. On most projects the interface is judged on what it shows and how fast. Here it is judged first on what escapes - what ends up in a URL, a log, a referrer header, a third party's server or a screenshot in somebody's email - and only then on anything else.

An identifier in a URL has already left

The single most common defect in health-adjacent applications is also the easiest to introduce, because frameworks encourage it.

A route like /patients/48219/results is the obvious design and it puts an identifier somewhere that travels. The browser keeps it in history. Every external resource the page loads receives it in a referrer header. The web server logs it, the corporate proxy logs it, and the monitoring tool aggregating those logs stores it. Somebody screenshots the page to ask a colleague a question and the identifier is now in an email thread.

The alternative is not complicated. The identifier in the address is opaque and means nothing without the database. Authorisation is checked on the server for every request rather than treated as implied by knowing the URL. Guessing fails, and sharing a link does not grant access.

That is a routing decision taken before anything is built, and it is one of the few front-end choices that is genuinely painful to retrofit, because every link, bookmark and integration depends on it.

One institution, two applications that should not be one

Boston's academic medical centres and research institutions have a structural problem that looks like a content problem.

The public site has to rank. It is marketing - departments, clinicians, conditions, research output - and it wants analytics, campaign tracking, a decent amount of imagery and the usual apparatus of a site competing for attention. The portal behind it handles appointments, results and study participation, and wants none of that.

Building both in one application with one configuration means the stricter requirement either leaks into the marketing site, where it is unnecessary, or the looser one leaks into the portal, where it is a disclosure. The second direction is the one that happens, because the marketing team has a legitimate need and the portal has no visible objection until something is wrong.

So they are separate deployments with separate policies, even when they share a design system and a domain. Two applications, one brand. That is a decision about repository and deployment shape, made in week one, and it is the cheapest form of containment available.

The review board is part of the schedule

Research and academic buyers in Boston bring an ethics or institutional review process, and the mistake is treating it as a final approval step.

The things a board cares about - consent wording, what is collected, how somebody withdraws, what happens to their data afterwards - can be reviewed against a wireframe. None of them require a working application. Teams that send the finished product for review find a multi-week queue between having something and being allowed to use it, and nothing in that queue is engineering.

So those items go first, in week two, with placeholder layout around them. Everything else iterates while they are being read.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - state privacy laws, accessibility exposure, invoicing - is on the United States market page.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in US dollars by bank transfer, with no Turkish VAT under the export-of-services exemption and no US entity on our side.