✦ Highlights

Six pieces I'd actually hand you if you only had ninety seconds — the decisions behind them, and proof they're real, not just described.

Android · SMART on FHIR

CHART

A clinical viewer that logs into a hospital's real records system the way it's actually supposed to be done — not a demo pretending to.

Problem
Most "health app" portfolio pieces fake the hard part. Healthcare orgs don't care that you can render a patient card — they care whether you understand how a third-party app earns the right to see one.
Decision
Full SMART App Launch: OAuth2 Authorization Code + PKCE via AppAuth-Android, against SMART Health IT's public sandbox — the same handshake Epic and Cerner/Oracle Health require in production. No backend, deliberately: PKCE exists so public clients don't need one. No persistent storage of clinical data, ever — only an encrypted refresh token survives between sessions.
Outcome
A working end-to-end login → token exchange → live patient fetch, with every architectural choice written down as an ADR before the code existed.
SMART App Launch sequence: CHART app authorizing against the SMART Health IT sandbox, then fetching a patient record CHART (Android) SMART Sandbox 1 · Authorize (PKCE code_challenge) 2 · Redirect + authorization code 3 · Token exchange (code_verifier) 4 · access_token + patient id 5 · GET /Patient/{id} (Bearer) 6 · Patient resource (JSON)
The actual SMART App Launch handshake CHART implements — not a simplified stand-in.
Android · Dietary Planning

MEND

Meal plans built around the thing your body won't forgive you for eating — lactose, gluten, whatever the list is.

Problem
Allergen-safety data is only useful if it's trustworthy, and only free if nothing behind it costs money at scale.
Decision
A curated, vetted dataset lives on-device as the trusted default — the app works fully offline from day one. An optional Cloudflare Worker can expand results from a free-tier recipe API when online, clearly labeled by source so a quota running out never quietly looks like "no results."
Outcome
An app that's honest about what it knows for certain versus what it's borrowing from elsewhere — and an in-app update checker + signed release pipeline, since there's no Play Store doing that for it.
MEND's on-device architecture: Compose UI over a dietary rules engine, backed by a curated dataset with an optional Worker-based expansion path Compose UI meal plan · recipe browser Dietary rules engine filters by restriction, no framework dep Room — curated dataset always available, works offline Worker → recipe API optional expansion, clearly labeled free-tier recipe API (when online)
No backend required for the trusted path — only for the optional one.
Nine languages · One engine

The Chess Engine, Nine Times Over

The same algorithm, built from scratch nine separate times, just to feel what each language is actually like to think in.

Problem
Anyone can claim to "know" nine languages. Almost nobody can show the same non-trivial problem solved idiomatically in all nine, against the same test oracle, with the same coverage bar.
Decision
An alpha-beta minimax chess engine with piece-square tables, independently implemented in Kotlin, Rust, Go, Python, Swift, C++, Dart, Java, and JS/WASM — same legal-move oracle, same benchmark suite, so the languages are actually comparable rather than nine unrelated toy projects.
Outcome
A live, interactive dashboard comparing them head-to-head — nodes/second, verbosity, safety tradeoffs — not just a claim, a chart you can look at.
Cloudflare Worker · Disposable Email

Anonymail

An inbox that exists just long enough to be useful, then forgets you entirely — on purpose.

Problem
Disposable-email services are everywhere; trustworthy ones that explain their own security model are rare.
Decision
AES-256-GCM encryption in memory, nothing ever written to disk, inbox lifetime capped at an hour by design — the constraint is the feature, not a limitation apologized for.
Outcome
It's not a mockup. It's running right now, and you can generate an inbox in the next ten seconds.
Cloudflare Workers · Claude AI

ELINAL

Supreme Court opinions, decoded — the kind of case that shaped the country, made to actually want reading.

Problem
Landmark opinions are either flattened into a one-line pop-history take or left in original text dense enough to repel anyone without a law degree. Neither actually teaches the reasoning.
Decision
Layered explainers for each case — background, holding, reasoning, dissents, real-world impact — built on Claude AI and Cloudflare Workers, with "Educational only. Not legal advice." treated as a load-bearing constraint on the writing, not a disclaimer bolted on after.
Outcome
Constitutional law that reads like something you'd choose to finish, not homework you're assigned.
Java · Spring Boot · PostgreSQL

LEDGER

Money that never appears or disappears — proven with a database transaction, not just a promise.

Problem
Anyone can claim "I build financial backend systems." Almost nobody can show a ledger that stays correct under concurrent load — exactly where naive implementations quietly break.
Decision
Java and Spring Boot on PostgreSQL — the literal stack, not an approximation of it. A database-level UNIQUE constraint enforces idempotency by construction, not application code a future change could race. Balance reads are O(1) via a transactionally-maintained running-balance table, not summed over history on every request.
Outcome
A working API, not just a design doc: 20 threads racing the same account and 20 threads racing the same idempotency key, fired concurrently against a real PostgreSQL instance in CI — both invariants hold every run. Every ADR ties back to a specific claim, and now to a passing test that would fail if the claim were false.
LEDGER's transaction submission flow: idempotency check, entry insertion, locked balance update, commit POST /transactions idempotencyKey + entries idempotency_key UNIQUE duplicate → return original result Insert ledger_entries entries net to zero, or reject Lock account_balances SELECT ... FOR UPDATE — no lost updates Commit O(1) balance reads from here on
The full submission path — idempotency and consistency are enforced by the database, not application-level discipline.
Java · Spring Kafka · Redpanda

WIRE

LEDGER proves a transaction is correct once it arrives. WIRE proves it arrives at all — in order, exactly once, no matter what fails along the way.

Problem
A synchronous API call is only half of "real-time transaction ingestion." The other half is what happens when the broker redelivers a message, a downstream call times out, or one malformed event lands in a stream that has to keep moving — the exact conditions naive ingestion pipelines don't survive.
Decision
Redpanda — the same Kafka wire protocol, partition/consumer-group/offset semantics and all, chosen for CI weight rather than any change in what's being proven. Events are keyed by accountId for structural per-account ordering, and delivery is made effectively-once by pairing the broker's at-least-once guarantee with LEDGER's own idempotency key, rather than inventing a second correctness mechanism.
Outcome
A repo whose every ADR names the failure it exists to prevent — lost updates, duplicate posts, head-of-line blocking from a single poison message — before a line of consumer code is written. Docs-first, same as LEDGER; concurrency tests against a real broker are next.
WIRE's event flow: production keyed by account, ordered delivery, idempotent post to LEDGER, offset commit only on a terminal outcome Event produced accountId → partition key wire.transactions.raw ordered per account, at-least-once Validate → POST /transactions eventId becomes LEDGER's idempotencyKey LEDGER responds 2xx/dup → commit · 5xx → retry · 4xx → DLQ Commit offset only after a terminal outcome
At-least-once delivery from the broker, plus an idempotent receiver, equals effectively-once posting — no new correctness mechanism invented.

If any of this is worth a conversation, I'd like to have it.