Things I've built (and building)

Coaches spend hundreds of hours per season manually tagging film in Sportscode, labeling situations like set offense, transition, or 6v5. This pipeline automates that: drop in an .mp4, get back a Sportscode-compatible .xml with six codes tagged and ready to open.

The six codes: [Team] Offense, [Team] Transition O, and [Team] 6v5 for each side, matching the convention coaches already use in hand-tagged files.

Fine-tuned YOLOv8 detects player_dark, player_light, and goalkeeper per frame. A feature extractor computes cap counts, centroids, zoom level, and optical flow. An LSTM temporal classifier maps those signals to Offense / Transition O / 6v5 / neutral. Training on six labeled games with ground-truth Sportscode XMLs.

Python · YOLOv8 · PyTorch · LSTM · Sportscode XML

The broadcast camera zooms into the attacking end and teams switch sides at halftime, so pool geometry can't be used as an orientation signal. The classifier relies on cap count ratio, goalie position, optical flow, and zoom level - signals that stay meaningful regardless of which end is in frame.

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 worked to build a tool for the California DMV, translating technical capabilities into a concrete business case for a government customer.

Python · LLMs · Geospatial data · Web-hosted database

Delivered the full pipeline and web interface to the California DMV at the end of the course - built working closely with them throughout, shaping the tool around what they actually needed.

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.

The live product is hosted at via-visit.com ↗. Log in with email cj@via.ai and password tryvia2026. Navigate to the Dashboard tab to explore the interface.

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.