Back to blog feed

Case Study

Shipping a Multi-Vendor Marketplace MVP in Six Weeks

A six-week MVP case study covering vendor onboarding, order orchestration, and payments without creating unpayable technical debt.

Shipping a Multi-Vendor Marketplace MVP in Six Weeks

Marketplace MVPs fail when teams try to ship "all commerce features" at once. We treated this build as a constrained systems problem: one buyer app, one vendor panel, one admin console, one payment path, and one reconciliation loop.

Week 0: scope lock and kill list

Before coding, we made a kill list of features that looked attractive but would break timeline:

  • No real-time bidding.
  • No dynamic commission experimentation.
  • No full warehouse sync.
  • No custom payout schedules per vendor.

That decision protected the six-week target more than any framework choice.

Week 1-2: vendor onboarding and catalog flow

Vendor onboarding had one goal: fast time-to-first-live-listing. We implemented:

  • KYC status states (pending, approved, blocked).
  • Catalog upload with async validation.
  • Admin moderation queue with bulk approve/reject.

The async validation queue prevented onboarding traffic spikes from affecting buyer API latency.

Week 3-4: checkout and order orchestration

Checkout was designed for idempotency from day one. Each order request carried an idempotency key and payment session token. If payment callbacks duplicated, the order pipeline still produced one final order state.

Order state model:

created -> payment_pending -> confirmed -> vendor_ack -> packed -> shipped -> delivered/cancelled

Every transition was event-logged for support and dispute resolution.

Week 5: settlement and operational control

Multi-vendor payout logic is where MVPs usually collapse. We kept it deterministic:

  • Commission calculated at order confirmation.
  • Refund adjustments applied as explicit settlement entries.
  • Payout reports generated per vendor per cycle.

Support tools included one-click order timeline and payment trace view. That cut escalation time significantly during launch week.

Week 6: launch plan and blast-radius control

Launch was staged by category and geography. Controls included:

  • Feature flag for checkout path fallback.
  • Rate limits per vendor API key.
  • Rollback path to "catalog-only mode" if payment reliability dropped.

We also ran shadow reconciliation for the first week: settlement engine output was compared with manual accounting snapshots before payout execution.

Results after first 30 days

The MVP launched on time, vendor activation was above target, and support load stayed manageable because order/payment traces were visible from day one. Most importantly, the architecture left room to add advanced pricing and promotions later without rewriting core order flow.

What we would still change

If we had two extra weeks, we would add automated vendor quality scoring and stronger inventory drift alerts. Those are important, but they were rightfully excluded from MVP critical path.

Related reading:

Comments

Threaded replies are enabled. Upvote useful ideas.