Most product decisions can be reversed. You can change the pricing, redesign the onboarding, rewrite the backend if you have to. There's one decision that can't be fixed later, and almost nobody makes it deliberately: what happens on the day the platform is live and completely empty.
We ask one question on every first call, before scope, before budget, before anyone opens a design tool:
Which side of your platform can you get 100 of – by hand, within a month, without spending anything on acquisition?
It sounds like a growth question. It isn't. It's an architecture question, a design question and a fundraising question wearing a growth question's clothes. And the number of founders who have a real answer is small enough that it's become our fastest filter for whether a project is ready to exist.
Why launch day is the worst day of a platform's life
A two-sided product has a property that single-sided products don't: on launch day it is worth approximately nothing to everyone who opens it.
Owners won't list items when there are no renters browsing. Renters won't browse when there are eleven listings. A club won't pay for a member network that has three clubs in it. Every participant is rationally waiting for someone else to show up first, and the product does nothing to break the standoff – because the product is the standoff.
This is usually called the chicken-and-egg problem, which makes it sound like a puzzle with a clever solution. It isn't. It's a cost. Somebody has to pay it, in money or in manual labour, before the platform has any value at all. The only question is whether you planned for that cost or discovered it in month five with the code finished and the runway short.
The three answers we hear
"We'll run ads at launch."
This is the most common answer and the most expensive one.
Paid acquisition works when the thing on the other end of the click has value. On launch day, it doesn't. You pay to bring a renter to a catalogue of four items in the wrong city. He looks, finds nothing, leaves, and does not come back – and because he's now seen the product at its worst, you've spent money to lose a user rather than acquire one.
Worse, ads are symmetrical when the problem isn't. You need one side seeded first and the other side pulled in behind it. Spending equally on both usually produces two thin sides that never reach the density where either becomes useful.
Paid acquisition is a scaling tool. It is not a starting tool. There's a point in a platform's life where it becomes the right answer, and it's later than almost everyone assumes.
"I have a WhatsApp group with 400 of them."
This is the answer we're listening for.
It's unglamorous. It doesn't scale. It sounds too small to matter – and it's how most of the platforms you're benchmarking against actually started. Someone had direct, personal access to a hundred people on one side of a market and pulled them in one conversation at a time.
What makes this answer strong isn't the number. It's that it's specific and already true. The founder isn't describing a plan; they're describing an asset they already hold. That asset determines almost everything downstream: which side you seed, what the first version of the product has to do, what it can skip entirely, and how long the manual period lasts.
A founder who runs the regional association for a category of small operator has a real answer. A founder who "knows a lot of people in the industry" doesn't yet – the difference is whether you can list them.
"Both sides will come organically once it's live."
This isn't an answer. It's a hope with a launch date attached.
Organic growth on a two-sided platform is a consequence of density, not a cause of it. Listings get indexed and rank because there are many of them. Word of mouth spreads because the product worked for someone, which requires a counterparty to have existed. Every organic mechanism you're counting on switches on after the cold start, not during it. Building your launch plan on them is building it on the state that comes two steps later.
What the answer changes
Founders sometimes assume this is a marketing conversation that can wait until the build is done. It can't, because the answer changes the product itself.
It decides which side the product is built for first. If you're seeding supply manually, version one needs supply-side tooling that's borderline embarrassing in its simplicity – often an admin panel where your team enters listings on behalf of people who will never log in. If you're seeding demand, you need something entirely different.
It decides what you don't build. A platform whose first 200 participants are all personally known to the founder does not need automated verification at launch. It needs it at month eight. Building it at month zero costs weeks and delays the only thing that matters, which is finding out whether anyone wants this.
It decides whether the platform should exist as software yet. Some of the strongest answers we hear lead to us recommending no platform at all for the first six months – a spreadsheet, a shared inbox, a group chat and manual matching. If matching people by hand doesn't create value, automating it won't either. We've told clients this and lost the project. It's still the right call, and the ones who took it came back with a better-shaped brief.
It decides what you tell investors. "We'll acquire users through paid channels" is the weakest possible answer to the strongest possible question in a marketplace pitch. "I have direct access to 400 operators and 60 have committed to list" is a different conversation.
The self-check
Run these eight before your next build decision. If more than three are uncomfortable, the cold start is your real risk – not the tech stack.
Name the side you'll seed first. One side, not "both".
Can you list 100 specific names or organisations on that side, today?
What do the first 100 get that's worth their time while the other side is still empty?
What are you doing manually for the first six months, and who on the team is doing it?
What's the smallest geography or category where the platform feels full rather than empty?
Which features are you building for a density you don't have yet – and can they wait?
At what point does the second side become self-sustaining, and what number tells you it happened?
If manual matching in a spreadsheet doesn't create value in 60 days, do you stop?
Why this is the first thing we ask
We build marketplaces, P2P products and member networks, and every one of them launched empty. We know what breaks in month two and which features founders wish they'd cut. The failure mode is remarkably consistent: nothing goes wrong during the build. The build goes fine. The platform ships, works, looks good, and sits there.
So we start at the end. Who shows up on day one, and why do they stay while the other side is still empty? If there's a solid answer, everything else is scope. If there isn't, we'd rather say so on the first call than take the money and watch it happen.
If you're building something two-sided and the eight questions above were uncomfortable, that's worth 30 minutes. The call is free, there's no deck, and we'll tell you honestly whether it's ready – including when the answer is that you shouldn't build it yet.