In the fall of their freshman year at USC, Anantika Mannby and Miki Safronov-Yamamoto kept circling back to the same question: where should they spend the summer. The answer was San Francisco, in a hacker house, building their companies alongside people doing the same thing. The houses that already existed had a problem that had nothing to do with rent or location. The gender ratio was so lopsided that neither wanted to live in one.

So they decided to build their own, a women-only version, and ran straight into a deadlock. A house needed money to exist. Money needed a house to exist first. Neither side would move until the other one already had.

The Trap

For some businesses, the hardest problem shows up before the product does. A marketplace needs both buyers and sellers, and neither wants to be first to an empty room. A community needs both members and a reason for those members to show up, and a reason is hard to manufacture without people already there to experience it. A platform needs both developers willing to build on it and users worth building for. In each case, waiting for a clear signal from one side before approaching the other produces exactly the freeze Mannby and Safronov-Yamamoto were living through. There is no signal. There is only whoever moves first.

Stop Treating Both Sides the Same

The instinct in this situation is to try to solve the whole system at once, one pitch that lands both the money and the people. That instinct is usually the mistake. The two sides of a dependency like this rarely have the same cost of entry, and treating them as one combined problem means the harder side sets the pace for both. The more useful move is not to solve the chicken-and-egg problem in the abstract. It is to find the one dependency you can remove without asking anyone's permission, and let that change what the other side is being asked to say yes to.

For FoundHer, money required proof before it would move. Curiosity did not. Backers needed something concrete to point to before committing real dollars to a nonprofit house with no track record. Aspiring residents needed nothing more than an application form and a reason to be interested. Once the founders stopped trying to win over both sides with the same motion, they had an obvious place to start.

Finding the Side With the Lower Activation Cost

The practical version of this looks like a short sequence rather than a single decision. Name both dependencies honestly, without assuming either one is obviously the priority. Ask what each side actually needs before it will move, not what would be nice to offer them. Identify which of those thresholds is lowest, the one a stranger could clear without money, without your product finished, without a track record behind you. Put almost all of your early effort into that side, and let it produce something real. Only then take that proof to the side that required it in the first place.

This is a sequencing decision, not a hustle decision. The founders were not simply working harder than everyone else. They were choosing, deliberately, which problem to solve first because it was the only one they were actually able to move without waiting on someone else's approval.

What FoundHer Did

Safronov-Yamamoto started dialing, according to an interview with EO Magazine, ending up on as many as three calls a day with founders she had never spoken to before. Every call closed with the same request: introduce me to the most talented female founder you know. Three months in, she estimated she had spoken to nearly every female founder in her network and theirs. An application went up online with no track record behind it, a LinkedIn post spread on its own, and close to a hundred women applied to live in a house that, for all anyone could tell, was little more than a website.

None of that took capital. It took a repeatable ask that cost the person on the other end of the call nothing to answer honestly, and the willingness to make that call a hundred times over.

Proof Before Infrastructure

By the time backers were approached, the founders were not describing a hypothetical house. They were describing a house with close to a hundred real, named applicants attached to it, which is a fundamentally different conversation than an idea on a slide. FoundHer eventually launched on roughly fifteen thousand dollars in total donations, a modest figure that reflects less about how cheaply a hacker house can run and more about how much of the actual problem, the part that usually eats months of a founder's time, had already been solved before any of that money arrived.

Two Other Versions of the Same Problem

A two-sided marketplace usually frames its cold start as needing both buyers and sellers at once. It rarely does. A founder can recruit twenty sellers manually, by phone or by hand, using nothing more than a shared spreadsheet and a promise of early visibility, long before any platform code exists to formally match them with buyers. The sellers do not need the platform to be real yet. They need a reason to believe buyers are coming, and a founder willing to personally deliver the first few.

A community-driven product has the same asymmetry hiding inside it. Members do not need a finished product to gather. They need a narrow, specific problem worth gathering around, which can exist in a Slack channel or a group chat months before there is any business model funding it. The organizer's job in that early stage is not to build the infrastructure. It is to prove the problem is real enough that people show up for it without being paid or sold to.

The Sequencing Test

Before building a pitch deck or a fundraising plan, it is worth asking one specific question honestly: of everything I need, which one can I get moving without asking anyone for permission or money. Whatever the answer is, that is where the first few weeks should go, not because it is the more urgent need, but because it is the only one currently inside your control.

This Does Not Mean Always Go First

It is tempting to turn this into a universal rule, always find the free side and start there. Some businesses do not have a free side. A regulated product may need legal clearance before either customers or capital can move at all. A hardware company may need working prototypes before either side takes it seriously. In those cases, the framework still applies, but the answer to which dependency can move first may simply be smaller and slower than a phone call, a single pilot customer, a working sketch, rather than nonexistent. The question is worth asking even when the honest answer is that almost nothing can move yet, because it usually reveals more room to act than the deadlock first suggests.

The Closing Principle

When two things depend on each other, the instinct is to ask how to build both at once. The more useful question is narrower. Ask which one can move first, on its own, without waiting for the other. Everything else tends to follow from getting that one answer right.

‍

read - Thinking Like a Scientist: Why Great Founders Test Their Ideas Before They Bet On the Company