Build a marketplace or platform business

The Real Problem Behind Platform Issues

Most founders think building a marketplace is about features. They obsess over matching algorithms, payment systems, and user experience flows. But that's solving the wrong problem.

The real constraint in every marketplace is liquidity imbalance. You either have too many buyers chasing too few sellers, or vice versa. Everything else — conversion rates, retention, revenue per user — flows from this single bottleneck.

I've seen founders spend six months building sophisticated recommendation engines when they have 12 active sellers. They're optimizing for a problem they don't have yet. Meanwhile, their core constraint — getting more quality supply — remains unsolved.

Think about it through constraint theory: Your marketplace's throughput is determined by its weakest link. If you have 10,000 buyers but only 50 sellers, adding more buyers won't increase transactions. The system can only process what the constraint allows.

Why Most Approaches Fail

The typical approach treats marketplaces like software products. Founders build features first, then try to find users. This is backwards and expensive.

They fall into what I call the Complexity Trap. They assume more features will solve the liquidity problem. Chat systems, advanced search, mobile apps, AI recommendations. Each addition creates new failure points without addressing the core constraint.

Here's what actually happens: You launch with 20 features but zero network effects. Users visit, find an empty marketplace, and leave. You respond by adding more features to "improve engagement." The cycle continues until you run out of money or patience.

The marketplace that wins isn't the one with the most features. It's the one that solves the liquidity problem first and fastest.

Another common mistake is trying to serve everyone. Broad markets feel safer but create weak network effects. A marketplace for "freelancers" competes with Upwork. A marketplace for "React developers in fintech" has a chance to dominate a specific niche.

The First Principles Approach

Strip away everything inherited from other marketplace models. Start with one question: What's the minimum viable transaction that creates value for both sides?

Airbnb didn't start with professional photography and insurance policies. They started with air mattresses and cereal boxes. The minimum viable transaction was "sleep somewhere for less money." Everything else came later.

Identify your supply constraint first. In most marketplaces, supply is harder to acquire than demand. People will download an app to buy something. Getting them to sell requires more effort, trust, and often upfront work.

Map your constraint mathematically. If each seller can handle 10 transactions per week, and you want 1000 weekly transactions, you need 100 active sellers minimum. This becomes your primary metric — not downloads, not signups, but active suppliers.

Design your entire system around maximizing this metric. Your onboarding flow, incentive structure, product features, and resource allocation should optimize for removing the supply constraint.

The System That Actually Works

Build what I call a constraint-focused platform. Every decision filters through one lens: Does this help solve our primary bottleneck?

Start with manual processes. Handle payments manually through existing tools. Use spreadsheets for matching. Build the bare minimum technology needed to facilitate transactions, nothing more. This lets you validate demand without building complex systems.

Focus intensely on supplier acquisition and retention. Create compounding loops where successful suppliers attract more suppliers. This might be referral bonuses, exclusive territories, or revenue sharing that increases with tenure.

Measure supplier health obsessively. Track active suppliers, transactions per supplier, supplier churn, and time to first transaction. These metrics predict marketplace health better than user growth or gross transaction volume.

A healthy marketplace has excess demand chasing limited supply. If you have the opposite, you're solving the wrong constraint.

Only add features that directly impact your constraint. If you need more suppliers, build better supplier tools. If suppliers need more demand, build better discovery for buyers. Everything else is noise until your liquidity problem is solved.

Common Mistakes to Avoid

The biggest mistake is premature scaling. Founders see early traction and immediately try to expand geographically or add product categories. This dilutes network effects and spreads your limited resources across multiple constraints.

Another trap is the Vendor Trap — outsourcing your constraint to third parties. Using generic marketplace software or relying on external channels for supplier acquisition. You lose control over the one thing that determines your success.

Don't ignore unit economics early. Some founders think marketplace unit economics don't matter during the growth phase. But if each transaction loses money after accounting for acquisition costs, more transactions just mean bigger losses.

Avoid feature parity thinking. Just because Uber has surge pricing doesn't mean your dog-walking marketplace needs dynamic pricing. Build only what your specific constraint requires.

The final mistake is misreading your constraint. If suppliers complain about low demand, but you have 10x more buyers than sellers, demand isn't your constraint — the quality or capacity of your suppliers is. Fix what's actually broken, not what people say is broken.

Remember: Marketplaces aren't technology problems. They're constraint optimization problems disguised as technology problems. Identify your constraint, build the minimum system to remove it, then repeat until you achieve liquidity. Everything else is just complexity for complexity's sake.