Domains change.
The way I build
doesn’t.

The first system I put in front of real users. It ran the whole hiring loop — candidates searching and applying, employers posting and reviewing, and an application pipeline that moved people through stages without anyone losing track of where a candidate actually stood.

What made it more than a job board was compliance. Care work has a legal bar to clear before anyone meets a client, so background verification and police checks ran alongside the application itself. A candidate was never simply “applied” or “hired” — they sat at a specific point in a verification chain, and the interface had to make that state unambiguous to every party looking at it.

The largest surface area I have worked on. It carried the full lifecycle: onboarding for several distinct user types, plan selection with popular plans surfaced, document generation and verification, claims and claim filing, benefits and accumulator management, member ID cards, invoicing and billing.

It also ran the commercial side — agents and agencies, their hierarchies, and the commissions owed against each sale — plus the third-party and vendor integrations for data the platform could not own itself.

The piece I would point a reviewer at is the configuration layer. Flows, content and input rules were all driven by configuration an admin could change, so a large share of client requests never became a release at all. That single decision is what let the product keep moving as its surface kept growing.

I lead this project and the team behind it. Members enrol in a yearly programme and receive defined benefits across the hospitals and clinics in their chain at no cost or minimal cost — bought either by individuals or by companies on behalf of their employees.

Every client is a hospital chain, often spanning several US states, and no two want the same thing. Rather than forking behaviour per client, the product is driven by configuration an admin controls. That is what keeps ten-plus tenants on one codebase instead of ten, and it is why a new client requirement is usually a settings change rather than a sprint.

The data does not come from one place either. Vendors sit in the middle for eligibility and other records moving between the platform and the hospitals, so a real share of the engineering is integration contracts and the failure modes around them — what happens when a feed is late, partial, or disagrees with what we hold.

It covers physical health, emotional health, relationships, environment, passion and values or spirituality — turning each into personalised activities and guidance rather than one more generic checklist.

The interesting engineering is pacing and personalisation: what to suggest next, how to keep someone coming back without nagging them, and how to show progress across six dimensions at once without the interface collapsing into a dashboard nobody reads.