Building for environments you don't control

Most software advice assumes you own the environment. Your servers, your network, your deploy button, your users on the latest version. Roll forward, roll back, ship again on Monday.

Two of my current engagements are not like that. One is a clinical alerting platform used by NHS trusts. The other is the cloud and connectivity layer for a UK detection hardware company whose units are installed inside hospitals. In both, the environment belongs to someone else, and it sets the rules. This piece is about what that does to how you build, and what to ask of anyone building it for you.

What you do not control

The network. Hospital networks permit no inbound connections. None. You do not get a port opened because your product needs one. If a device on a ward needs to talk to your cloud, the device makes the call, outbound, and your cloud answers. If your support team needs to reach that device, the same rule applies. Everything has to be designed as outbound only from day one, because there is no day two where the firewall policy changes for you.

The network is also not reliable. Hospital Wi Fi drops. Wired links get unplugged by cleaners. A device that assumes a connection is present will fall over the first time it is not.

The hardware. A detection unit installed in a hospital doorway is not a server you can rebuild from an image. If a software update leaves it unbootable, an engineer travels to the site. Multiply that by a fleet and you have a product that cannot afford a single bad release.

You also cannot upgrade the fleet in lockstep. Units in the field run different software generations, because sites update on their schedule, not yours. Your cloud has to talk to all of them, at once, indefinitely.

The conformance requirements. An NHS trust connecting a clinical system to its infrastructure has a conformance process. It covers how you consume their HL7 messages, how you look up patient records, how you handle their data, how you authenticate. You do not negotiate this. You meet it, per trust, and each trust's requirements differ.

The stakeholders. The people signing off are clinical safety officers, hospital IT, procurement, and product owners. Most are not engineers. A remote access design that is technically sound but cannot be explained to a hospital IT manager in a page of plain English will not be approved. That is not a communication problem to be solved after the engineering. It is a constraint on the engineering.

Design first, and write the trade offs down

When you cannot easily undo a decision, you make it slowly and on paper.

For the detection platform, every significant change starts as a written design or options appraisal. Remote access to fielded devices is the clearest example. The question was how a support engineer reaches a unit behind a hospital firewall that permits nothing inbound. I wrote up the options, including build against buy, with the security implications of each. Then I wrote a second version for non technical stakeholders, because the people approving it were going to be asked by hospital IT what it did and why it was safe. Only after that did I write the implementation spec and build it.

That sounds slow. It is faster than the alternative, which is building the first idea and discovering in a customer conversation that it cannot be explained or cannot be approved.

The written trade offs matter later, too. Six months on, someone asks why the relay works this way and not that way. The answer is in the document, with the alternatives that were considered and rejected. The design doc is the reason the codebase still makes sense to the people who did not write it.

Backward compatibility is a first class constraint

In a normal product, backward compatibility is a nice to have. You version the API, deprecate the old one, and move on.

When the client is a device in a hospital that may not be updated for months, it is not optional. On the detection platform, every change to the device to cloud link is designed under one rule: no deployed unit may break. New capabilities have to land in the cloud first and stay dormant until each device picks them up on its own schedule. Old message formats keep working. Configuration pushed from cloud to device has to be something an older device can safely ignore.

The over the air update path is held to the same standard. Releases are signed. A device that cannot verify a release does not install it. A device that is mid update and loses its network has to come back up in a known state. The worst outcome is not a failed update. It is a unit that needs a site visit.

The same principle applies to the alerting platform. When I built real-time webhook delivery into each trust's own systems, each trust chose which events it wanted, how it authenticated, and where they went. Trusts rotate credentials without a code change. Adding a new event type for one trust cannot alter what another trust receives. Every trust's integration is a contract, and the contract holds while the platform changes underneath it.

Degrade safely, because silence is the worst failure

An alerting platform tells a clinician a patient is deteriorating. If it fails loudly, someone notices and picks up a phone. If it fails silently, nobody does. Silence is the failure mode you design against above all others.

In practice that means the pipeline never stops because one thing went wrong. A message that cannot be decrypted is logged and skipped, and the next one is processed. A trust endpoint that is down gets retried with backoff. A trust endpoint that returns a permanent error is not retried, because retrying a 401 forever is another form of silence. Missing configuration is logged and the record is moved past. The service processes what it can and keeps going, and everything it could not process is visible to the people who need to act on it.

Escalation is part of the same thinking. An alert that is not acknowledged does not sit there. It times out and goes to the next person. The platform assumes the first delivery might not land, and plans for it.

On the fielded devices the equivalent is the uplink daemon. It reads the device's local audit log and streams events out. When the network goes, it holds and resumes. Nothing is lost while the connection is down, and nothing on the device depends on the cloud being reachable. The detection keeps working with the cable pulled out. The cloud catches up later.

The test for all of this is deliberately dull. Take the network away, corrupt a message, point an endpoint at a dead host, and watch what the system does. It should carry on and tell you. If it stops, or carries on and does not tell you, that is a defect, and it is the one that matters most.

What this looks like day to day

None of the above is heroic. It is a set of habits.

• A design document before any significant change, with the rejected options recorded.
• A plain English version of anything a non technical stakeholder will have to defend.
• Every change checked against the oldest thing still deployed.
• Every integration specified against the trust's conformance requirements and tested against realistic message flows, not happy path fixtures.
• Failure paths tested as carefully as success paths.
• Runbooks, health checks and a process for tracking vulnerabilities in the things you depend on, because the environment will be audited and you will be asked.

If you are commissioning software for an environment like this, these are the things to ask about. How does a change reach a device that has not been updated in six months? What happens when the trust's endpoint is down for an hour? Who wrote the document that explains this to hospital IT? If the answers are vague, the discipline is not there yet.

If you are building for one of these environments

I work on medtech and healthtech products at fixed scope and fixed price. Device to cloud platforms, hospital system integrations, alerting and notification pipelines, and the secure remote access that keeps a fielded product supportable.

Every build starts with a scoping sprint. One week, £1,950 + VAT, and you get a written spec, the architecture, a delivery plan and a fixed price quote. If we go ahead with the build, the full amount is credited against it. If we do not, everything the week produced is yours to take elsewhere.