marketplace_cold_start v1.0.0

name: "marketplace_cold_start" description: "Solve the cold start for a marketplace or network product: define the atomic network and one launch slice, pick a primary strategy with a scored selector (single-player tool, seeded supply, concierge match, hard-side subsidy, closed network), seed by marketplace type, and read per-slice liquidity with a tested calculator until the loop sustains itself. Use when launching a two-sided marketplace, community, or network product, when early growth stalls with users on both sides but no transactions, or when deciding where to launch first."

Marketplace Cold Start

Purpose

Get a marketplace or network product from empty to self sustaining in one slice, then repeat the unit. The cold start problem, in Andrew Chen's framing, is that the product is worthless with no users and users will not stay for a worthless product. The way out is not more total users. It is density in a small unit that works on its own, called the atomic network, plus a seeding method matched to the type of marketplace.

Scope boundary: this skill covers the period before and just after first liquidity in each slice. For general growth marketing after liquidity, use a growth skill. For pricing and take rate design, use a pricing skill. This one ends when slices pass their liquidity targets on their own and expansion becomes a repeatable copy.

Workflow

1. Name the transaction and the sides. Write one sentence: who pays or acts, who supplies, what counts as a completed transaction, and how often a happy user needs it again. If the transaction cannot be stated, stop. No strategy fixes an undefined transaction.
2. Cut the first slice. Pick one category, one place or one bounded community, and one time window. The slice must be small enough that the team can recruit a real share of its suppliers by hand. State the boundary a match can happen inside: a travel radius, a category, a campus, a trade. Read references/metrics-and-density.md for the slice rule.
3. Set liquidity targets before seeding. Choose buyer liquidity, seller liquidity, and a target utilisation for this slice, with the window stated. Set them in writing now, while no results exist to argue with. Use scripts/liquidity.py to work out required suppliers from expected demand, supplier capacity, and target utilisation.
4. Identify the hard side. The hard side is the side that is harder to get and that the other side values most. Test it with evidence: which side says no more often, which side's absence kills a match, which side competitors fight over. Subsidy, concierge time, and recruiting effort go to the hard side first.
5. Pick one primary strategy. Score the five strategies in references/strategy-selector.md against this slice: single-player tool, seeded supply, concierge match, hard-side subsidy, closed atomic network. Pick the highest score as primary. Name any supporting tactic as supporting, in second place. Two primary strategies at once is how cold starts stall.
6. Seed inside the slice only. Follow the playbook for this marketplace type in references/seeding-playbooks.md: local services, goods, jobs, social and community, or B2B. Every seeded listing must be able to transact. Recruit by hand, build profiles for suppliers, photograph or write the listing with them if that is what quality takes. Log the source of every seeded supplier.
7. Be the matching system until it teaches you the rules. Match by hand, confirm both sides, and write down every manual step and judgement. After 10 to 20 matches, the notes are the spec for search, ranking, or automation. If hand made matches do not close, the problem is the offer, the price, or trust. Fix that before building software.
8. Measure per slice, weekly. Run python3 scripts/liquidity.py once per slice with the window's searches, transactions, listings, suppliers, demand, and capacity. Report buyer liquidity, seller liquidity, time to first match, utilisation, repeat rate, and zero-result search rate where search exists. Read the pattern table in references/metrics-and-density.md before acting on any single number.
9. Decide: hold, shrink, fix, or expand. Both liquidities pass target for two consecutive windows and repeat rate is stable or rising: expand to one adjacent slice and repeat from step 2. Either liquidity fails and utilisation is high: shrink the slice. Both fail and utilisation is low: return to concierge and repair the offer. Never expand on total user growth while per slice liquidity is flat.
10. Taper help on a written rule. Subsidies, concierge hours, and staff seeding drop when the slice passes target, not when the team gets tired. Write the taper condition at step 3 and honour it. Keep a weekly watch on passed slices for a month after expansion, because a slice can fall back when attention moves.

Output Contract

• A one page cold start plan stating: the transaction sentence, the first slice and its boundary, the hard side with its evidence, liquidity targets with windows, the primary strategy with its selector scores, and the taper rule.
• A seeding log for the slice: supplier, source, date added, first transaction date, active or seeded-only status.
• A weekly per slice liquidity report from scripts/liquidity.py, with the five numbers from references/metrics-and-density.md and a hold, shrink, fix, or expand decision with its reason.
• Worked required-supply arithmetic for the slice, with demand, capacity, and target utilisation shown, so anyone can check the count the plan aims at.
• An expansion note when a slice passes: what was copied to the next slice unchanged, what was changed and why.

Operating Rules

1. Density beats totals, every time. Report and judge per slice. A platform wide average that mixes a working neighbourhood with nine empty ones is a false pass.
2. One slice, one primary strategy. Supporting tactics are allowed and must be labelled supporting. Splitting seed effort across slices before one passes is the most common self inflicted stall.
3. No fake activity. No fake accounts posing as users, no fake reviews, no listings that cannot transact, no demand numbers the team invented. Team seeding is done openly as the team, or as clearly platform owned supply. Historical cases where founders hid behind aliases are history to learn from, not steps to copy.
4. Subsidise activity, not signups. A guarantee pays on a completed listing, a worked shift, or a first transaction. Paying for registrations buys a crowd that never transacts and poisons the liquidity numbers.
5. Targets before results. Liquidity targets, windows, and taper rules are written before seeding starts. Changing a target mid window needs the reason logged in the weekly report.
6. Manual first, software second. If a human cannot make the match close with full information and personal effort, software will close it less often. Concierge failure is product information, not a staffing problem.
7. Every factual example in a plan must trace to a checked source. Case stories used here are in the skill references with their sources: Chen on atomic networks and Tinder at USC, Dixon on come for the tool with YouTube, Graham on Airbnb in New York, Gurley on Uber density per city. Numbers in worked examples are labelled hypothetical and show their arithmetic.
8. Test before shipping a plan. Verified in this environment under Python 3.12: scripts/liquidity.py compiles, the demo slice returns buyer liquidity 62.0 percent, seller liquidity 27.5 percent, and required suppliers 90, a thin slice returns both liquidities below target with a supplier shortfall named, and an impossible input, transactions above searches, fails with a clear message.