Islamic Services Marketplace
A multi-service marketplace connecting clients with vetted practitioners for Hijama, Ruqya, Quran tutoring, and more. Built for a group launching a UK-based platform.
What this is
A marketplace platform where clients find and book vetted practitioners offering Hijama (cupping therapy), Ruqya (Islamic spiritual healing), Quran and Arabic tutoring, massage, and other Islamic services. Practitioners apply, get vetted by the platform team, and manage their own profiles and bookings. The platform takes a configurable commission per booking.
Started as a single-practitioner Hijama booking site and evolved into a full marketplace. The original 73-session codebase (security hardening, booking engine, GDPR compliance, Stripe integration) became the foundation for the pivot.
How it’s built
Next.js 15 with App Router and Server Components. Drizzle ORM on Neon Postgres (Frankfurt, EU) for GDPR data residency. Stripe for payments (moving to Stripe Connect Express for practitioner payouts). Resend for transactional email. Service categories are admin-managed rows in a database table, so adding “Islamic Marriage Counselling” is a data operation, not a code deploy.
The booking flow is category-first: pick a service → filter practitioners by location, language, gender, online availability → choose a time → confirm. Online sessions (tutoring, Ruqya) use the same booking engine with a video link instead of a physical address. Child safeguarding (DBS checks, parental consent) is built into the flow for tutoring categories.
206 tests (180 unit + 26 Playwright E2E) across the full stack. Production build verified. Security audited.
What I learned
A marketplace is a trust problem, not a booking problem. The booking engine was the easy part; I’d already built it. What made the pivot hard was designing trust: how do clients know a practitioner is qualified? How do you handle DBS checks for tutors working with children? How do you split payments legally? Every design decision is really a trust decision in disguise.
Flexible categories beat fixed enums. I started with a Postgres enum for three service types. Research on 20+ competitor platforms showed that practitioners define what they offer. You can’t predict the categories. A table with metadata per category (requires intake form? DBS check? online-eligible?) is more work upfront but means the business can grow without engineering.
The UK compliance bar is higher than you expect. Health data (Hijama intake forms) and religious beliefs (Ruqya) are “special category data” under UK GDPR. Children’s data (tutoring) adds DBS requirements. A marketplace acting as data controller needs Article 28 processor agreements with every practitioner. None of this is optional. I wrote the legal templates and safeguarding policy from ICO guidance and statutory requirements.
Status
Feature-complete. Pending: brand name, domain, Neon DB provisioning, Stripe live keys, practitioner profiles, solicitor review of legal docs.