The gap NexaCare targets is comprehension. Most people don't know what their health benefits cover, what they've used, or what a procedure will cost them — not because the information doesn't exist, but because it's presented in formats designed for insurers rather than humans. NexaCare reframes benefits data around the questions people actually ask: Am I covered for this? How much will it cost me? How much of my limit is left?

The platform is built in React with TypeScript throughout, and the type system earned its keep immediately — benefits data is deeply nested and full of edge cases (coverage tiers, deductibles, co-pays, per-category limits), and modeling it with precise types caught entire classes of bugs before runtime. Features include a coverage dashboard summarizing plan status at a glance, plan breakdowns by category ([dental, vision, prescription, paramedical]), usage tracking against limits, and [claims exploration / cost estimation — confirm scope].

The hardest problems were design problems wearing engineering clothes. Healthcare data has enormous informational density, and every screen was a negotiation between completeness and clarity — showing enough to be trustworthy without recreating the overwhelming PDFs the app exists to replace. Component architecture mattered at scale: shared state for plan data, composable display components for the many benefit-type variations, and consistent handling of loading, empty, and error states across the app.

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