What logistics software taught us about building reliable systems for regulated sectors

Most of our work since 2003 has been in shipping and vehicle logistics. That’s the Tier 1 vertical for Team Bison and the operating reality for the wider Bison Grid Ltd group — four production platforms with named customers including Siem Car Carriers, TOTE Maritime, the Wallenius Wilhelmsen partner network and Petrucela & Co.

We also work in NHS (BNSSG’s My Joint Health Hub), legal (Clarke Willmott), and medical (Harley Medical Group). We treat those as a defended “we also work with” book — not the headline of the business, but real long-running engagements with real regulated buyers.

People sometimes ask us how the move between sectors works. Are logistics engineers really comfortable building for a clinical context? Do legal customers want a vendor that’s better known for moving cars? The honest answer is that almost everything we learned about reliable software in shipping transfers directly. Here’s what.

Cargo doesn’t wait for code to ship

There’s a useful operating fact about logistics software that doesn’t apply to most other categories: the physical thing is already moving. A vessel is on the water. A car is on a transporter. An ePOD scan is happening at a port at 5:30am. The software cannot say “back in five minutes, doing a release.” Whatever you ship has to work in real operating time, against real operating constraints, on real operating hardware.

That discipline transfers cleanly into NHS, legal, and medical contexts. A patient is on a digital care pathway. A solicitor is meeting a deadline that statute won’t move. A clinic is taking a booking against a real chair in a real diary. The systems all share the same underlying property: a real-world process is depending on the software to be there and to be right, and the cost of being wrong is not a brand impression but a downstream operational consequence.

Reproducible deployments are not optional

In a brochure-site context, you can get away with editing files on the live server and hoping for the best. In a production logistics context, “we edited the file on the live server” is the first sentence of an incident write-up. The same applies in regulated sectors.

What this looks like in practice: environment parity (your staging is genuinely like production), versioned deployments, database migrations that run in repeatable order, the ability to roll back cleanly, and an audit trail of what was deployed when by whom. None of this is exotic engineering. It’s just the engineering discipline you’re forced into once a customer’s operation depends on you.

Monitoring before features

If a system has to be reliable in production, the question “how would we know if it stopped working?” has to be answered before the system is in production, not after. We learned this from shipping operations where a missed status update can ripple into berthing delays and OEM compliance issues. We apply the same discipline on NHS patient pathways and on legal-sector platforms where a quiet error in a workflow can put a deadline at risk.

The cheapest part of the engineering budget is monitoring. The most expensive part is finding out from a customer that something broke six hours ago.

Conservative tech choices age better than fashionable ones

There’s a category of engineering decision that looks good in a pitch and ages badly in production. The newest framework version. The bleeding-edge cloud service. The exotic database. Sometimes those choices are right. Mostly, they age into liabilities — undocumented, sparsely supported, hard to hire for, and a quiet tax on every future engineer who joins the project.

Bison Exchange has been running production OEM EDI booking for car-carrier shipping operators for over ten years. It is not built on whatever the most fashionable choice was in 2014. It’s built on choices that were already mature and well-understood at the time, and as a result it’s still a comfortable system to work in. The same logic applies to a long-running NHS platform or a legal case management system — you optimise for the team that will be maintaining it in 2030, not for the architecture diagram in this quarter’s pitch.

Data handling that survives an audit

Logistics work has taught us to think about data the way an auditor would. Who created this record? When? Were they authenticated? Was it modified? By whom? Can we prove that?

Shipping operates under IMO and DVSA frameworks. Vehicle logistics operates under various OEM data contracts. Customs operates under HMRC CDS. NHS work operates under DSPT and DTAC. Legal and medical work operates under their own GDPR-derived obligations. The frameworks differ; the underlying engineering discipline is the same. Treat data as something that may have to defend itself in front of an auditor, and you build systems that survive scrutiny across all of those regimes.

Clear ownership for “what happens at 3am”

In shipping, something will break at 3am eventually, and someone will need to act on it. The same is true of any other regulated system. The question isn’t whether — it’s whether the operating model has a clear answer.

For us that means named on-call rotations, runbooks that actually correspond to current systems, and escalation paths that don’t depend on a particular individual being awake. It also means that the answer to “who looks after this in five years’ time” is not “we hope the original developer is still around.”

This is the discipline that scaled from shipping into the rest of the work. A clinic doesn’t want a different answer to that question than a car carrier does. They want the same one.

What doesn’t transfer

It’s only fair to mention the things that don’t transfer. Shipping fluency doesn’t make you a clinical safety expert; you have to learn that. Vehicle logistics doesn’t teach you legal-sector confidentiality conventions; you have to learn those. Operating heritage in one sector earns you the right to be taken seriously while you ramp up on another, but it isn’t a substitute for actually doing the work.

What it does transfer is the engineering posture: the assumption that this thing will run for years, against real users, in real conditions, where being wrong has a cost. That posture is rare. It’s also the thing most worth hiring for.

---

Team Bison is the software, AI and operations consultancy within the Bison Grid Ltd group. We’ve been building production software for businesses where reliability matters since 2003 — shipping and vehicle logistics as our Tier 1 specialism, with NHS, legal and medical work as a defended part of our book.