The gap NexaCare goes after is comprehension. Most people don’t know what their benefits cover, what they’ve already used, or what a procedure will cost them. The information exists. It’s just written for insurers instead of for people. So NexaCare reorganizes it around the questions you’d actually ask: am I covered for this, what will it cost me, and how much of my limit is left?

It’s React with TypeScript throughout, and the type system paid for itself almost immediately. Benefits data is deeply nested and full of edge cases: coverage tiers, deductibles, co-pays, per-category limits. Modeling it precisely killed whole categories of bugs before anything ran. The app has a coverage dashboard for plan status at a glance, breakdowns by category, and usage tracked against limits.

The hardest problems were design problems dressed as engineering ones. Healthcare data is dense, and every screen was a negotiation between showing enough to be trusted and recreating the overwhelming PDFs the app exists to replace. Architecture mattered at that scale too: shared state for plan data, composable display components for the many benefit types, and the same careful handling of loading, empty, and error states everywhere.

NexaCare is where my frontend work came together. TypeScript discipline, component design under real complexity, and the instinct that the best interface for complicated information is the one that makes it feel simple.