Live capacity filtering
Availability is computed against confirmed bookings at query time, not cached from the last write, so a trip that fills drops out of discovery instead of accepting a seat it no longer has.
All case studies
ESTGMAM
Estgmam Marine Marketplace
A two-sided marine tourism marketplace, built as one responsive web platform: Saudi captains list yacht trips, travellers book them, and live capacity removes a full trip from view before the same seat can be sold twice.
- Industry
- Marine Tourism & Travel
- Duration
- 5 Months
- Services
- Custom SaaS Solutions, Web Development, UI/UX Design
Zero
Double bookings
Capacity is checked against confirmed bookings at query time, not after the fact.
100%
Payments through Moyasar
Every booking settles through the licensed Saudi gateway, not a payment path we built ourselves.
3
Applications, one platform
Customer, captain and operator consoles — responsive web apps installable as PWAs, not native store builds — on one source of truth.
Scale-ready
Concurrency architecture
Stateless serverless rendering over pooled database connections, with availability resolved per request, so a booking spike is absorbed rather than queued.
THE CHALLENGE
What the business was up against.
A marine trip has a hard capacity and a fixed departure time. Overselling one is not a billing error to reconcile next month — it is a family turned away at the marina, and a marketplace is blamed by both sides of a booking it brokered.
- Two audiences with opposite needs shared one product: captains running a business — finances, compliance, today’s manifest — and travellers who want to find a boat and pay in under a minute.
- Capacity is perishable. A trip that fills has to leave the customer’s view at once, because a listing that is a few seconds stale is a listing that takes a booking it cannot honour.
- Money had to move through Moyasar under Saudi rules, and a payment that succeeds against a seat that has just gone is worse than a payment that never started.
- Captains take money from the public, so verification could not be a form nobody read — an unverified operator must not be able to appear as a bookable one.
- Arabic is the product’s first language, not a translation layer over an English one: names, marina addresses and free text all had to survive the round trip through the database and back byte for byte.
THE APPROACH
What we built.
One platform behind three front doors: a customer app for discovery and booking, a captain dashboard for the business behind it, and an internal console for the operator. All three are responsive Next.js web apps installable as PWAs rather than native store builds, so one fix reaches every device at once. Sessions come from Supabase Auth with one-time-code sign-in, scheduled jobs on Vercel release unpaid holds and move trips between states without anyone pressing a button, and a single shared client store keeps discovery, seat selection and payment reading the same numbers.
Booking in a single pass
Discovery, seat selection and payment run as one flow over a single shared client store, so the screen never re-renders itself out from under a traveller mid-booking and the seat count cannot disagree with itself between two panels.
The captain’s side of the business
A dashboard that answers the questions an operator actually asks: what is booked today, what has been earned, and what is still to be settled.
Verified operators, settled payments
Accounts are held by Supabase Auth with one-time-code sign-in, KYC gates a captain’s listings rather than trailing behind them, and every booking settles through Moyasar, the licensed Saudi gateway, rather than a payment path built in-house.
An operator console for the platform itself
A private super-admin panel where the platform owners approve KYC submissions, set and adjust commission rates, and reconcile what was collected against what each captain is owed — the work a marketplace has to do on itself, kept off the two public apps.
Work that happens with nobody watching
Scheduled jobs on Vercel expire unpaid holds, so a seat someone stopped paying for returns to inventory instead of sitting reserved, and move trips between states as their departure passes. This is the housekeeping that decides whether availability is still true an hour later.
BUILT WITH
- Next.js (App Router)
- TypeScript
- Tailwind CSS
- PWA (installable web app)
- Prisma
- Supabase (PostgreSQL)
- Supabase Auth (OTP)
- Vercel Cron Jobs
- Vercel Edge Functions
- Moyasar
INSIDE THE SYSTEM
The system itself.
Screens from the running product, not a redesign of it.
Estgmam — Marine Booking Platform
Dashboard overviewScreen 1 of 12
THE OUTCOME
What changed.
The platform now runs both halves of the transaction. Travellers book trips that are genuinely available, and captains can see what they have sold and what they are owed without asking anyone. Because capacity is settled at the source rather than reconciled afterwards, the double booking that a marketplace of this kind usually learns to apologise for does not arise. The architecture is sized for the spikes this market actually has — a holiday weekend, a promoted trip — with rendering that scales out per request and availability resolved against the database rather than a cache that can go stale under load.
Running on spreadsheets that stopped scaling?
That is the problem we solve most often. Tell us where the numbers stop adding up.
Start a conversation