Snapshot
| Detail | Value |
|---|---|
| Client | B2B services marketplace startup, US-based, pre-seed ($500K) |
| Industry | SaaS / Marketplace |
| Engagement | Full Product Engineering (Concept → MVP → Scale) |
| Team | 2 senior full-stack engineers, 1 frontend engineer, 1 QA, tech lead |
| Duration | 14 weeks to launch, ongoing development after |
| Tech Stack | Next.js, Node.js (NestJS), PostgreSQL, Redis, Stripe Connect, Algolia, AWS ECS, Terraform, GitHub Actions |
| Key Result | $2.4M Gross Merchandise Value in Year 1 |
The Challenge
Our client identified an underserved niche in the B2B services market: connecting corporate event planners with independent vendors (photographers, caterers, florists, AV technicians, event designers) in the $50B US corporate events industry. The existing process was painful: planners relied on personal referrals, managed vendor communication via email and spreadsheets, collected quotes manually, and processed payments through a patchwork of invoices and check payments.
The founder’s vision: a marketplace where event planners discover, compare, book, and pay vendors through a single platform — with verified reviews, transparent pricing, and automated payment splitting (the platform takes a percentage of each transaction).
Technical complexity drivers:
Two-sided marketplace dynamics. Two distinct user types (planners and vendors) with different UIs, different onboarding flows, different dashboard needs, and different incentives. The platform’s value depends on having sufficient supply (vendors) and demand (planners) simultaneously — the classic cold start problem.
Multi-vendor booking for single events. An event might require 5–8 vendors (photographer, caterer, florist, AV, rentals, decorator, transportation, entertainment). The platform needed to handle multi-vendor carts, coordinated scheduling, and split payments across multiple vendors per transaction.
Stripe Connect split payments. Each booking payment needed to be automatically split: the vendor receives their fee minus the platform’s commission. Multiple vendors per event meant multiple simultaneous splits from a single planner payment.
Search and matching. Planners needed to search for vendors by service type, location, availability, budget range, and rating — with results ranked by relevance. Simple database queries wouldn’t deliver the search quality a marketplace requires.
Budget: $75K maximum for MVP. The pre-seed funding had to cover 12 months of operations including marketing to bootstrap both sides of the marketplace.
Our Approach
Weeks 1–2: Architecture and Data Model
The data model was the critical foundation. Marketplace data models are inherently complex: many-to-many relationships between planners and vendors, mediated by events, bookings, and reviews.
Core entities:
- Users (polymorphic: planner or vendor profile attached)
- Vendor profiles (service types, location, portfolio, availability, pricing)
- Events (planner-created, with date, location, budget, required services)
- Bookings (linking a vendor to an event, with status lifecycle: requested → quoted → accepted → paid → completed → reviewed)
- Payments (Stripe Connect transactions with split records)
- Reviews (bidirectional: planners review vendors, vendors review planners)
Stripe Connect architecture: We used Stripe Connect in “destination charges” mode. When a planner pays for a booking, the charge is created on the platform’s Stripe account and a portion is automatically transferred to the vendor’s connected Stripe account. The platform retains its commission.
For multi-vendor events: a planner’s total event cost is broken into individual bookings, each charged and split separately. This is simpler and more reliable than trying to split a single charge across multiple vendors.
Weeks 3–6: Core Platform Build
Vendor onboarding and profile:
Multi-step onboarding: business information → service categories → portfolio upload (photos and descriptions of past work) → pricing configuration (hourly, per-event, or custom quotes) → availability calendar → Stripe Connect account setup (identity verification handled by Stripe). A vendor could complete onboarding in under 15 minutes.
Planner event creation:
Planners create an event with: date, location, guest count, budget range, and required service categories. The platform suggests recommended vendor types based on event type and budget.
Search and discovery (Algolia):
We implemented Algolia for vendor search, providing: full-text search across vendor names, descriptions, and specialties; faceted filtering by service type, location radius, price range, and rating; real-time results as the planner types; and geo-based ranking (vendors closer to the event location rank higher).
Algolia’s search quality is significantly better than PostgreSQL full-text search for this use case — and the implementation was 2 days of work versus 2+ weeks to build comparable quality from scratch.
Booking workflow:
- Planner finds vendors and sends booking requests (with event details)
- Vendor receives notification, reviews event details, and responds with a quote (or a standard package price)
- Planner reviews quotes, asks questions via in-platform messaging, and accepts
- Platform collects payment from planner via Stripe
- Vendor delivers the service
- After the event, both parties leave reviews
- Vendor’s payment (minus commission) is released after a 48-hour review period
In-platform messaging: Real-time messaging between planners and vendors for each booking. Implemented with WebSocket (Socket.io) for instant delivery and PostgreSQL for message persistence. Messages are scoped to a specific booking context.
Weeks 7–10: Payment, Reviews, and Dashboards
Multi-vendor payment flow:
Each booking in an event is an independent payment. A planner with 5 vendors for one event makes 5 payments (or optionally, pays the total and the platform splits it). We built a “cart” experience where the planner reviews all accepted quotes for an event and checks out all at once — creating 5 individual Stripe charges with destination transfers, processed as a batch.
Payment holds: after a booking is completed (post-event), the vendor’s payment enters a 48-hour hold period. If the planner raises a dispute, the payment is held pending resolution. If no dispute, the payment is released automatically.
Review system:
Bidirectional reviews (1–5 stars + text) with verified booking validation — only parties who completed a booking can leave reviews. Review aggregation calculates an overall rating, per-service-category ratings, and a “response rate” metric (how quickly the vendor responds to booking requests).
Anti-gaming: reviews must be submitted within 30 days of the event. Vendors cannot see individual reviews until both parties have submitted (preventing retaliatory ratings). Flagged reviews go through a moderation queue.
Vendor dashboard: Booking requests and pipeline, calendar with upcoming events, revenue tracking (earned, pending, paid out), profile analytics (views, search appearances, conversion rate), and review management.
Planner dashboard: Events being planned (with vendor status per event), past events with expense summaries, saved vendors, and a booking history with payment receipts.
Weeks 11–14: Quality, Performance, and Launch
Load testing: Simulated 500 concurrent users (200 planners searching, 100 planners booking, 200 vendors responding to requests). Identified and fixed two bottlenecks: a database query in the search-ranking algorithm that wasn’t using an index (fixed, search response time dropped from 800ms to 120ms) and a WebSocket connection leak in the messaging system under high concurrency (fixed with proper connection cleanup).
Security review: Input sanitization on all user-generated content (XSS prevention). Rate limiting on search, messaging, and payment endpoints. CSRF protection. Stripe webhook signature verification. Admin privilege escalation testing.
SEO foundation: Server-rendered vendor profile pages with structured data (Schema.org LocalBusiness). City-level landing pages for the initial launch markets (New York, Los Angeles, Chicago, Miami, Dallas). Meta tags optimized for “event vendors [city]” searches.
Launch: Soft launch with 35 pre-onboarded vendors in New York (recruited by the founder during the build phase). First planner booking 3 days after launch.
The Results
Year 1 Performance
| Metric | Month 1 | Month 6 | Month 12 |
|---|---|---|---|
| Vendors on platform | 35 | 280 | 840 |
| Planners on platform | 12 | 190 | 620 |
| Monthly bookings | 8 | 95 | 310 |
| Monthly GMV | $18,000 | $120,000 | $340,000 |
| Platform commission revenue | $2,700 | $18,000 | $51,000 |
| Average booking value | $2,250 | $1,260 | $1,097 |
Year 1 total GMV: $2.4M. Platform commission revenue: $360K (15% average commission rate).
Key growth drivers:
- Vendor profiles ranking on Google for “[service] vendors [city]” queries drove organic vendor sign-ups after Month 3
- Planner referral program (launched Month 4) drove 40% of new planner sign-ups
- Average booking value decreased over time as the platform attracted more small and mid-size events — a healthy sign of market broadening
Technical Performance
| Metric | Value |
|---|---|
| Uptime | 99.94% (one 45-minute incident in Month 7) |
| Average search response time | 140ms |
| Payment processing success rate | 99.7% |
| Vendor onboarding completion rate | 72% |
| Platform response to booking request (median) | 4.2 hours |
Business Outcome
The founder used the Year 1 traction ($2.4M GMV, 840 vendors, 620 planners, 15% month-over-month growth in Q4) to raise a $3.8M seed round at a $16M valuation — 18 months after the initial $500K pre-seed. The platform is now expanding to 8 additional US cities.
Client Quote
— Founder & CEO, [Client]
Investment Summary
| Phase | Investment | Timeline |
|---|---|---|
| Architecture + data modeling | $12,000 | Weeks 1–2 |
| Core platform build | $32,000 | Weeks 3–6 |
| Payments + reviews + dashboards | $18,000 | Weeks 7–10 |
| QA + performance + launch | $10,000 | Weeks 11–14 |
| Total MVP | $72,000 | 14 weeks |
| Ongoing development | $7,500/month | Continuing |
Building a Marketplace?
Two-sided marketplaces are among the most architecturally complex products to build.
We’ve shipped marketplace platforms with multi-party payments, matching algorithms,
and the booking workflows that make them work.