Things I've built (and building)

VIA is an agentic pipeline that pulls in regulatory documents and geospatial data for a given region, then automatically generates AV safety scenarios and evaluation summaries, giving teams a structured way to assess readiness for new deployment environments.

Findings are surfaced through an interactive web-hosted database, allowing the California DMV to directly explore AI-generated insights without needing to run the pipeline themselves.

AI Engineer and Technical PM who owned the full product lifecycle from architecture through stakeholder-facing delivery. Bridged engineering and customer needs simultaneously, and pitched VIA as a subscription service to the California DMV, translating technical capabilities into a concrete business case for a government customer.

Python · LLMs · Geospatial data · Web-hosted database

Delivering the full pipeline and web interface to the California DMV at the end of the course. Pitched VIA as a subscription service - translating technical output into a concrete business case for a government buyer.

The core architectural question was how to structure the agentic pipeline - whether to use a single orchestrator passing context through sequentially, or break it into specialized agents for regulatory parsing, geospatial analysis, and scenario generation separately. We landed on a modular approach with distinct agents per data source and an orchestrator coordinating the outputs. This kept the pipeline debuggable and made it straightforward to swap in new data sources as scope evolved mid-project.

The product thinking evolved more than the code did. Our initial assumptions about what the DMV actually needed shifted significantly - which is why there are two decks. Learning to reorient around the real customer problem rather than the original spec was the most transferable skill I took from this project.

VIA went through a meaningful scope change mid-project as we sharpened what the DMV actually needed. Both decks are worth a look - the pivot shows how the product thinking evolved.

Coaches spend an enormous amount of time manually tagging film to label situations like Stanford offense, defense, 6v5, or counter attack. This pipeline automates that entirely - give it raw game footage, get structured tactical labels back.

Ground-truth labels are extracted automatically from Hudl Sportscode timelines, so no manual annotation is needed. The training data pipeline is complete; model training is underway.

YOLOv8 ↗ localizes players in each frame. DBSCAN ↗ clustering assigns cap colors to teams. Player coordinates are transformed into a top-down pool diagram, which a CNN classifier then uses to predict the tactical situation.

Python · YOLOv8 · DBSCAN · PyTorch · CNN

Using DBSCAN for cap color clustering rather than a fixed color classifier was a deliberate generalization choice. Water polo cap colors vary significantly across teams, tournaments, and lighting conditions - a hardcoded classifier would break on any new game. DBSCAN clusters pixel data without assuming a fixed number of groups or specific colors, so the pipeline works on footage it has never seen before without retraining.

4RGE connects aspiring athletes with professional trainers and coaches, giving users access to personalized 1:1 sessions with professional level coaches, usually unavailable to amateurs.

Mobile engineer on a 3-person team. Architected the full frontend and all backend API integrations from a Figma mockup to a live App Store product. Zero critical post-launch defects, zero missed milestones on a professional-athlete timeline.

React Native · Node.js · Firebase · Stripe

Shipped to the App Store in under 6 months on a professional-athlete timeline. Zero critical post-launch defects, zero missed milestones across the full build cycle.

The hardest piece was building a calendar-style session view that worked correctly for both coaches and athletes simultaneously. A booked session had to appear - and stay in sync - across both user types in real time. I modeled sessions as shared Firebase documents with listeners on both sides, so cancellations and reschedules propagated instantly without a refresh. Getting the data model right so the same document served two completely different UI views was the core engineering challenge.

Building for two user types at once doubles the edge case surface area. A feature that looks simple from the athlete side - book a session - has real backend complexity when the coach's calendar, availability, and notification state all have to stay consistent. I learned to design data models for both consumers before writing a line of code.

The Market is a peer-to-peer marketplace built for the Stanford student community. Co-founded the company with the goal of making it easier for students to buy, sell, and trade within a trusted network. Built entirely from scratch while carrying a full athletic and academic load.

Co-founder and technical lead. Made every decision: stack selection, UI/UX system, data model, and third-party integrations. Pitched and iterated directly with industry advisors to sharpen product-market fit. Went from Figma designs to a working production prototype in one adacemic quarter.

Flutter · Python · Firebase

Shipped a working production prototype - listings, search, user profiles, and in-app chat - in a single academic quarter while carrying a full course load and D1 athletic schedule. Pitched to industry advisors and iterated on product-market fit throughout.

Building in-app chat on Firebase required a unique, stable conversation ID for every pair of users - without a backend to generate one. The solution: combine both user IDs into a canonical string by always sorting them alphabetically, so user_A_user_B is the same path regardless of who initiates. Both users listen to the same Firestore document, keeping the chat consistent with no duplicate threads and no server round-trip to create a conversation.

Scope creep is the real enemy of a technical team. Chat, listings, profiles, search - each felt small in isolation. Shipping in one quarter meant making hard calls about what to cut and learning to treat "good enough to prove the concept" as a legitimate engineering bar.