I build AI products 0-to-1 and scale them. It's the work I enjoy the most.
For two decades I've turned emerging technology into products people use every day, in both consumer and enterprise. I've led teams, and I still build by hand. I make powerful tools simple, trustworthy, and approachable for everyone. The dozen-plus tools and agents below are a snapshot of what I built to learn, mostly for myself, over the last five months at South Park Commons. It's changed how I work, and shaped what I want to build next.
17 years at Google repeatedly building 0-to-1 AI and productivity products, including Inbox by Gmail, Gemini for Workspace, and a conversational-AI product at Area 120 that Google Cloud acquired. Then VP of Product for AI and Search at Slack. Now Founder in Residence at South Park Commons. MIT EECS.
How I (now) work
Some of how I build is the same as it's always been; some is completely different. I've always run experiments and kept some and killed others. Now that I can prototype an idea in an afternoon, I try far more things and drop them freely when they aren't working; the cost is low enough that that's fine. The skill that matters is taste: knowing when to keep pushing on something versus stop and take it as a lesson. Talking to the people who'd use a thing matters more than ever; it's how I stay on the right problem and the real pain. And sharpening my own workflow matters more too, because the tools give so much leverage.
Three things stay fixed underneath: power, simplicity, and safety, held together rather than traded against each other. Access stays scoped to just what's needed, and nothing merges without a security and architecture pass.
Daily drivers what I use every day, built for myself first
A chief of staff that lives in Slack
Mara is a Slack agent I built for myself and use daily. I started with the obvious features: a morning digest, drafting in my voice, tracking, search. They worked. The one I keep reaching for is the plainest: it answers real questions the way someone who truly knows me would, because it's grounded in my data and tuned to how I think. I run four assistants in Slack. Mara is the one I use, because it knows me.
What I took away: personalization is the unlock: grounded in your data and tuned to how you think, an assistant stops being generic and starts being yours. Where it lives drives whether it gets used, and proactive features earn their place only when they're right almost every time. When they're not, they should stay quiet.
Scoped access to my Drive, for any agent
My Drive is my source of truth, but an agent I point at it shouldn't see everything in it. Clio is an MCP server that gives a given agent only the folders and files it should touch. I turned it into a system: one skill keeps my Product Ideas doc current, another writes and updates my Product Briefs as they evolve, so the source of truth maintains itself. My Hermes agent is next, on the same tight leash.
What I took away: we're each about to run many agents, and access can't stay all-or-nothing. Today's OAuth wasn't built for this. The platforms will likely fix it at the source; until they do, the hard part is safety: giving each agent real power over your data without handing it the keys to everything. Good UX is part of that, but safety is the point.
The right brief, at the right time and place
I take a lot of meetings with people I haven't met. The old prep was manual: remember to ask Gemini Deep Research hours ahead, write a long prompt, then dig the result back out of my chat history. Now a scheduled task does it. For each meeting worth prepping, it drops a shadow event on my calendar: a short summary in the event, a link to a full Notion brief, grounded in my email, calendar, Slack, notes, the web, and refreshed with anything recent. It's waiting on my phone, where I'd look anyway.
What I took away: the value is the closed loop: I don't ask, wait, or go hunting. It's a system, not a tool. That distinction is one I keep coming back to, and where I think productivity goes next. And you don't always need to build new UI: often the bigger win is a system that brings value into the tools people already use.
Where humans and agents plan together
Agents write long plans for us to review, but today you hand the feedback back by dumping it into one chat box. Reviewing a document by commenting on its sections is older and better; it's why doc comments exist. So I built a skill that has Claude Code draft a plan as a Notion doc, then iterate with me through comments until it's final and becomes the spec it builds from. It worked well enough that I extended it to web-based AI too. This very page came together the same way, through comments left straight on the live Vercel preview.
What I took away: review belongs in a tool built for review, not a terminal. People and agents will keep working on the same documents, and that needs the right interfaces and account identities to be both safe and effective.
Things I launched
Easy scheduling, and a lesson in launching
I schedule a lot of meetings. I like to customize my availability, which means flipping between calendar and email. Markfree is a Chrome extension that makes it one step: click your free slots on Google Calendar, copy, paste. Simple and free, which made it a good thing to practice launching on. The last mile was the lesson: store approval, a business address and phone that weren't my own, a demo video. I stopped short of full go-to-market.
What I took away: the final mile took several times longer than the build, for something this simple. Now I know what "shipped" costs, and that decides what I take all the way versus keep for myself.
Keeping an agent's design consistent
I kept hitting the same wall: coding agents are weak at design, and they redo it every pass instead of holding it as a system. I first tried a full design companion (a Lovable-style UI wired into Claude Code), but matching that quality needed training data I didn't have. So I narrowed it to a Claude Code skill that sets a design system up front, holds the app to it, and grows the system as the app needs new pieces, the way a designer would. It worked well enough that I open-sourced it, free for anyone to use. (Built Feb '26. Then the Claude Design skill and app happened 🙂)
What I took away: design is its own language, and it isn't native to how agents build; you have to set it as a guardrail. A newer worry: as skills multiply and the tools change weekly, overlapping ones will cause failures that are hard to trace.
Things I abandoned the ones I stopped on purpose
A self-healing to-do list
The blocker to getting value from AI is often just remembering to ask. So: what if an agent lived inside your to-do list and helped things get done, no prompting required? I built it, extended it into meeting prep and email triage, then shelved it. The real power needed write access, not just read, and today's OAuth is all-or-nothing. As my first solo build, I wasn't ready to be the steward of that much critical user data at that scope. But the meeting-prep piece was good enough that it became the system I use now.
What I took away: a lot of it was UX I hadn't nailed (session-based versus chat, and meeting people where they already are), and safety and cost were real constraints, not afterthoughts. I'll bring pieces of it back.
And a long tail of other experiments. A sampling:
What I've learned
Getting an agent to do something is the easy part. The hard part is everything around it: trusting it with your data, making it good enough at real work that you'd hand it real work, meeting people where they already are, and building for the people using it and the agents acting for them at the same time.
The upside of getting this right, powerful software in the hands of every person and business, is enormous, and so is the cost of getting it wrong. I'm an optimist, driven by building high-utility products people love. But in this new era, doing it safely has never been more important. I build everything with that in mind. Now I want to apply what I learned to a product I can scale to millions.