The Startup Moat Moved: What Every AI-Native Founder Has to Unlearn
Three months as an EIR at Andrew Ng's AI Fund — on finding the pain, the moats that are left, and how you actually build now.
I wrapped my EIR at AI Fund on July 31.
AI Fund is Andrew Ng’s venture studio. Ng founded Google Brain, was Chief Scientist at Baidu, teaches at Stanford, and was named to the TIME100 AI list in 2023. Getting into the program was a 48-hour build challenge, then interviews with the CPO, the CTO, and Ng himself.
Here’s the part that still gets me. I applied for this through LinkedIn like everyone else — the posting had roughly two thousand applicants at the time — with a referral from Fahad Aziz, a founder I know well. I heard nothing for two months.
Then Mike Rubino, who runs talent at AI Fund, emailed me out of the blue. Subject line: this is not spam — builder dinner with Andrew Ng. It arrived at 3:52 in the morning and invited me to a dinner that same evening: about fifteen builders, ninety minutes, Mountain View, in person with Andrew. Everything about it looked like something you would delete.
I nearly did. Don’t. If an email like that ever lands in your inbox, read it twice.
I didn’t get in through the front door. The front door doesn’t scale — two thousand applications is a volume problem, not a verdict on any of them. Mike had just started at AI Fund and had rebuilt how they sourced, using AI to go and find the people the pipeline was never going to surface. So I didn’t get in because someone got lucky with my resume. I got in because someone built a better way to look. He isn’t doing that alone: Dylan Love — a recruiter who went and got a CS masters to become a data scientist, and now a GM at DeepLearning.AI — is building AI for talent with Andrew. Between them, the machinery that finds people is being rewritten. Which is the argument of this whole piece, arriving two months before I understood it as a product lesson: when the cost of doing something collapses, doing it stops being a differentiator, and the moat moves to being found.
I’d spent the previous six weeks rebuilding how I showed up publicly. In the 45 days to April 28: 27,942 impressions and 10,620 people reached — up 510% and 622% over the prior 45 days. Mike’s email landed on day twenty-six of that window, while the curve was already climbing. I don’t think those two facts are unrelated.
Which is the point. The growth wasn’t the result of being found. It was the cause of it.
I’ve since wondered whether that’s part of why the conversation went anywhere at all. A studio whose entire operating model is hypothesis, test, evidence is not going to be moved by someone describing their potential. It’s going to be moved by a chart.
I went.
One more person belongs in this part. After the dinner came a 48-hour build challenge, and after I submitted it I did the thing everyone does: I waited. Rob Ross, a founder I’d met days earlier, told me what I couldn’t see — that there were other people working on the same challenge, that they were being weighed against each other, and that every one of them was still moving while I sat on a submitted file. Build something tonight, he said. Ship it in the morning.
He called at eight the next morning to ask whether I actually had. I said I was sort of working on it. He made me prioritize. At nine I committed: by eleven I’d send him the exact email I intended to send AI Fund at five that afternoon, describing what I’d built and shipped. If I missed either mark I’d take him to the Ritz-Carlton. He turned that down — I don’t care about the Ritz-Carlton, it has no value. You charge $500 an hour. Give me eight hours of consulting for my startup. He refused a meaningless stake and repriced the bet in the only currency that mattered.
I hit both deadlines. Mike replied within hours and set up the onsite.
In a competitive process, waiting is the losing move. What you submitted is the opening, not the last word.
Much later — week nine of the EIR — that relationship turned into a different kind of conversation. The kind where you give someone honest feedback and risk the relationship a little, because you think they can use it. Seven specific things, candidly delivered. He took it exactly as intended, and later gave me a signed copy of Andrew’s book. Which is the other half of how this works: being found is the opening, not the outcome. What you do with the relationship afterwards is the part you actually control.
Mike deserves more than a mention. When the whole thing nearly came apart at the last minute, he did the rarest thing a person on the other side of a negotiation can do — he told me it was completely fine to walk away, and explained his reasoning instead of pressing. That’s why I said yes. You learn a lot about an organization from how it behaves when you might leave.
I’d made a version of this bet once before, with my own life. Eight years ago I moved from Texas to the Bay Area at a point when roughly eight people were leaving California for Texas for every one going the other way. I went the wrong way down that highway on purpose, for exactly this reason — proximity to where things get known first. The reaction stuck with me. Someone told me there’s no middle ground with you: you’re either too dumb, or you’re too smart and you know something we don’t. I said thank you for the compliment, and that time would tell. Eight years on I’m still not certain which one I am — but I’d make the same move again tomorrow.
And none of what followed was a separate decision. Working with the best minds I can get near, staying close to research, and getting to teach — that’s one strategy, and I set it in motion eight years ago when I pointed the car west. Joining AI Fund wasn’t a new plan. It was the same plan, one layer up.
I almost didn’t take it. Navya Chitimireddy, a VC at Abyro Capital, cut through weeks of my deliberating with a single question: would you regret it if you didn’t? That’s Bezos’s regret-minimization framework, and it ended the debate in about four seconds. She was also the first person to tell me plainly that distribution is the moat and that the answer is company workflows — which turns out to be most of what this piece is about.
The answer, once she made me say it out loud, wasn’t about the credential. It was proximity. I’d regret not getting to watch one of the sharpest thinkers in applied AI reason in real time — what he considers worth researching, how he thinks about distribution, what he kills and how quickly. And not only him: a bench of operators who had already done the thing I was trying to do. You can read all of that. Sitting next to it is a different kind of learning.
Rakesh Utekar and Ashwyn Sharma pushed me the same way from different angles. Rakesh is the kind of builder who makes you recalibrate what one person can ship in a week — I’m only half joking when I call him the Terminator. Ashwyn had seen the place from the inside and couldn’t name a single negative: his read was that AI Fund is built for serious founders, the ones who don’t chase shiny objects.
There was one more thing, and it’s what stopped the decision feeling like a career calculation. Most studios and accelerators fund what the market has already validated — the shiny category, the adoption curve that’s already bending. What I saw here was a different starting question: does this problem have to be solved, for people’s sake? Back it because society needs it, not because the signal has already arrived. I care more about problems at that scale than about being famous or getting rich. It felt like a perfect match.
Three months is short enough that everything you learned is still vivid, and long enough that some of it is real. I wanted to write these down before the vividness fades into general wisdom, because the specifics are what make them useful.
Three parts: finding the pain, the moats that are left, and how you actually build now. Some of it I heard from mentors and internalized. Some I watched teams get right or badly wrong.
None of this is beginner material. If anything, the founders who need it most are the ones with the most scar tissue — because the playbook that worked before AI is now the thing most likely to mislead you. AI collapsed the cost of building. Table-stakes engineering stopped being a differentiator the moment it stopped being scarce. That single change moves where the moat lives, and everything below follows from it.
Part 1 — On finding the right pain
1. Go after the biggest pain — that’s where engagement and willingness to pay live.
Every product solves SOME kind of pain. That’s not the bar.
The bar is: is this the biggest pain? Because that’s the only place where users actually engage with the product and are willing to pay for it.
Solve a mild pain and you get polite nods. Users try it once, don’t come back, and never open their wallet. They’d already adapted to that pain and built a workaround. You’re not selling a solution — you’re competing with inertia.
Inertia wins.
Andy Ku, AI Fund Partner for Product Build, kept pulling me back to that one word — biggest. Not a pain. The biggest one.
The biggest pains are the ones users mention unprompted, the ones with an ugly workaround already bolted on, the ones that make them curse at their screen. Those are pre-qualified. The user already believes the pain shouldn’t exist. Your product just has to make it go away — and they’ll pay for that.
2. Find multiple users with the same pain before you build.
There’s nothing magic about a specific number. What matters is more than one. That bar came from Andy Ku, and it held every time I tested it.
When several users independently describe the same pain in similar words, that’s your evidence the pain is real and worth solving. One user is an anecdote. A handful pointing at the same thing is signal — and it directly validates lesson one, because a pain multiple people carry is far more likely to be a big one.
Skill lies in finding the ICP. Not defining it — finding it, in the wild. Once you’ve found a few who share the pain, build for them specifically, not for the abstract “market.” “Market” is a shape you infer later.
3. Ask facts, not wants — then observe.
Andy and Jill Shih, a product and UX leader with 25 years in the discipline who now runs AI Fund in Taiwan, both drilled this into me — the Mom Test and contextual inquiry, applied together.
The Mom Test came to me from Vaibhav Mathur, a physicist turned builder in the same cohort, who put the book in my hands and kept pointing me at the sources actually worth following. He has a nose for who to listen to.
First: never ask “would you buy this?” — the answer is always kind. Ask facts about the past. How long did that task take last time? What did it cost you? Who else was involved? What did you try before?
Second: watch someone actually work through their real task. You’ll see the pain they’ve stopped mentioning because they’ve stopped noticing it. Survey data doesn’t touch this layer.
Three killer questions that quantify the pain:
How long does the task take?
How much does it cost?
What happens if it doesn’t get solved?
The third one does double duty. It surfaces the cost of inaction — which is where willingness to pay actually lives, because a budget line exists to avoid a consequence, not to buy a feature. And it makes the user say the pain out loud, which often raises their own estimate of what solving it is worth. It was the most useful question I asked.
And when you’ve built something, don’t ask them if they’d use your product. Watch whether they do. Behavior is the only signal that doesn’t lie.
Part 2 — The moats that are left
4. Data is a moat you can design for.
Any new AI system has three paths to defensibility:
Own the data — proprietary corpus, exclusive access, historical archive nobody else has.
Buy access no one else can — exclusive partnerships, licensed streams, geographic or regulatory access. Sandeep Gupta sharpened this one for me — the acquisition angle most founders skip past.
Design the product so it generates new data every time it’s used. This is where I landed: every user interaction should make the system more intelligent for the next user using it. That’s a compounding flywheel with no ceiling — not a static advantage.
Feature parity is six weeks away. Data compounds.
Own a vertical.
It’s worth being blunt about why this matters more than it used to. Anyone can ship the feature now, and foundation-model companies are absorbing whole verticals as fast as they appear. So the moat moved. What’s left is the hard engineering — eval, reliability, eliminating AI slop. The data. The distribution. Finding the ICP before anyone else does. And, least obviously, still being there after the fifth pivot while thousands of people build the same thing the same week.
That last one sounds soft. It isn’t. When building is free, persistence is scarce.
5. The hardest engineering problem is the moat — and proximity to research is how you hold it.
This one is Andrew Ng’s, directly.
Don’t compete on features. Don’t compete on being first to market. Invest in the technology and solve the problem others have tried — and failed — to solve.
Every space has competitors. Users not choosing them yet usually means one of two things: the competitors don’t solve the real problem, or nobody’s heard of them. Sometimes both.
There’s a third reason, and it’s the one AI keeps manufacturing: the capability to solve it only just arrived. A model ships, a research result lands, and a problem that was genuinely intractable last year becomes tractable this quarter. That isn’t a market rejecting a solution — it’s a market that never had one. Being in the Bay Area is an unfair advantage here, not because of the money but because you hear about the capability months before it’s obvious, and the window between possible and crowded is where the whole game is played. Hear it early, build fast, get there first.
That is the bet I described at the top — made once with a moving truck, and again with a career.
The hardest problems are the moat that’s left.
Eliminating AI slop — low-quality, hallucination-heavy generative output — is a category-defining engineering problem. Many teams have tried. Most have failed. That’s exactly why it’s the moat. Cross-family judgment, structured refusal, guardrail-as-architecture, eval-gated deployment — the whole discipline of making probabilistic systems trustworthy in production. Solve one of those and the ICP finds you. You never had to compete on features.
But there’s a second half to this that took me three months to see clearly. If the hardest problem is the moat, then staying close to research is how you keep it — because the hard problem moves. The thing that was unsolvable last quarter has a paper about it this quarter, and the team that read it first gets there first. A moat built on solving one hard problem is a moat with an expiry date. A moat built on being continuously close to where the hard problems are being solved doesn’t have one.
I stay close to research two ways. Teaching is the first — four and a half years of it at UC Berkeley Executive Education, taking AI strategy and responsible deployment to more than fifteen hundred Fortune 500 executives, and I’m going back to it. Nothing exposes a shallow understanding faster than a room of executives asking why. And I work with people who carry the field in their head. Andrew is a research encyclopedia; ask him about a problem and you get the shape of the literature back, not an opinion.
That was, honestly, part of the decision. When I said yes, I told myself: I don’t have to worry about the technical challenge at all — Andrew will be there to unblock that. It sounded a little like wishful thinking. It wasn’t — but it also didn’t mean what I assumed it meant.
He never handed me a solution. The slop work was mine: I built the evals, largely out of his own course, and got a 60–80% reduction. What he unblocked was the layer above the solution. Am I even working on the right engineering problem? And who has already solved this, or is solving it right now — which researchers, which teams, which papers. A ten-minute answer to that saves a month, because the expensive mistake is never a bad implementation. It’s an excellent implementation of the wrong problem.
Eli did the same thing from a different angle: a steady stream of technical resources and trends on the slop problem, and one instruction that stuck — build a taste for it. Then he pushed further. Don’t lean on the models alone. Don’t become an AI zombie.
That one landed hard, because I’d written the same warning about myself years earlier, before business school: as a (just) technologist, when all you have is a hammer, everything looks like a nail. AI is the largest hammer any of us has ever been handed. The correction isn’t to use it less — it’s to keep the judgment that decides where to swing.
And the way you keep that judgment isn’t restraint. It’s architecture. The reason I build gates — evals, cross-family review where no model family grades its own work, checks that fire whether or not I remember to run them — is so the judgment survives the speed. An AI zombie lets the model make the call. A framework forces the call to be made, by a human, and recorded. Same tools, opposite posture. Most of what looks like heavy AI use in how I work is actually the scaffolding built to stop exactly that failure.
6. A real buyer is a moat. User delight isn’t.
Delighted early users are necessary, not sufficient.
The wedge that becomes a company needs an economic engine — buyers whose budget already exists, whose pain is board-level, whose measurable outcome is unambiguous.
Users loving something is a starting condition. Not proof of a company.
The clearest way to check: can you name the specific budget line item that already exists in the buyer’s org, and the specific measurable outcome your product will improve, and the specific title of the person who owns that budget? If you can’t name all three, you don’t yet have a commercial signal. You have user delight and a hypothesis.
Part 3 — How you actually build now
7. Eval is the product.
This one is Andrew Ng’s again — I first heard it in his DeepLearning.AI course on Agentic AI, which is also where the autonomy-level framing and the case for evals clicked for me, and it kept landing harder every time I saw it play out inside the studio. His way of putting it: the thing that separates a good team from a great team is how they run their evals.
Every AI system I saw succeed had eval infrastructure baked in from day one. Every stall traced back to teams shipping the model output first and adding evaluation later. Later never comes; the deploy calendar hardens around the shipped shape.
When the model changes underneath you weekly — new snapshot, new alignment update, new subtle regression — evaluation is what makes the system real. Not the demo. Not the pitch. The eval harness is the thing that keeps you shipping when the ground moves.
8. Build frameworks and AI-native agentic workflows, not just products.
The strongest teams I saw weren’t shipping products faster. They were shipping the framework that shipped the products.
Your own dev workflow. Your eval harness. Your security gates. Your architecture-alignment checks. Sonar. Cross-family judgment. Guardrail-as-architecture. Each of these is a small compounding investment that turns every product you ship next into a faster and safer ship than the one before.
The framework compounds. The product depreciates. If you’re only building products, you’re re-buying the same tooling forever.
That’s the inward half. The outward half matters more.
Ship the agentic workflow, not just the feature. A feature gets evaluated, compared, and swapped. A workflow gets adopted — it becomes how the work actually gets done, and then it becomes the thing nobody wants to unpick on a Tuesday. Embed yourself in how the user operates and you stop being a tool they chose; you become the backbone they’d have to rebuild around to leave.
That is switching cost you earned rather than trapped someone into. And in a market where the feature you shipped can be cloned in six weeks, it may be the most durable moat on this list.
I didn’t arrive at this on my own. Dylan and Gaurav Surtani are the two who made it concrete for me. Gaurav is a one-person AI engineering team at DeepLearning.AI, and watching how he works is the argument: he isn’t hand-writing more code than everyone else, he’s built the workflow that writes it — agents, MCP servers, skills, cost-aware model routing — and then he open-sources the pieces. In the developer arena the differentiator stopped being how fast you type. It’s the workflow you built to do the typing.
9. The clock on consumer AI wedges is compressing.
Categories I saw close in weeks that would have taken quarters two years ago.
Speed of learning matters more than speed of building. A studio like AI Fund is one of the few environments engineered specifically for that compression — the entire operating model is “run more hypothesis-test loops per week than you could run alone.”
Persistence is the moat nobody lists.
I watched what that looks like up close. Jayanth (Jay) Madduru, a Founder in Residence at the studio, ran the loop harder than anyone I’ve met — thesis, test, feedback from the studio, then straight into the dark to learn something new about the user or a new way to build. One weekend he shipped 150 pull requests. Then Monday he’d be back with a sharper thesis and more energy than he left with, like a spring that won’t stay compressed.
He credits me for some of what he learned about building. He has no idea he handed me more back than that.
Most of those loops fail. That is the job, not a detour from it. When building is free and thousands of people are shipping the same week you are, the differentiator stops being the code and becomes who is still running the loop after the fifth one breaks. Almost nobody is. You only fail when you stop trying.
The meta-thesis — why any of it worked
Eli Chen insisted on this one — he’s a Technology Partner at AI Fund and previously co-founded and was CTO of Credo AI: you can’t just reason your way to the destination.
You start with a hypothesis. You test it with real users. You pivot on what you learn. You start over with a sharper hypothesis. That’s the loop. There is no other loop.
Every one of these only became real to me because I got to run that loop compressed. Any of them read as generic advice on their own — “own the data,” “eval is the product.” They only become your advice when you’ve held them against your own hypothesis and seen how they change what you’d do next.
That’s what a studio buys you: not the destination, but the loop.
If you want to be found, show receipts
The piece argues the moat moved to being found. Here’s the practical version, and it’s the advice I’d give anyone in the market right now.
Claims don’t travel. Receipts do. Your resume says you know a technology. So does everyone else’s. The résumé is a claim; nobody can verify it in the eight seconds it gets. What survives that eight seconds is proof someone can click.
Three tiers, in increasing order of how much they’re worth:
Public contributions. A GitHub profile with real commits beats a bullet point that says the same thing. It’s the cheapest receipt available and most people still don’t have one.
Open source. Strictly harder, and worth more precisely because it’s harder — you’re inviting strangers to read your actual code and judge it. That takes guts, and everyone reading it knows that.
A working thing they can use. The strongest form. Don’t tell someone you understand AI systems — put an agent on your site and let them talk to it. I did exactly that on my own site rather than adding another line claiming technical depth. One interaction settles a question a paragraph can’t.
The pattern underneath all three: stop describing your capability and start exposing it. Descriptions are indistinguishable at scale — that’s exactly the collapse this whole piece is about. A thing that works is not.
The reframe — worth solving vs. vitamin water
Every founder starts with hope that this experiment will be the one. When the wrap comes, it stings.
Andy, Eli, and a friend from my poker circles — Anurag Jain, a multi-time founder now building in stealth — kept saying the same thing in different words: an experiment that doesn’t lead to commercial success is the experiment doing its job. Failed hypothesis is data, not verdict.
Anurag put it more sharply: “Solving the right pain is important. Raising money for something that isn’t even a big pain worth solving is much worse.”
Wrapping cleanly on something that turned out to be vitamin water — not a painkiller — saved me the next seven years trying to force market-fit onto a hypothesis the market wasn’t asking for.
There’s a symmetry here I only noticed while writing this. Both explorations I ran during the EIR were bets on the same thing this piece argues. One was an AI-powered platform for adapting content across channels; the second came after it. Strip the surface off either and they were about the same problem: being found. I was building the answer to the exact thing that got me the job — I just hadn’t connected the two yet.
What we learned was that the market wasn’t ready to pay for it on the timeline a studio needs. That’s a finding about commercial urgency, not about the thesis. I still think the thesis is right. I think it gets more right every month building gets cheaper.
Solve the right pain. The wrong one drains you.
What I’m carrying forward
On finding the pain
The Mom Test on every conversation with a potential user — ask facts, not wants, then watch them work. And never on the strength of one user; one is an anecdote, several with the same pain is a market.
The hypothesis → test → pivot → sharper-hypothesis loop as the only real product-development method.
On the moats that are left
Design the data loop from day one. The data you accumulate by operating is the one moat a competitor can’t clone by shipping the same feature.
Take the hardest engineering problem on purpose. Once building is cheap, the problem others tried and failed to solve is the moat that’s left.
Choose the room, not just the project. Proximity to research is how you keep that moat, because the hard problem moves — what was unsolvable last quarter has a paper about it this quarter. Ten minutes with someone who has already crossed it beats a week of solo effort.
A real buyer beats a delighted user. Willingness to pay is the only validation that survives contact with a budget.
On how you build
Encode the standard as a gate, not a habit. Evaluation-as-infrastructure and cross-family review — never letting one model family grade its own work — survive a deadline only when they’re gates in the system rather than intentions in my head. That is most of why I build an agentic operating system instead of a checklist.
Ship the agentic workflow, not just the feature. A feature gets compared and swapped; a workflow gets adopted and becomes the backbone.
Optimize for learning rate, not output. The variable that compounds isn’t hours worked, it’s how fast one loop closes — idea to shipped to measured to sharper idea. Shortening that cycle is the only advantage that keeps paying after the market moves.
The founder cadence of shipping a real thing every 2–3 weeks even when the market takes longer to answer.
One more, less tactical
Every founder goes through lows. The hypothesis breaks. The pivot isn’t obvious yet. The loop feels like it’s grinding on you instead of forward. What separates founders who keep building isn’t grit — it’s having someone in the room who asks the right questions in those moments.
Eli did that for me more than once. He also believed the slop problem was worth solving and made that clear when it counted — and he’d be the first to tell me when I was drifting off it.
Cheerleaders are easy to find. So are critics. One person who is both — who backs you when you need backing, and says the hard thing when you’re off track — is rare, and worth more than most advice. You don’t get to appoint that person. You can only be the kind of person they’d bother doing it for.
The silver lining is always there. You often can’t see it alone.
Two courses worth your time
If you take one thing from this piece and act on it, make it these.
Agentic AI — the one I’d hand any engineer or founder building with agents. Evals, agentic workflows, and the autonomy-level framing that stops you from over- or under-trusting a system. Most of Part 3 above is this course meeting real deadlines.
AI for Everyone — not technical, and that’s the point. I recommend it to literally everyone: the PM, the designer, the ops lead, my own family. It’s the fastest way to give someone accurate intuitions instead of headlines.
What’s next
Two tracks, running in parallel.
The right build. I’m back in the market — applied AI leadership, agentic systems and AI-native engineering, or the right early-team seat as an IC architect.
What I care about is the layer underneath the product: how agents plan, execute, validate and evaluate; how you route models so cost scales with judgment rather than volume; how context survives a session boundary; and how evaluation gets treated as architecture rather than a phase that arrives after the build.
A side project, deliberately. Exponential OS started in February as a plugin I wrote to get my own resume out the door, and turned into an agentic operating system I use every day — alongside Co-Dialectic, the open-source prompt and context optimizer I maintain. Engineers started asking to buy it, which is the only reason I think of it as more than tooling.
I’m calling it a side project on purpose. I haven’t found a scalable problem yet. And the foundation is evolutionary enough that there’s no precedent to validate it against — which makes it genuinely interesting to build and genuinely hard to prove.
Here is the list above, turned on my own work:
The hardest problem, on purpose. The part I took on is the one most teams route around: making a probabilistic system trustworthy enough to leave alone. Cross-family review where no model family grades its own output, eval gates between stages, refusal treated as architecture.
The data loop from day one. Every gated ship writes a record — which model ran, what it cost, which gate caught what. That is data accumulated by operating, and nobody clones it by shipping the same feature. Where it is built to go next is the part I actually care about: a system that learns from its own operation, and — by consent, never by default — from how other teams run theirs. A workflow that gets sharper because somebody else’s build broke is a moat that compounds instead of depreciating.
The standard as a gate, not a habit. It is a pipeline, which is what stops a deadline from quietly deleting the review step. Teams adopt a workflow. They only ever compare a feature.
The room, not just the project. Four and a half years of teaching Fortune 500 executives, and I’m going back to it — because a room of executives asking why is still the fastest way I know to find the edge of my own understanding.
Distribution, built in. I am the product’s first user: I run my own distribution through it, which lifted my LinkedIn engagement roughly 500% and my Substack growth well over 1,000%, and is how this piece reaches you. Eating your own dog food is not a slogan — it is the only way I find the defects a customer would have found first.
Distribution I already had, without calling it that. Fifteen hundred Fortune 500 executives taught, the UC Berkeley Exec Ed AI alumni community I run, the Xoogler community, LPM, talks at SXSW and Step SF and ClawCamp, and writing like this. Channels compound quietly for years before you notice they are channels — which is also the honest reason to want an accelerator or an investor. The right one is a distribution asset before it is capital.
Still open: the ICP, and the first real buyer. Finding who this is unmistakably for is work I still have in front of me, and engineers asking to buy is interest, not validation. Willingness to pay is the only proof that survives contact with a budget.
Those last two are why it stays a side project, and they are in here on purpose. A moat list you only ever apply to other people’s companies is a blog post.
And the moat this piece says nobody lists — still being there after the fifth pivot — is one you can only show. My ICP has moved five times since February: careers, then branding, then culture, then developers, then AI startups. Every move meant rebuilding something I had just finished. None of them changed the thesis, because the thesis was never the customer — it was the loop. I also killed two explorations this year on exactly the signal above. Persistence isn’t refusing to let go. It’s knowing which thing to hold.
The teams I want to work with build the system that builds the product. If that’s yours, let’s talk.
Grateful for Andrew Ng; Andy Ku and Jill Shih for the customer-discovery frameworks that reshaped how I think about pain; Eli Chen for the execution-first mindset — beachhead discipline, experimentation-based learning, and the “5% inspiration, 95% perspiration” frame — that I’ll carry into every build; Anurag Jain for the reframe on solving the right pain; Sandeep Gupta, a fellow EIR from my cohort, for the data-access-as-moat lens; Dan Landau for advising me on story, personal brand and how to market from day one; the AI Fund team; and the founders who shared their stories with me during the EIR.
And a separate thank you to the people who didn’t just cheer from the sidelines — the ones who put their own time into this on purpose. The interns who built alongside me — Kaden Jackson, Sidhant Lochan and Michael Chen. The engineers who shipped things they didn’t have to. The ICP discovery partners who gave up their own hours to help me work out who the customer actually was. The design partners who let me watch them work and told me the truth about what was broken. The marketers who handed over hard-won insight and asked for nothing back. The AI Fund portfolio companies and the people there who took my calls, sat through interview after interview, opened their playbooks, and genuinely tried to be my ICP — several of them were a real fit, the commercial pull just wasn’t there yet. The friends who went looking for customers on my behalf without being asked.
Support is passive. These people were deliberate about it — and that is the difference between a hard three months and a good one.
They say it takes a village to raise a child. It takes at least as many to raise a startup, and I had four: the AI Fund portfolio, my UC Berkeley EMBA cohort and the Haas alumni network, the Xoogler community, and LPM — the Large People Model. Most of the customer interviews behind Part 1 came out of those rooms — strangers who gave me an hour to tell me what was actually broken. That is the network you query when the answer isn’t in anybody’s training data. Thank you for being part of the journey.
Onwards.