02 / Florida Blue · Oct 2020 — Dec 2021
Enrollment intake
Member-facing insurance applications on Java, Spring Boot, React, and AWS — owned from the first requirement through production support.
5+ insurance applications · 20+ APIs · 25% faster processing
members.internal/enroll
- Problem
- Member services were slow to process. A request sat long enough that support had to explain the wait instead of the decision.
- Constraints
- Existing member-facing flows on Java, Spring Boot, React, and AWS. Production traffic. No pause for a rewrite.
- Decision
- Own five healthcare insurance applications and more than twenty APIs through production support. Spend the work on SQL and service-level paths.
- Tradeoff
- Calendar time went into tests, reviews, and CI/CD instead of a sixth application.
- How it was measured
- 25% faster application processing — the résumé number. Enrollment-intake is an illustrative name for that Florida Blue work.
A health plan is a promise with machinery behind it. Members do not care how the machinery is arranged. They care whether Submit leads somewhere.
At Florida Blue that work sat behind five insurance applications and more than twenty APIs — React on the member side, Spring Boot and AWS behind it.
I stayed through production support because that is when the edge cases introduce themselves — the duplicate address, the child on two plans, the form finished on a phone in a parking lot.
- Java
- Spring Boot
- Microservices
- React.js
- AWS EC2
- S3
- RDS
- Lambda