Seed the supply side or wait for it: the cold-start choice two-sided models can't dodge

Every two-sided model has a moment before it has any sides at all. A buyer opens the marketplace and there’s nothing to buy, or a provider opens it and there’s no one to sell to. Whichever one shows up first meets an empty room — and an empty room is usually the last time they check.

The canvas question this sits on is M1: who goes first isn’t a marketing decision, it’s a model decision, and it has exactly two honest answers.

	Seed it yourself	Wait for it to show up
What day-1 buyers see	a working example	an empty shelf
Who does the first unit of work	your own account, playing the supply role	whichever real provider arrives first — no guaranteed timing
Risk if skipped	none — the shelf is never empty	buyer visits once, finds nothing, doesn’t come back to check again
BIXSO built it as	Service Place — seeded as its own provider, 3 listings, before opening	the default on every app, by omission, until someone notices and fixes it
Choose when	you can credibly deliver the first few units yourself	neither side can substitute for the other — you genuinely have nothing to seed with

On Service Place, the fix was direct: on 18/07/2026, BIXSO’s own account was seeded as a provider with three real listings before the marketplace opened to outside providers. No abstract “coming soon” state, no placeholder cards — an account that could actually respond to a booking, doing the job a real provider hadn’t shown up to do yet.

That’s the clean half of the story. The other half is why it needed to happen as a fix rather than as a plan.

Nine days later, on 27/07/2026, a separate audit — done for an unrelated reason, connecting Service Place to a sibling app — found that POST /api/services, the endpoint a real provider would need to list their own service, had existed since the app’s first build with zero call sites. No button, no form, no path in the UI that ever called it. A provider signing up organically had no way to list anything at all; every listing on the platform, seeded or otherwise, existed because someone ran a script.

That’s the honest limit here: seeding the supply side wasn’t a cold-start strategy anyone decided on in advance. It was the accidental default, because the feature that would have made seeding unnecessary — a real provider being able to list something themselves — hadn’t been built yet. The seed covered for a gap that took over a week to even get noticed, let alone closed.

The lesson isn’t “always seed the supply side.” It’s that the seed-vs-wait decision only looks deliberate after the fact. Made on purpose, seeding buys you real trials while the self-serve path for the harder side gets built — and it should come with a tracked date to retire the seed, not stay indefinite. Made by accident, it’s identical from the outside, but there’s no one checking whether the real path exists yet.

If you’re building a two-sided model and the supply side is thin: ask which of the two rows in that table you’re actually in — deliberate bridge, or an empty gap nobody’s looked at yet. The table looks the same either way. Only one of them has an end date.

This is a M1 (who goes first) question on the Business Solution Canvas — free, CC BY-SA, open for anyone building the same decision into their own model.