People are surprised that we work in both healthcare and electric utilities. They sound like unrelated industries — one is regulated by health authorities, the other by reliability councils. Different customers, different acronyms, different software stacks.
Look at the engineering problems, though, and the same patterns keep showing up. After enough years across both, we've stopped thinking of them as separate verticals and started thinking of them as a single category: systems where being approximately correct isn't good enough.
Here are five things they share, and what each one means for how you build software for them.
1. Compliance is an engineering constraint, not a checkbox
In a typical SaaS, compliance is something the legal team handles after launch. PHI gets sprinkled with a "we use SSL" disclaimer; an annual SOC 2 audit fixes whatever surfaced. The product doesn't change shape because of it.
In healthcare or grid operations, that doesn't work. HIPAA changes what data your analytics can see. NERC-CIP changes how systems talk to the outside world. PIPEDA changes what's allowed to leave the country. The compliance regime is a structural input to the architecture, not a bolt-on.
This is why "compliance-aware" is a phrase we use deliberately. It's not the same as "compliant." Compliant is a binary. Compliance-aware is a design posture — building so the compliance answer is yes by construction, instead of by retrofit.
2. Integrations are the product
Both industries are old. Hospitals have systems that predate the modern web. Utility substations have devices that were installed when the engineers who installed them were apprentices.
A new product in either space rarely gets to define its own data model from scratch. It has to talk to what's already there: HL7 v2 messages from the EHR, FHIR resources from the integration engine, IEC-61850 reports from the substation, DNP3 traffic from the SCADA. The product's value is often the integration, not the application logic sitting on top of it.
This shifts the engineering effort. The clean part of the codebase — the React frontend, the typed business logic — turns out to be a thin sliver of the system. Most of the actual engineering happens at the protocol layer, the message translation, the schema evolution.
3. Determinism is a feature
In consumer SaaS, retry-on-failure is fine. The user clicks the button again. In a regulated environment, a duplicate submission can be a compliance event. A retried message can confuse a downstream system that's already acted on the first one. The same input has to produce the same output, every time, traceably.
This pushes everything toward idempotency, audit trails, message deduplication, and observability. Not as nice-to-haves — as load-bearing pieces of the architecture.
4. The half-life of code is measured in decades
The first version of your healthcare SaaS will outlive most of the engineers who wrote it. The first version of a utility's operational software is probably still running, somewhere, in some form.
When you write code that will outlive its authors, you write it differently. You favor boring over clever. You comment the why, not the what. You design for the team that will pick this up in eight years and have to figure out what you were thinking.
This is mostly about restraint. Don't add the abstraction. Don't introduce the framework. Use the simplest approach that solves the problem, because every layer of cleverness becomes a layer of obstacle for the team that inherits it.
5. Failure modes are operational, not technical
A bug in a consumer app is a bad day for the user. A bug in a healthcare data platform can be an audit. A bug in a utility's operational software can be an outage event with regulatory consequences.
This changes what you optimize for during a build. Velocity matters, but it's bounded by an enforceable definition of done that includes things like runbooks, observability, and operational handoff. Shipping the feature is the start of the work, not the end of it.
There's a kind of engineering discipline that emerges from working in these environments. It values durability over novelty. It treats integration and compliance as design surfaces. It assumes the system will outlive the team and writes accordingly.
We've found that this discipline transfers. The teams we work with in healthcare ask about the patterns we picked up in utilities. The utility teams want to know how we handle data lineage in healthcare analytics. The vocabulary is different; the underlying engineering is the same.
If you're building software in either of these spaces — or in any environment where the cost of a careless decision is bigger than a bad sprint — that mindset is worth more than any particular tech-stack opinion.