What shipped
- 586 endpoints spanning quoting, enrollment, funding, claims and reporting across nine user roles
- Eleven external systems integrated, from carrier marketplaces to banking and payroll
- Money movement under dual control, with a second factor above a configurable threshold
- Security remediation across roughly 25 sites where record identifiers could be altered
The situation
A growing number of employers have stopped buying a group health plan and instead give employees a fixed allowance to buy their own coverage. It is simpler for the employer and better for a lot of employees. It is considerably harder for whoever has to operate it.
Six parties are involved in a single month of coverage. The employer funds an allowance. A broker advises on plan design. The employee shops a public marketplace and picks a plan. A carrier bills a premium. A bank moves the money. Payroll deducts the balance. Each one runs on its own schedule, in its own format, with its own idea of when a number is final.
How we framed the problem
The hard part of this domain is that no participant sees the whole transaction. Everyone holds one accurate fragment and assumes the rest lines up. When it does not — an employee changes plan mid-month, a carrier restates a premium, a bank transfer fails — the discrepancy surfaces somewhere far from where it started, usually as a person on the phone asking why their paycheck is wrong.
So the modeling work was less about features than about establishing, for every fact in the system, where truth lives. Which party is authoritative for a premium amount? For an effective date? For whether a payment cleared? Once that is written down, reconciliation stops being a monthly spreadsheet exercise and becomes something the system does continuously, flagging the small number of cases where authoritative sources genuinely disagree.
The second decision was to treat every external system as a translation problem rather than a data source. Each integration sits behind its own adapter that converts a partner's view of the world into the platform's. When a partner changes their contract — and they do — the change is contained to one place instead of rippling through the application.
The system we built
A single platform serving nine different kinds of user, from platform operators to brokers to the employees themselves, with what each can see and do driven by their role.
Work that takes minutes rather than milliseconds — an open enrollment period, a bulk employee import, a month of claims — runs as a background job that reports progress back to the browser as it goes, instead of leaving someone watching a spinner and wondering whether to refresh. Documents that people need as paper — plan documents, required notices, receipts, agreements — are generated from templates on request.
Because it is a regulated market handling money and health information, the security posture is part of the design rather than a layer on top: record identifiers are encrypted rather than sequential, secrets live in a managed vault, and the whole flow is available in English and Spanish.
What was hard
Employer spreadsheets arrive in every conceivable shape. Every employer tracks its people differently — different column names, different orders, different notions of what a dependent is. Someone had to reconcile each new file against the platform's schema by hand, which was slow and error-prone at exactly the moment a new client forms their first impression. We used a language model to propose the mapping, scoring its own confidence for each column, with a person confirming before anything is imported. The model does the tedious part; the human keeps the final say.
Moving money had to be both fast and hard to get wrong. Transfers between employer accounts and the platform's banking partner needed to be quick for the common case and genuinely difficult to do by accident or malice. The design layers the checks: the direction of the transfer is explicit, the operator's role is verified, the approver must be on a named list, and above a configurable dollar amount a second factor is required. Every transfer records who requested it, from where, and on what device.
A class of flaw let identifiers be tampered with. Record identifiers appearing in URLs could be altered to reach another party's data. Fixing it was not one patch but a program of work across roughly 25 sites, paired with encrypting identifiers so that guessing a neighbouring value stops being meaningful.
Stack
.NET 8, ASP.NET Core, Entity Framework Core, Azure SQL, Azure Key Vault, Azure OpenAI, SignalR, background job workers.
Where it stands
The platform runs the full lifecycle in production — quoting through enrollment, funding, claims and reporting — for employers, their brokers and their employees.
A note on what is not here
We are not publishing business outcomes for this engagement. The measurements that would matter — enrollment volumes, reconciliation effort saved, support load — belong to the client, and we have not been given permission to share them. Everything above is drawn from the system itself and can be walked through in detail on a call.