I build projects, I also study how they break.
Selected builds, notes, and AI security practice shaped by real product work.
I belive a lot of the useful work starts the same way: build something people actually want, then look harder at the system underneath it.
That pattern shows up in projects like Clicky Local and video analysis experiments, then shows up differently in my capstone threat model for an AI tutoring system, where I used real code access to test how policy, trust boundaries, and product choices can fail together.
AI tutor security case study
A public excerpt from a 99-page master's capstone using AskTA as a code-accessible case study for AI security, FERPA risk, and remediation planning.
Open to product-minded AI security conversations
Product, systems, and AI security is the lane where the work is most useful.
Clicky Local
A local discovery experiment focused on making neighborhood intent feel simple, useful, and alive.
Trust grows when the interface makes local context legible fast.
Video Analysis Experiments
Prototype systems exploring how vision and language models can summarize real-world activity without hiding uncertainty.
The real UX challenge is exposing confidence, not just shipping classification.
Startup Work
Cross-functional building across product, execution, and operations where the work had to survive contact with users.
Speed matters most when the team can still explain why it shipped.
K-12 AI rollouts fail at the boundary, not the demo
The flashy model behavior is rarely the real deployment problem. The real risk lives where student data, vendors, identity systems, and school operations touch.
Builder-first AI security work
Threat modeling and rollout review work that stays close to real product decisions.