How I work
product instinct + frontier tooling + team enablement
I come from product and design. Co-founded two companies, led product at a third, coached 100+ founders. That background forced me to get good at one thing: understanding the actual problem before building anything. Every system I ship starts there.
I was an early believer in AI as a working tool — I applied to Anthropic over three years ago, and I was building and shipping my own AI products in 2024 before "vibe coding" had a name. I build across whatever surface the problem demands: local Mac, Replit, Cursor, Claude Code, Flutter, Node, Python. I don't wait for permission to learn a new stack.
The thing I care most about is making teams dangerous with these tools -- not just adopting them myself. At MILLS I made AI non-optional, ran workshops to integrate Claude Cowork into daily workflows, pushed our developer to use AI in every task, and wired Cursor agents into Linear for autonomous PR generation. Enablement isn't a deck. It's sitting next to someone while they use the tool.
Years as a head of product, designer, and founder taught me one thing: if you don't deeply understand the user's problem, the solution doesn't matter. I bring that craft to every system I build — the first question is always what's broken in someone's workflow, not what tool to use.
I was vibe coding in 2024, building and shipping my own products before it had a name. I've built apps in Node, Python, and Flutter without formal training in any of them — locally on my Mac, across Replit, in Cursor, in Claude Code. Wherever the best tool lives, I go there. When a new capability drops, I'm building with it that week.
At MILLS I didn't just adopt AI — I made it mandatory. I ran workshops to get every team member into Claude Cowork daily. I pushed our developer to use AI in every workflow and integrated Cursor agents into Linear for autonomous PR generation. Adoption doesn't come from training decks. It comes from sitting next to people while they use the tools.
Every system I build includes its own documentation. AGENTS.md files, architecture diagrams, onboarding guides. If the next person can't pick it up without asking me, I haven't finished the work.
If a process depends on one person remembering to do something, it's not a process. I design workflows that run whether I'm there or not.
I've built systems that lasted and systems that didn't. The ones that didn't taught me more. Speed of iteration matters more than perfection of first draft.