B2B Marketplace Platform — MVP to Scale
We designed and built a two-sided B2B marketplace from concept to launch in 12 weeks. The platform connects verified industrial suppliers with procurement teams, handling $2M+ in transactions in its first quarter.
12 weeks
Time to launch
Discovery to production
$2M+
First-quarter GMV
Gross merchandise value
99.9%
Platform uptime
Through first-quarter peak
The challenge
The founding team had a strong commercial thesis but no technical team. They needed an MVP that could attract early marketplace participants, validate the supply/demand fit, and handle financial transactions securely — all within a tight runway.
Objectives
- Launch a working marketplace in 12 weeks
- Support supplier onboarding without engineering involvement
- Handle split payment settlements between platform and suppliers
- Build admin tooling for moderation and dispute resolution
Discovery
We ran a structured 2-week discovery sprint before writing any code: mapping the supply/demand workflow, identifying the minimum feature set to validate commercial fit, and designing the data model around multi-tenancy from the outset. The founding team joined daily sessions — their commercial knowledge shaped every scope decision.
Strategy
Ship the minimum viable marketplace — enough for the founding team to run supplier recruitment and onboarding conversations — then layer in catalogue management and payment infrastructure in parallel sprints. Admin tooling was built alongside the product, not after, so the team could operate without engineering support from day one.
How we approached it
We ran a 2-week discovery sprint to define the MVP scope and data model. We then built a Next.js storefront, a supplier onboarding portal, a real-time inventory catalogue, and a payment layer using Stripe Connect for split settlements. Multi-tenant architecture allowed suppliers to manage their own product listings independently. Admin tooling let the client moderate listings and manage disputes without engineering involvement.
Architecture
Multi-tenant Next.js application with per-supplier namespacing. PostgreSQL with row-level security for tenant isolation. Stripe Connect for split settlement — suppliers receive funds directly with platform fees deducted at transaction time. Redis for catalogue search caching. Node.js API layer handling business logic, webhook processing, and event queuing.
Implementation
Four two-week sprints: (1) supplier onboarding and authentication, (2) catalogue management and search, (3) checkout and Stripe Connect integration, (4) admin moderation tooling and analytics. Each sprint shipped to a staging environment that the founding team used to run real supplier conversations — feedback from those conversations directly shaped sprint 3 and 4 scope.
Key decisions
Build vs. buy for catalogue search — a proper search engine would have been more capable but added operational complexity to an MVP.
PostgreSQL full-text search with Redis caching was sufficient for the initial catalogue size and avoided introducing Elasticsearch before it was needed.
Custom payment logic vs. Stripe Connect — building custom settlement logic would have given more flexibility but introduced significant compliance and engineering risk.
Stripe Connect handled split settlement, identity verification, and payout compliance. The constraints of the platform were acceptable trade-offs for the speed and compliance coverage it provided.
What changed
Platform launched in 12 weeks. Within the first quarter, $2M+ in gross merchandise value was processed. Supplier onboarding time averaged 48 hours. System maintained 99.9% uptime through peak demand periods.
Impact
The founding team closed their first 12 supplier partnerships during the build phase and processed $2M+ in transactions in the first quarter without any engineering support for day-to-day operations.
Lessons learned
- 1Involving the founding team in daily discovery sessions removed the biggest risk for a first-time technical engagement — misaligned scope.
- 2Building admin tooling in parallel (not after) meant the client could operate independently from the first week of launch.
- 3Multi-tenancy decisions made in week 1 avoided a painful re-architecture that would have been required at supplier 50+.