How to solve the cold start problem for a two-sided marketplace?

I'm building a P2P crowdshipping marketplace, basically BlaBlaCar but for packages instead of passengers. Travelers going between cities/countries carry items for people who need to send stuff.About to launch the MVP and hitting the classic chicken-and-egg problem.Travelers won't sign up without packages to carry, senders won't post without travelers available. Every marketplace founder says "focus on one side first" but nobody gets specific about how they actually did it, especially when you can't fake supply like you can with a SaaS landing page.For those who've built P2P platforms or two-sided marketplaces: what actually worked for your first 50-100 transactions? Did you manually match people? Subsidize one side? Constrain to one route/city?

Hacker NewsToolAISource
0Sign in to voteCopy link

FL score

42

out of 100

Verdict

SKIP

medium confidence

Competition

No competitor data yet

Trend

No signal yet

A P2P shipping marketplace that solves last-mile costs by leveraging existing traveler routes, but needs to prove unit economics work before scaling.

The pain

Shipping small packages between cities costs $15-40 through traditional carriers. People traveling between cities have unused luggage space. Senders want cheaper options. Travelers want to offset travel costs. The pain is real on both sides.

The gap

The founder has identified the problem but is stuck at the execution gap: how to get the first 50-100 transactions without a chicken-and-egg deadlock. They're asking the right question but haven't committed to a specific constraint or subsidy strategy. The marketplace only works if there's sufficient overlap between traveler routes and sender destinations.

Build angle

Don't build a general marketplace yet. Pick one specific route (e.g., London-Paris, NYC-Boston) where you can manually operate for 3 months. Recruit 20-30 regular travelers on that route through travel forums, expat groups, and university networks. Subsidize their first 3 shipments to get senders. Once you hit 30-50 transactions on that route with positive unit economics, expand to 2-3 adjacent routes. Only then build the full platform. The constraint forces you to learn what actually makes the marketplace work.

Strengths

  • Real problem with clear willingness-to-pay on both sides (senders save money, travelers earn money)
  • Low-tech MVP possible (manual matching via WhatsApp/email for first 100 transactions)
  • Existing successful precedent (BlaBlaCar proved the model works for passengers)
  • Network effects kick in once you hit critical mass on a route
  • Regulatory arbitrage: less regulated than traditional shipping

Risks

  • Unit economics may not work: if average shipment is $20 and you take 20% commission, you make $4 per transaction. At 10 transactions per day, that's $40/day revenue. Doesn't scale without volume.
  • Liability and insurance: who's responsible if a package gets lost or damaged? This could kill the business if not solved early.
  • Traveler reliability: unlike BlaBlaCar where no-shows hurt one person, a no-show here affects a sender's business. Trust is harder to build.
  • Route concentration: marketplace only works on high-traffic routes. Most routes won't have enough travelers to create supply.
  • Regulatory risk: some countries may classify this as unlicensed shipping and shut it down.
  • Chicken-and-egg is real: you can't fake this like SaaS. You need actual people moving actual packages.

Questions about this idea?

FlyBot reads the scoring and gives you a second opinion on “How to solve the cold start problem for a two-sided marketplace?”.

Open FlyBot