How We Built a Cloud-Native, IAM-First Foundation a Regulated Insurer Could Compound On

The situation

The carrier was preparing for an initial production deployment of a new line-of-business platform. The brief was unusual in one respect: this was not a pilot or a proof of concept. Whatever shipped on day one would become the substrate for years of follow-on work, so any architectural shortcut taken now would compound into permanent drag later.

The platform had to be enterprise-grade from the first deployment: secure, repeatable, observable, and aligned with the organization's IAM and PAM standards. It also had to give developers a workflow in which AI tooling was a first-class citizen, not a side experiment bolted on after the fact.

The first production deployment is the foundation everything else inherits.

The challenge

Five problems had to be solved in parallel, not sequenced:

1. Stand up a production platform that was enterprise-grade on day one, not after the next refactor.
2. Put identity at the front door and map it cleanly to existing IAM and PAM procedures.
3. Make the cloud auditable and reproducible: no environment that could not be rebuilt from code.
4. Design the developer experience so that individual velocity would increase year over year rather than plateau.
5. Embed AI tooling in the daily workflow so the productivity gains were structural, not personal.

Solving any one of these is straightforward. Solving all five inside a single initial deployment, without compromising any of them, is the foundation problem.

The approach

We designed a cloud-native architecture grounded in three principles: infrastructure-as-code for everything, identity at the front door, and developer velocity as a measurable design goal. Each principle showed up as a concrete decision the team could point to during code review, not as a slogan on a slide.

The operating model

A small ExeQut delivery team worked alongside the carrier's engineering, security, and IAM counterparts. The cadence was built around CI/CD as the unit of progress: governance, security review, and change control were embedded in the pipeline rather than added as gates after the fact. That choice mattered downstream. Once governance lives inside the pipeline, every subsequent feature inherits it for free.

The technical architecture

The platform is built around three primary microservices deployed on AWS. Java services sit behind an Angular front end, with Camunda providing workflow orchestration for the business processes that span them. The service split was deliberately conservative; the goal was a foundation that could absorb new capabilities without rework, not a microservice count that looked impressive on an architecture diagram.

A small set of well-bounded services beats a large set of fashionable ones, especially when the platform has to last.

Identity at the front door

Authentication and authorization were not deferred. From the first deployment, the platform sat behind Microsoft Entra SSO with role-based access control mapped directly to the carrier's internal IAM and PAM procedures. Every service, environment, and administrative path was accessed through the same identity plane, with a zero-trust posture toward implicit trust between components.

This was the decision that paid back the most over time. Retrofitting identity into a running platform is one of the most expensive forms of technical debt a regulated organization can take on; building it in from day one removed an entire category of future cost.

Infrastructure as code, end to end

Every environment was provisioned and managed through Terraform. There were no manual cloud changes, by policy and by enforcement. Database schema changes were managed through Liquibase and shipped through the same pipelines as application code. CI/CD pipelines existed for every deployment path, including the ones that organizations typically leave manual.

The result was a platform whose state could be fully described by the contents of the repository. Environments were reproducible, audits were tractable, and recovery was a function of the pipeline rather than the operator.

Either every change is reproducible from code, or it isn't. There is no middle ground that survives an audit.

Developer experience as a first-class concern

The repository structure, branching model, and pipeline design were chosen so that individual developer velocity would compound year over year rather than plateau after the first few sprints. AI tooling was embedded directly into the daily workflow, treated as a first-class component of the development environment rather than an optional extra.

The point was not novelty. The point was that the cumulative effect of small, structural friction reductions, applied every day, dwarfs anything a single feature delivers.

The outcome

The platform shipped to production as a cloud-native foundation with full infrastructure-as-code visibility and auditability. Identity controls were aligned with the carrier's enterprise IAM and PAM standards from the first deployment, with no later retrofit required. Individual developer velocity has compounded across subsequent delivery phases, in the direction the architecture was designed to encourage.

Most importantly, the foundation has done its job: it has supported every subsequent phase of the modernization without requiring a teardown. New capabilities have been added on top of the original architecture rather than around it, which is the proof point that matters most for an initial deployment.

What we took from it

1. Treat the first production deployment as the most consequential architectural decision a program makes. Everything that follows inherits its assumptions, including the bad ones.
2. Identity belongs at the front door, before the application layer. Retrofitting IAM and PAM into a running platform is one of the most expensive forms of debt a regulated organization can carry.
3. Infrastructure-as-code is not a tooling preference; it is what makes every subsequent audit, environment, and rebuild tractable. "Mostly as code" does not survive contact with a real audit.
4. Developer velocity is a design goal, not a soft outcome. If it is not measured and structured for, it plateaus.
5. AI tooling pays back when it lives inside the daily workflow, not next to it. First-class integration is the difference between structural gains and personal ones.