WhizCloud
Case study · Chapter 01
Marketplaces & Platforms

From offline vendor chase to a Request → Quote → Approval marketplace.

A multi-platform service marketplace built with NestJS, MongoDB, React, and Flutter — where users discover, compare, and book venues and services across web and mobile with a complete booking lifecycle and real-time notifications.

Chapter 02
The challenge

Service booking was fragmented, opaque, and unscalable.

Users coordinated vendors manually. Vendors had no structured leads. There was no digital trail for quotes, approvals, or status — so growth meant more chaos.

01

Manual multi-vendor coordination

Users chased catering, photography, and venues through phone and email with no single system.

02

No price or availability comparison

Nothing centralised real-time pricing or availability across service categories.

03

Limited review and location visibility

Booking decisions happened without clear quality signals or proximity context.

04

Vendors lacked lead tools

Enquiries, quotes, and booking status lived offline with no scalable workflow.

Chapter 03
Project Context

Client

Fast-growing service marketplace

Industry

Venues & event services

Integrations

NestJS · MongoDB · FCM · AWS

Engagement

Full platform · web + mobile

Chapter 04
Research & Discovery

What we learned before we designed anything

Findings from event planners and vendors — the basis for every discovery, booking, and admin decision that followed.

Key findings

Consolidation drives conversion

Users abandoned booking when they could not compare prices and availability in one place.

Location is the first filter

Proximity consistently beat every other discovery criterion before price or reviews.

Vendors needed lead management most

Untracked enquiries were the biggest operational pain on the supply side.

Variable pricing needs quotes

A fixed-price checkout would fail categories where pricing is negotiated per event.

Real-time status is expected

Any lag between vendor action and user notification created support load and confusion.

Competitive landscape

Category-specific silos

Most marketplaces covered one service type — not venues, catering, and photography together.

Weak vendor tooling

Competitors offered listings, not full quote and approval workflows with booking tracking.

Location gaps in B2C services

GPS-aware discovery was common in consumer apps but rare in this marketplace category.

User Persona

Ananya

Event Planner · Corporate Events

Goals
  • • Compare vendors by location and category
  • • Get quotes quickly
  • • Track booking status in real time
Pain Points
  • • Chasing vendors manually
  • • No transparent price comparison
  • • No record of what was agreed
Chapter 05
Information architecture

One NestJS API powering web, mobile, and admin.

Discovery, booking engine, vendor management, and notifications share a multi-tenant backend so every surface stays in feature parity.

One NestJS API powering web, mobile, and admin.
Chapter 06
Designing solution

Marketplace modules built around the booking engine.

Request → Quote → Approval sits at the core — discovery, vendor tools, and admin control all reinforce that lifecycle.

Before

Users had no way to discover, compare, and book services in one place.

01
Discovery

Location-aware marketplace browsing

  • ✓GPS and manual city/area selection with category browsing and featured recommendations
  • ✓Vendor detail pages consolidating pricing, albums, reviews, maps, and similar services
Before

Coordination happened entirely offline with no structured booking trail.

02
Booking Engine

Request → Quote → Accept → Complete

  • ✓Full multi-step lifecycle with history, cancellation, and modification support
  • ✓Real-time status (Pending, Approved, Completed) visible to user and vendor
Before

Vendors had no tools to manage leads, listings, or bookings at scale.

03
Vendor Dashboard

Leads, listings, and quotes in one place

  • ✓Listing management for pricing, albums, and availability plus enquiry tracking
  • ✓Structured quote responses without leaving the platform
Before

Operations needed developer involvement for every category or content change.

04
Admin Panel

Self-serve marketplace control

  • ✓RBAC for users, vendors, bookings, quotations, and content management
  • ✓Dynamic form builder so new service categories launch without code changes
Chapter 07
Technology

Built for multi-platform booking at scale.

NestJS, MongoDB, React, Flutter, FCM, and AWS chosen so flexible categories and real-time notifications stay consistent across devices.

Built for multi-platform booking at scale.
Chapter 08
Implementation

Booking engine first, then discovery and parity.

The Request → Quote → Approval domain was designed and tested before discovery and vendor features layered on — with web, mobile, and admin shipping in parallel.

01

Discovery

Mapped every user and vendor touchpoint from first search to completed booking.

02

Booking engine first

Designed and validated the core lifecycle state machine before frontend surfaces.

03

Parallel delivery

Built React web, Flutter mobile, and admin against the same NestJS API.

04

Notifications & auth

Integrated FCM push, JWT/OTP, Google Sign-In, and optional biometric login.

05

Cloud launch

Deployed on AWS with managed MongoDB, S3 media, and CI/CD pipelines.

Chapter 10
Results & Impact

What changed after launch

✓

Manual coordination eliminated - Discovery, comparison, quoting, and booking all happen inside the platform.

✓

Faster booking journeys - Users complete discovery to confirmed booking without leaving the app.

✓

Higher vendor engagement - Structured lead management and booking tracking gave vendors the tools they were missing.

✓

Location-based confidence - Proximity, price, and reviews enabled real-time decision making for the first time.

✓

Ops independence - Categories, listings, and content updates no longer require developer involvement.

✓

Future-ready foundation - New cities and service types are added through admin configuration, not architecture changes.

Chapter 11
The Learnings

Challenges & Learnings

Multi-tenant RBAC

Users, vendors, and admins needed strict data separation designed from day one.

Dynamic form builder

Category-specific inputs required a flexible MongoDB schema and dual-platform rendering.

Quote state complexity

Expired, re-quoted, and partial accepts demanded a disciplined state machine.

Location accuracy

GPS worked in dense cities; manual area fallback was essential elsewhere.

Real-time consistency

Push events had to reach user and vendor simultaneously without race conditions.

Chapter 12
What's next

Where the platform goes from here

Production payment gateway with refunds and vendor payouts
Vendor analytics for enquiry and conversion rates
Advanced search, availability, and rating filters
Verified post-booking review flows
Multi-language and multi-currency expansion
AI-powered vendor recommendations
Chapter 13
In their words
“

WhizCloud took our vision of a unified service marketplace and turned it into a fully working platform faster than we expected. The booking engine works exactly as we needed — the quote and approval flow has transformed how our vendors manage requests.

“What stood out was their ability to think about both sides of the marketplace — the user experience and the vendor tools — at the same time. The admin panel gives us complete control, and the dynamic form builder means we can launch new service categories ourselves.”

Smart Booking Marketplace Client
Smart Booking Marketplace · Venues & Event Services