Projects
I build to learn. Each of these started as a real problem I wanted to solve — and became a lesson in making product decisions under constraint.
Spexel
AI · MedTechUpload an engineering drawing. Get a traceability matrix in seconds.
Try it at spexel.io →
Problem
Engineers in manufacturing and regulated industries spend hours manually reading engineering drawings to extract specifications into traceability matrices. It's tedious, error-prone, and a bottleneck on every product release cycle — especially when drawing packages span hundreds of pages across multiple revisions.
Key Decisions
The core product decision was accuracy over speed: a single-model approach was inconsistent on domain-specific notation like GD&T callouts and fit tolerances. I designed a two-stage pipeline — custom OCR for deterministic text extraction, followed by LLM validation that interprets specs in visual context. The tradeoff was latency; the gain was reliability. I also chose a privacy-first architecture with zero server-side storage, which became a key differentiator for regulated-industry customers.
What Shipped
A production web app at spexel.io — upload a drawing (PDF, PNG, JPEG), review AI-extracted specifications, customize the matrix, and export. Multi-page drawing support, per-page editing, and a clean review UI so engineers can catch and correct errors before export. GDPR-compliant with zero data retention by default.
What I Learned
Talking to engineers early would have saved several pivots. The most valuable feedback loop was watching someone use it on a real drawing for the first time — the gaps between what I built and what they needed were immediately obvious. Ship early, watch real usage, iterate.
UltimateMe
iOS · On-Device AIAn AI fitness coach that runs entirely on your phone — private by architecture, works offline.
Problem
Existing health apps surface data but don't do anything useful with it. Your watch knows you slept poorly and skipped the gym — but it never connects those dots or tells you what to do next. And the AI coaches that are appearing bolt a cloud chatbot onto the side and ask you to hand your most intimate health data to a black box. I wanted a coach that actually acts on your data without that data ever leaving your phone.
Key Decisions
The defining decision was to run the AI entirely on-device — a quantized Gemma model (~2B params) via Google's LiteRT-LM, executing on the phone's GPU. Cloud inference would have been far easier and the model far smarter, but on-device means health data never leaves the device, the coach works offline, and there's zero per-query cost. The hard tradeoff: a 2B model is much less reliable than a frontier model at structured output. So I designed the coach as a multi-agent system — one generalist chat "hub" plus background specialist "spokes" (a goal reviewer, a recovery reviewer) that share written state, never conversations. Narrower agents with smaller prompts are dramatically more reliable on a small model.
What Shipped
A native iOS app where the coach runs fully local: chat, on-device tool-calling (it logs food, builds multi-day workout programs, and updates goals — each behind explicit approval tiers), on-device vision for meal-photo logging, and a food database with verified-vs-estimated macro provenance. Background agents periodically review progress and recovery and feed the chat coach. HealthKit supplies sleep/recovery context; Supabase persists the user's logs. ~115 unit tests pin the deterministic layers.
What I Learned
On a 2B model that fits on a phone, prompt engineering only takes you so far — it will confidently produce malformed output no matter how good the prompt. The fix wasn't a bigger prompt, it was deterministic recovery layers: when the model narrates a workout plan instead of emitting structured data, app-side code detects the gap and re-prompts; when it fumbles a tool call, a parser repairs it; when it skips a UI action, a fallback fills in. I learned to treat the model as one unreliable component in a system I engineer around — not as the system itself.
Kitty Merge
iOS · Consumer GameA physics-based merge puzzle game — shipped solo to the App Store.
Problem
"Merge" puzzle games — the watermelon-game genre — are wonderfully satisfying, but most are buried under aggressive ads and pay-to-win mechanics. I wanted to ship a genuinely polished, gentle take on the format, and prove to myself I could take a consumer product the whole way from blank canvas to a live App Store listing, solo.
Key Decisions
The entire feel of the game lived in the physics tuning — restitution, friction, and merge timing. Early builds felt either dead or chaotic; I iterated on those values across many builds until a drop felt satisfying instead of floaty. I deliberately chose native SpriteKit over a cross-platform engine so the physics — the "juice" that makes this genre addictive — felt first-class on iOS.
What Shipped
Kitty Merge — drop cats, merge matching breeds, and chain your way up eleven breeds to the legendary Mega Cat. Built in Swift and SwiftUI on a SpriteKit physics engine, with Game Center leaderboards, a one-time StoreKit Remove-Ads purchase, AdMob banner / interstitial / rewarded ads, and Firebase analytics. Live on the App Store, with a dedicated landing page.
What I Learned
The last 10% is 50% of the work. The core loop came together fast; App Store review, privacy compliance, and monetization plumbing did not. Apple rejected my first submission over an App Tracking Transparency prompt that wasn't firing — a subtle race condition on cold launch. Tracing the lifecycle timing, fixing it, and getting approved on resubmission taught me that shipping a consumer app is as much about platform compliance and polish as it is about the idea.