Self-Service Health-Insurance Enrollment Platform

I. System Context & Constraints

Technical reality: An insurance operator sold Fortune-100-level PPO health plans to individuals — sole proprietors, retirees, the self-employed — through a PEO co-employment model. The entire enrollment journey was paper-based and manual: every application meant hand data-entry, no central system, and pricing changes that required rebuilding marketing materials by hand.

Director’s constraints: The data was highly sensitive (Social Security numbers, payment details), so the build had to be compliant and secure from day one. Pricing had to update quarterly without re-pricing existing customers, and a marketing site plus a transactional app had to read pricing from a single source of truth — no duplicated, drifting data.

II. Critical Path & Architectural Choices

We split the product into a WordPress marketing site and a Next.js / TypeScript enrollment application backed by PostgreSQL, joined by one deliberate seam: a lightweight pricing API as the single source of truth. Both the marketing quote form and the React enrollment flow call the same /api/pricing endpoint, so a quarterly price change publishes everywhere at once with zero data duplication.

Security drove the rest of the architecture. SSNs are encrypted client-side before they ever reach storage and only decrypted in the admin context; admin access uses JWT auth with refresh tokens, session timeout, and rate limiting. Payments run through Stripe (Elements, subscriptions, and webhook-driven status reconciliation) with duplicate-submission detection and graceful payment-failure handling, all deployed via CI/CD.

III. Governance, Risk & Team Topology

I directed delivery across six cross-functional teams — planning, product, design, web, engineering, and QA — sequenced into a milestone plan from wireframes through core backend, the five-step enrollment form, the submission pipeline, the self-service pricing engine, customer and admin dashboards, QA, launch, and a later rebrand-and-domain migration.

Risk centered on PII and money. We enforced a security review (SQL injection, XSS, CSRF, auth-bypass), eight core end-to-end test scenarios, WCAG 2.1 AA accessibility, and a 30-day post-launch support window with a clean client-owned handover of code, credentials, and documentation.

IV. Quantifiable Outcomes