Mastermind · March 9, 2026
Why I stopped building an outreach tool
The moment on the call that settled it was Chinat asking: what can Pulse do that Claude Code can't? I didn't have a clean answer. That was the answer.
I walked him through where I was heading. Founders need promotion, I said, and automated outreach is a real need, but I'm probably not the best person to build it, and more importantly I don't think it's the most interesting problem I can work on. The technical thread I want to pull is agent-to-agent communication, specifically the intersection of access management and performance. How do agents remember, how do they share context, how do they gate information across users without leaking, and how do they do all of this at reasonable latency.
He pushed on the version of the question every technical founder should have to answer. What is the specific core problem you are solving, and can you articulate it in a way that a user could evaluate? He'd been through the same exercise with a previous project where the core problem was context, and he said what he'd learned there was that context is too vague a claim to pitch. If you can't name the specific capability that goes from impossible to trivial when you ship, you don't have a product yet.
Then he ran the actual test on me. Suppose you want to schedule a meeting with me. You can already ask Claude Code to do it. So what does Pulse add?
The honest answer is that Claude Code can execute if it knows my context. It doesn't know your calendar availability. It doesn't know your ongoing commitments. It doesn't have the agent-to-agent layer that would let my hosted instance ask your hosted instance a question and have the answer come back without either of us writing an email. That agent-to-agent layer is the specific thing that doesn't exist yet. It's the gap that every shipped product in this space hand-waves at.
So the research-side and product-side questions are the same question. How do agents acting on behalf of different users exchange information safely and reliably. That's a real technical problem with a falsifiable answer, not a framework paper. Access management says which information is allowed to flow. Memory says what each agent has access to in the first place. Performance says whether the system is fast enough to be worth using. If Pulse solves that, it isn't a wrapper, it's infrastructure. If Pulse doesn't solve that, it's a prettier Claude Code.
The outreach direction I'd been working on is a wrapper. That's the real thing I'm admitting this week. It's a wrapper on top of a capability that exists, and the moat is UI polish and maybe prompt engineering, which is a bad moat to bet a year on. Walking away from it costs me the near-term revenue and the simplest demo. Walking toward the access-management problem costs me the next several months of harder technical work with no obvious demo moment.
Chinat's frame on it, which I agreed with even though it added to the scope, is that a technical problem of this shape needs a benchmark. You can't pitch the solution, you pitch the benchmark. If we can build a realistic benchmark, ten thousand question-answer pairs across fifty simulated users, that tests whether Pulse refuses the right requests and routes the right ones, we have a defensible technical story instead of a marketing one. Benchmarks are how you move from hand-waving to a falsifiable claim. They're also a lot of work.
The pitch deck work changed shape as a result. I'd been structuring the deck around product features. The deck needs to lead with the technical problem, pose the access-management question, and then show the specific architecture and benchmark that answer it. The deck becomes a technical brief with a product implication, not a product brief with a technical appendix. Same content in different order, and the effect is different.
The thing I've been procrastinating on, and I said it out loud on the call, is accelerator applications. A few of them are due. I've been dragging my feet because the pitch wasn't sharp enough to withstand a hard question. Once the pitch is narrower, the applications get easier to write, because I'm not trying to hedge across five possible futures. One thesis, one problem, one benchmark, one demo.
Chinat's side of the call is moving in a parallel direction. He's dropped the idea of a product launch moment and is treating the Hong Kong flagship event in July as the launch itself. Same discipline: commit to one specific moment that forces everything else to cohere. For him the moment is a thousand-participant event. For me the moment is the benchmark and the architecture it runs against.
The check I'm making on myself: this week, the outreach framing gets formally removed from the deck, the benchmark plan gets written down with real numbers, and the applications go out with the honest narrower pitch. If I'm still pitching outreach by the next mastermind, I've backslid.