Salon Booking Marketplace — Multi-Salon Platform

Overview#

This is a marketplace for salon and barber bookings, in the spirit of ride-hailing apps. Many salons register on one platform. A client opens the app, sees salons near their location, picks a barber or stylist, a service and a free time, and books. They can visit the salon or ask for a home service, where a barber comes to them if they are close enough.

Salon owners manage their business from a dashboard, barbers see their own schedule and earnings, and a platform admin approves salons, reviews payments and watches for fraud. The working name is still to be decided.

My role#

I did the full build: product rules, architecture, the API, the database design, the three web areas, the background jobs, security, tests and documentation.

The problem#

Booking a haircut usually means calling, waiting or walking in and hoping. Salons lose time on the phone and have no clean record of who served whom or what each barber earned. A marketplace also has to handle money it does not hold: salons collect payment from clients, so the platform needs a fair, auditable way to collect its commission.

Approach & architecture#

The back end is a NestJS modular monolith: one application split into independent modules for discovery, availability, bookings, home service, staff pay, billing, notifications, audit and administration. Modules talk through clear interfaces and events, so any one of them can later become its own service.

1. Client / salon / admin (Next.js PWA)then
2. →NestJS API (versioned REST)

1. NestJS APIthen
2. →PostgreSQL + PostGIS (data, geo search, booking rules)

1. NestJS APIthen
2. →Redis + BullMQ (end-of-day closing, reminders, expiries)

1. NestJS APIthen
2. →private object storage (payment proofs, photos)

1. NestJS APIthen
2. →SMS provider interfacethen
3. →SimRelay (first provider)

The front end is a single mobile-first Next.js app, installable as a PWA, with separate areas for clients, salon partners, staff and the platform admin. Maps use Leaflet.

A few rules shaped everything. All business logic lives on the server: prices, availability, commissions and permissions are always computed by the API, never trusted from the browser. Money is stored as whole minor units, never floating point. Times are stored in UTC and worked out in each salon's time zone.

Key challenges#

No double booking, enforced by the database. A barber cannot be booked twice for overlapping times. Rather than relying on application checks alone, a PostgreSQL constraint rejects overlapping bookings, so even simultaneous requests cannot collide.

Nearby search that stays fast. Salon locations are geographic points, and discovery uses PostGIS distance queries to list salons around the client, with home service limited to a short radius.

Tenant isolation. Every salon's data is scoped to that salon, and integration tests prove one salon can never read or change another's records.

Collecting commission fairly. Each day is closed by a background job that works out what every salon owes. Salons upload proof of payment, an admin reviews it, and unpaid balances lead to a grace period and then a lock. Every money-related change is written to an audit log with who, what and when.

Home visits. Home service has its own flow: the client sends a request with an address, salons accept or decline, and requests expire if nobody answers in time.

Tech stack#

• Next.js, React, TypeScript and Tailwind CSS for the PWA.
• NestJS with Prisma plus raw SQL where PostGIS and constraints need it.
• PostgreSQL with PostGIS for data and geo search.
• Redis and BullMQ for scheduled and background jobs.
• S3-compatible storage with short-lived signed links for uploads.
• Jest unit and integration tests against a real PostgreSQL database.

Results#

Phase 1 is built: salon onboarding and approval, services, staff and schedules, staff pay rules, discovery, availability and booking, check-in and completion, home service, daily settlements with proof review, reports, fraud signals and an audit log. The documented unit and integration test suites pass against a real database. The roadmap lists extension points for online payments, reviews, live location and native apps. It has not launched publicly yet.

Screenshots#