Notes · Engineering

Building the Army E-EFMP System: From Paper to the Cloud

Some projects are interesting because of the technology. This one was interesting because of the paper it replaced.

The program nobody sees until they need it

The Exceptional Family Member Program supports Army families whose members have special medical or educational needs. It is exactly the kind of program that has to work, quietly, for people who already have a lot on their plate. For years it ran on paper: enrollment forms, screening packets, provider approvals — physically re-submitted every time a family moved to a new installation.

If you have ever moved households, imagine doing it every couple of years and having to re-prove your child's medical needs by mail each time. That was the baseline we were replacing.

Three developers, every hat

We were a team of three, building the whole platform from scratch. There was no "the frontend person" or "the backend person." You owned a feature from the database to the button, and the next week you owned a different one. It is the kind of constraint that sounds stressful and is actually clarifying — there is nowhere to hand off a problem, so you just learn the whole thing.

The real work was the workflows

The hard part of E-EFMP was never "render a form." It was modeling the lifecycle of a packet, a family, a provider, and a policy — and the states each of them moves through — so that every stakeholder could see exactly where a case stood without calling anyone. Once those status models were right, the automation followed: approvals that used to travel by mail became in-app review and sign-off, and weeks of waiting collapsed into the time it takes someone to click.

We also wired installation directory listings to the Army's existing APIs, and built an in-app community forum with per-installation chat rooms so families could actually talk to each other and get local updates — the social glue a paper process never had.

What I'd tell another engineer

The technology mattered less than getting the state machine honest. If the statuses reflect reality, automation is almost boring to add. If they don't, no amount of clever code saves you. That is the lesson I have carried into everything since.

I keep the architecture and exact stack vague on purpose — the work required a security clearance and the program was conservative about what got disclosed. This is the "what we delivered" version, by design.

See the structured case study on the Work page, or head back to all notes.