Two-sided marketplaces that solve chicken-and-egg with code.
Supply and demand discovery, trust and safety, escrow and payouts, dispute workflows. The engineering shape that lets a marketplace not collapse under its own scale.
Marketplaces have engineering problems other startups do not.
A marketplace is two SaaS products in a trench coat. Supply side and demand side have different funnels, different metrics, different abuse patterns, and different engineering needs. Most marketplace engineering teams ship the demand side first and treat the supply side as an afterthought; six months later the supply side has churned because the tooling never caught up. We have shipped through this trap and know which parts to invest in first.
What changes when a Metafic pod is in your repo.
Supply-side product as carefully as demand-side
The seller dashboard, the listing tools, the payouts and tax reporting. Often the first place to invest after MVP.
Stripe Connect from day one, not Stripe Standard
Marketplace-shaped payments need destination charges or separate accounts. Migrating later is painful.
Trust and safety as engineering, not customer support
Listing-review queues, automated flagging, dispute workflows. We build it as a product surface, not a Slack channel.
Search and discovery against the actual catalog shape
Elasticsearch, Typesense, Algolia, or pg_trgm depending on cardinality, query patterns, and budget. We pick deliberately.
Two-sided fraud detection from week one
Buyer and seller fraud look different. We design rules and monitoring for both.
Who is on the pod for this work.
Pods scale up from here for Enterprise engagements.
Has shipped marketplace platforms to production. Knows the difference between commerce and marketplace patterns.
5+ years, comfortable with payments, search, and the auth complexity of a multi-party platform.
Tests the buyer journey and the seller journey as separate suites. Tests the dispute and payout flows as carefully as the happy path.
For the metrics layer (GMV, take rate, cohort retention) and the fraud-rules data pipeline.
The bugs that bite this stack.
Payout timing assumptions baked into seller UX
Sellers expect next-day payouts. Stripe Connect default is two days. UI implies one. We design for the real schedule.
Search ranking that overfits to demand-side metrics
A search algorithm optimised for click-through can starve new sellers. We design the ranking to balance both sides.
Tax and 1099 reporting added late
US marketplaces hit 1099-K thresholds and have to backfill seller records. We design for it from day one.
Dispute resolution built as a Slack workflow
It works at 10 disputes a week. It breaks at 100. We build the queue.
Honest about scope.
We will not build a marketplace MVP that ignores the supply side. We will redirect that scope toward what actually fails in marketplaces (it is almost never the demand side first).
Common questions.
Stripe Connect or Adyen or Hyperswitch?
Stripe Connect for almost all US/Western marketplaces, especially under $100M GMV. Adyen for global complex multi-currency. Hyperswitch when you are big enough to want vendor-neutral payment routing.
When do we need our own KYC?
Stripe Identity is enough for most marketplaces up to mid-scale. Roll your own KYC integration with Persona / Alloy / Sumsub only when Stripe Identity does not fit your geography or regulatory shape.
Geographic expansion strategy?
Build the multi-currency and tax handling before you launch the second country. Migrating a single-country marketplace to multi-country is harder than building both correctly from the start.
How do we handle dispute resolution?
Build it as a product surface from week one. Customer support tools, automated routing, escalation queues. Marketplaces that treat disputes as a Slack workflow do not survive scale.
Ready to scope it?
A 25-minute call. We will tell you what we would do, what we would not, and whether a pod is the right shape.
Or stay in the loop. One engineering teardown a week.