Dossier
About
Senior-year psychology major, student-athlete, and self-taught full-stack developer. 23 applications currently in development — spanning intelligence, research, education, cybersecurity, lifestyle, civic tech, and developer tools — all built solo on a schedule that leaves zero room for wasted motion.
I wrestle competitively — six months a year, five days a week plus private training and weekend competition. I have a dog, a job, and a full course load. Every tool I build exists because I needed something that didn't exist yet.
Grew up in the era of dial-up handshakes and CRT glow. Learned to think in systems from video games that demanded you map entire digital worlds on graph paper. Carried that pattern recognition forward into building software that does more than function — it resonates. The psychology degree isn't separate from the code. It's the reason the code works the way it does.
Architecture philosophy: build systems that feel inevitable. Clean enough to be timeless, strange enough to be interesting. Every application is a different experiment in the same ongoing question — how do you make technology that actually understands what it's for?
Somewhere between the signal and the noise, there's a pattern worth building around.
Method
How I build 23 things at once
I'm not primarily a coder. My training is in the social and behavioral sciences (psychology major), and I work design-first — implementation is handled by AI agents I direct. My hand-written code is limited to HTML, CSS, and Verse. I'm actively teaching myself more of the stack and picking up cybersecurity alongside every product I build; the goal is to understand the layers under my work well enough to direct the agents better, not to become an engineer.
The job I actually do is design lead and behavioral-science-informed UX architect for a workforce of one — the agent. That framing sounds odd until you notice it's the same job a CTO does at a company where nobody else has shipped anything before: define the vision precisely enough that the team can execute, own the architecture so the pieces fit, and inspect the work often enough that quality drift gets caught before it becomes debt.
Every project starts with a design brief I write, not a spec the agent writes for me. The brief includes the behavioral hypothesis, the psychological texture I want the user to feel, and the specific criteria that separate “shipped” from “shippable.” Then implementation runs. I test, direct, and rewrite load-bearing pieces by hand when they matter.
There's a real failure mode I've learned to respect: I can generate code faster than I can meaningfully review it. By project fifteen, my personal review bandwidth is the ceiling, not the model's throughput. The discipline that matters isn't prompting — it's saying no to work I don't have attention to inspect.
Two things I do that most people don't. First: I write documentation for the agent, not for humans. CLAUDE.md files, architecture notes, decision logs — written so any agent can pick up any project cold and be useful in five minutes. Second: I apply move-fast-and-break-things specifically to UX shortcomings and to the psychology of the interaction itself. When someone tells me a thing isn't possible with current tech, my default is to make them prove it, and to try it anyway while they explain. Most of the useful surprises live between “conventionally possible” and “actually attempted.”