My Technical Range

Examples of my technical judgement.

Most technical portfolios list features shipped. This one is organized around judgment calls instead, the moments where a nontrivial trade-off got made and why. It covers two healthcare products built and largely launched solo, indexed across eight sections below.

How this page is organizedClick any box to open its sharpest examples.
Player means hands-on executionCoach means strategic judgmentThe bar in each box shows the splitShaded box is openDashed box has no examples from that productOpen a product box to see its share of each section, like 8 of 16
Product 01

Medical Claim SaaS Platform

Helping people appeal wrongful health insurance denials

90%CI-enforced coverage floor on the LLM inference client

A SaaS platform that reads a scanned denial letter, matches it against a statutory deadline and eligibility engine, drafts a formal appeal letter, and sends it through whichever channel the payer actually requires, whether that's mail, fax, or portal.

What made it hard

Every decision that determines someone's legal eligibility had to be deterministic and auditable, never an LLM's best guess. The parts that are LLM-assisted, reading the denial letter and drafting the appeal, had to be structurally walled off from the protected health information underneath a case. This was built and largely launched solo, which meant carrying product, architecture, an independent security review, and on-call all the way through a regulated-industry launch.

What made it worthwhile

Health insurance denial rates have been climbing industry-wide, and most people who get denied never appeal at all. That's not because they don't have a case. It's because the process is opaque and the deadlines are unforgiving. This turns a multi-week paperwork problem most people give up on into something that actually gets filed correctly and on time.

Repositories3 (API, web, infrastructure)
Code~185,000 lines (117K Python, 55K TypeScript, 13K Terraform)
Pull requests442 (425 merged) across ~1,850 commits
Tests2,994 backend test functions, 268 frontend test files
Coverage gate90% CI-enforced floor on the LLM inference client
InfrastructureAWS ECS Fargate, PostgreSQL, S3, CloudFront, Terraform-managed
Product 01Click a box to read this product’s examples. Dashed means none.
Product 02

Payor Rate Data Platform

Making a regulatory mandate's data actually usable

44.3Mdeduplicated rate records from ~719M raw rows

A data platform that ingests the machine-readable pricing files U.S. health insurers are now required to publish. It collapses them from raw claims-level rates down to a queryable per-provider, per-procedure database, and exposes that database through a chat interface with row-level entitlements.

What made it hard

The raw feeds arrive at a scale that breaks naive pipelines outright. A single payer's monthly file can run to hundreds of millions of rows, and one early version of the pipeline died to disk exhaustion trying to stage a month of it before deduplication. The chat layer introduces its own problem class. Prompting isn't a security boundary, so entitlements had to be enforced by rewriting the SQL a model generates, not by asking it nicely. That work surfaced a real gap in a third-party SQL parser, and a wholly new "the model anchors on its own stale turns" bug class that no database-level guard could have caught. On top of the technical scale, payer data-use terms differ payer by payer, so some sources are structurally excluded from extraction rather than just flagged off.

What made it worthwhile

Price transparency in U.S. healthcare is a real regulatory mandate. But the raw files get published as an enormous compliance exercise that nobody can actually use. This turns that opaque legal requirement into something a patient, employer, or researcher can query in plain language.

Repositories3 (pipeline, web, infrastructure)
Code~130,000 lines (44K Python, 81K TypeScript, 5K Terraform)
Pull requests201 (200 merged) across ~820 commits
Tests1,161 pipeline test functions, 169 frontend test files
Data scale44,340,007 deduplicated rate records from ~719M raw rows ingested in the most recent full measurement cycle
Product 02Click a box to read this product’s examples. Dashed means none.
01Product Management & Judgment CallsRefused fabricated stats, sequenced launch gates, killed features that couldn't be built honestly.playercoach02Software ArchitecturePHI firewalls as data-shape contracts, two aggregates joined loosely, not by foreign key.playercoach03Development CraftRoot-caused silent classification bugs, closed a five-day CI gap that hid a payment defect.playercoach04DevOps / Infrastructure-as-Code / AWS"Merge is the apply" as governance, plan-time preconditions against crash-looping services.playercoach05AI/LLM EngineeringDeterministic-first design as a safety invariant, hallucination guardrails on every call.playercoach06Data Engineering at ScaleRetired a disk-exhaustion failure class structurally, not with a bigger box.playercoach07Security & ComplianceIndependent security review before real patient data, audit-log immutability proven by a failing test.playercoach08Incident Response & Operational MaturityFail-closed over silent restoration, a nine-minute perimeter exposure treated as an experiment.playercoach
productarchitecturedev craftdevopsAI/LLMdatasecurityincident

From 0 to 1

Ten judgment calls from early build through post-launch scale-up, in the order they actually happened. Filter by stage, or read the whole run.

Early buildMedical Claim SaaS Platform

I kept the eligibility engine fully deterministic. No LLM involved. That one decision decides who's allowed to appeal. Too important to leave to a guess.

Early buildPayor Rate Data Platform

I split the data into two tiers. A small, fast set serves the app. A much bigger archive just captures everything raw. Skip that split and you're stuck. Either the live database grows forever, or you throw away pricing data the moment nobody's using it yet.

Pre-launch hardeningMedical Claim SaaS Platform

I paid for an outside security review before launch. I held the platform on fake data until the worst finding got fixed. That cost real time and real revenue. But real patient data didn't touch the system until that gap was closed. Not before.

Pre-launch hardeningMedical Claim SaaS Platform

I found a channel that quietly told users their appeal letter had sent, when it hadn't. No error. Just silence. So I made it fail loud instead of patching it quiet. A silent fix means letters keep vanishing while someone's deadline runs out and they never know.

Pre-launch hardeningPayor Rate Data Platform

Our SQL filter was a denylist. It missed most of the dangerous functions it should've blocked. I flipped it to an allowlist instead. Small. Provably complete.

Launch weekMedical Claim SaaS Platform

I built launch as four gates. Each one needed a fully verified runbook before the next could open. Nobody could shortcut a step under deadline pressure. The sequence itself was the safety net. Not a checklist someone could skim past.

Launch weekPayor Rate Data Platform

I deliberately opened a locked-down service to the public internet for nine minutes. I just wanted to watch what real traffic did. It worked. But I was careful not to confuse that with 'safe to leave open.' Those are two different claims.

Post-launch scale-upMedical Claim SaaS Platform

I swapped our GPU compute for cheaper CPU-only infrastructure. I didn't touch the queue in front of it. That boundary meant I could test the whole migration and roll it back same-day if it broke. No gambling with cases that were already mid-flight.

Post-launch scale-upPayor Rate Data Platform

I spent days chasing a bug where our AI kept insisting a customer's access hadn't changed. Every database row said otherwise. Every permission check said otherwise. Every audit log said otherwise. The system underneath was telling the truth. The model was the only thing still lying, quietly, on its own.

Post-launch scale-upPayor Rate Data Platform

A disk-exhaustion bug once took down a production load. So I moved raw-volume staging out of the database entirely, into its own pre-aggregation step. That didn't just fix the bug. It moved the bottleneck somewhere it can't cause that failure again, at any scale.