Building Software for Regulated Industries: Insurance, Healthcare, and Government

I'm Tom Lang — I've built and scaled engineering organizations for three decades, from startups to 250-plus engineers and through multiple acquisitions, and I work as a fractional and interim CTO for growth-stage companies, with particular depth in regulated and integration-heavy environments.

Here's the sharpest way I can put it: in consumer SaaS, you optimize for engagement. In regulated industries, you optimize for defensibility.

When you sell into healthcare, insurance, or government, every single state change in your database is a potential legal event. You're not just building software — you're building an airtight, mathematically provable record that has to survive a federal auditor or a lawsuit. I learned this the long way, shipping across regulated markets for decades: insurance and annuity commission systems, a ten-year federal contract delivering software across agencies of the Department of Health and Human Services, and a third-party-administrator platform running health, life, and disability products. That reality fundamentally changes how I build and lead engineering. Here's how.

The architectural reality

You cannot take a consumer SaaS architecture and sell it to a hospital. Regulated software demands foundational patterns that consumer apps never need.

Immutable audit trails. You can almost never just UPDATE or DELETE a row. You use append-only event logs. If a patient's dosage changes, I don't overwrite the old value — I write a new record. I have to be able to prove exactly who changed it, when, and what their authorization level was at that specific millisecond. History isn't a nice-to-have; it is the product.

Bitemporal, time-travel correctness. If a regulator asks why an insurance claim was denied two years ago, you cannot run today's logic against today's data and hand them an answer. You have to architect the system to recreate the exact state of both the data and the rules engine as they existed on that specific date. The system has to remember not just what it knew, but how it thought, at every past moment.

The delete paradox. "Delete" in a regulated system is a legal concept, not a database command — and the legal concepts contradict each other. You build soft-delete and tombstoning to satisfy seven-year retention laws, while simultaneously building cryptographic shredding to satisfy GDPR/CCPA "right to be forgotten" mandates. You're required to keep it forever and required to make it unrecoverable, and the architecture has to do both. (This is where right-sized governance around data and access stops being optional.)

The rookie mistake: the bolt-on illusion

The single most fatal mistake a consumer-SaaS team makes entering these markets is what I call the bolt-on illusion.

They move fast, build a standard CRUD application, and try to sell it into a regulated vertical. Then the hospital's procurement team demands role-based access control and HIPAA-compliant audit logs — and the team assumes they can just slap those on in a two-week sprint. They can't. You cannot bolt an audit trail onto an architecture that was never designed to remember its own history. Getting there requires a massive, months-long architectural rewrite — which invariably happens while the sales deal dies on the vine. The defensibility has to be in the foundation, or it isn't real.

The scar: versioning the math itself

Years ago I oversaw the architecture for a complex insurance commission system. It wasn't enough to calculate a broker's payout and cut the check. Regulators required us to prove why a broker received a specific dollar amount — sometimes months or years after the fact.

So we architected a system that didn't just version the data; it versioned the math itself. We built a rules engine where the payout formulas were immutable. When state laws changed, we didn't update the formula — we created a new version of it with an effective date. Which meant that if an auditor showed up three years later, the system could literally replay history: fetch the exact mathematical formula that was legally active on that specific Tuesday, run it against the data as it existed then, and prove the payout was flawless. That's what defensibility looks like in practice — and it's the kind of thing you can see in the F&G work on my results page. You don't add it later. You build the whole system around it from the first line.

Why this is your moat

If you're a founder selling into a regulated vertical, here's the uncomfortable truth: a brilliant CTO who has only built consumer apps is an existential risk to you. They will build you a beautiful, blazing-fast product that you legally cannot sell — and you won't find out until the enterprise contract hinges on a technical audit you can't pass.

Having a CTO who has actually shipped in these environments is your moat. I don't treat compliance as a tax on engineering velocity; I treat it as a core feature of the product. I architect the defensibility into the foundation on day one — so when a massive enterprise deal comes down to a brutal technical audit, your software isn't a liability that kills the deal. It's the reason you win it. (Passing the specific SOC 2 audit is a piece of this, but the deeper work is architectural.)

The honest goal

So if you're building for insurance, healthcare, or government: optimize for defensibility, not engagement. Make your system remember its own history, let it replay the past exactly, and treat compliance as a foundation rather than a feature you'll add before the big deal. Do that and the regulated market — the one that scares off most of your competitors — becomes the moat that protects you.

If you're selling into a regulated vertical and need an engineering leader who's actually shipped software that survives a federal audit, that's exactly what I've done. Book a call and we'll make sure your architecture is the reason you win, not the reason you lose.