Marketplace

Marketplace Jasa Rumah

Marketplace dua sisi yang mempertemukan pemilik rumah dengan teknisi rumah tangga terverifikasi (AC, ledeng, listrik). Pelanggan dapat mencari penyedia, memesan sesuai jadwal, membayar di dalam aplikasi (dana ditahan hingga pekerjaan selesai), dan memberi rating. Penyedia menerima pesanan, memperbarui status pekerjaan, dan memantau pendapatan. Admin memverifikasi penyedia, mengelola kategori, memantau transaksi, dan menangani sengketa. MVP menargetkan 3 kategori jasa di satu kota pilot dengan alur end-to-end booking -> bayar -> selesai -> ulasan, serta pemotongan komisi otomatis per transaksi.

Pakai template

PRD — Marketplace Jasa Tukang & Teknisi Rumah Tangga On-Demand

Problem

Mencari teknisi rumah tangga yang tepercaya masih mengandalkan rekomendasi mulut ke mulut, nomor WhatsApp acak, dan harga yang tidak transparan. Pelanggan tidak punya jaminan kualitas, kepastian jadwal, atau perlindungan pembayaran. Di sisi lain, tukang/teknisi lepas kesulitan mendapat aliran order yang stabil dan sering kalah bersaing dengan yang punya jaringan luas. Belum ada kanal tunggal yang menyatukan pencarian, penjadwalan, pembayaran aman, dan reputasi berbasis ulasan untuk jasa perbaikan rumah on-demand.

Goals

Meluncurkan MVP marketplace dua sisi untuk 3 kategori jasa (AC, ledeng, listrik) di satu kota pilot.
Menyediakan alur end-to-end yang berfungsi: cari -> booking -> bayar in-app -> pengerjaan -> selesai -> ulasan.
Menahan dana pembayaran (escrow) dan mencairkan ke penyedia setelah pekerjaan selesai, dengan komisi platform terpotong otomatis per transaksi.
Memastikan hanya penyedia terverifikasi admin yang tampil di katalog, untuk menjaga kepercayaan.
Pelanggan dapat menyelesaikan sebuah booking (dari pilih layanan sampai bayar) dalam waktu di bawah 3 menit.
Membangun reputasi berbasis ulasan sehingga rating rata-rata penyedia terlihat jelas sebelum memesan.

Non-Goals

Pelacakan lokasi teknisi secara real-time via GPS di peta.
Fitur chat in-app antara pelanggan dan penyedia (untuk MVP cukup detail kontak & catatan booking).
Aplikasi mobile native (iOS/Android); MVP berupa web responsif/PWA.
Penetapan harga dinamis / surge pricing dan sistem penawaran (bidding).
Program loyalitas, poin, voucher, dan referral.
Penugasan penyedia otomatis berbasis AI/algoritma matching.
Multi-bahasa dan ekspansi multi-kota/multi-negara.
Resolusi sengketa otomatis serta refund otomatis penuh (MVP: penanganan manual oleh admin).
Langganan/membership berbayar untuk penyedia atau pelanggan.
Integrasi akuntansi/pajak (PPN, faktur otomatis) tingkat lanjut.

Target Users

Rina, pemilik rumah (32) di kota besar, sibuk bekerja — Menemukan teknisi AC/ledeng/listrik yang tepercaya dengan cepat, tahu harga di muka, bisa pilih jadwal, dan bayar aman tanpa ribet tawar-menawar atau takut ditipu.
Budi, teknisi AC lepas (38) — Mendapat aliran order tambahan yang stabil, jadwal yang jelas, pembayaran yang pasti masuk, dan reputasi yang bisa dibangun lewat ulasan pelanggan.
Admin operasional platform — Memverifikasi kredibilitas penyedia sebelum tayang, mengelola kategori jasa, memantau transaksi & GMV, serta menangani keluhan/sengketa agar marketplace tetap tepercaya.

User Stories

must-have
Sebagai pelanggan, saya ingin mencari dan memesan teknisi AC terverifikasi untuk tanggal dan jam tertentu, agar AC saya diperbaiki tanpa harus menelepon banyak orang dan tanpa kepastian harga.
must-have
Sebagai pelanggan, saya ingin membayar layanan langsung di dalam aplikasi dengan aman, agar saya tidak perlu menyiapkan uang tunai dan punya bukti pembayaran serta perlindungan bila layanan gagal.
must-have
Sebagai pelanggan, saya ingin memberi rating dan ulasan setelah pekerjaan selesai, agar saya membantu pelanggan lain memilih teknisi yang baik dan mendorong kualitas layanan.
must-have
Sebagai penyedia (teknisi), saya ingin menerima permintaan booking, menyetujui/menolaknya, dan memperbarui status pengerjaan, agar saya bisa mengatur jadwal pekerjaan dan memastikan pembayaran saya diproses.
should-have
Sebagai penyedia (teknisi), saya ingin melihat ringkasan pendapatan saya (tertahan, cair, komisi terpotong), agar saya tahu berapa yang saya hasilkan dan kapan dana cair.
must-have
Sebagai admin, saya ingin memverifikasi penyedia sebelum mereka tayang di katalog, agar pelanggan hanya bertemu teknisi yang kredibel sehingga kepercayaan terhadap platform terjaga.

Features

Registrasi & Autentikasi Multi-Peran

must-have

Pendaftaran dan login untuk tiga peran (pelanggan, penyedia, admin) dengan kontrol akses berbasis peran (RBAC) dan proteksi rute.

Pengguna dapat mendaftar & login via email + password (dan/atau OTP) dalam maksimal 5 langkah.
Sistem mendukung 3 peran (pelanggan, penyedia, admin); peran tersimpan di DB dan menentukan halaman yang bisa diakses.
Rute terproteksi menolak akses tanpa sesi valid dan mengarahkan ke /login; diverifikasi untuk minimal 3 rute (dashboard penyedia, dashboard admin, checkout).
Kredensial dikelola provider auth (hashed); tidak ada password plaintext tersimpan di DB maupun log.
Sesi bertahan setelah refresh halaman dan pengguna dapat logout dengan bersih.

Katalog & Pencarian Jasa

must-have

Halaman jelajah kategori, pencarian, dan filter penyedia beserta halaman detail penyedia.

Menampilkan minimal 3 kategori (AC, Ledeng, Listrik) lengkap dengan ikon dan deskripsi singkat.
Pencarian berdasarkan kata kunci + filter kategori + filter area/kota mengembalikan hasil dalam < 1 detik untuk dataset 500 penyedia.
Setiap kartu penyedia menampilkan nama, rating rata-rata, jumlah ulasan, harga mulai, dan badge terverifikasi.
Hanya penyedia berstatus 'verified' dan 'active' yang muncul di hasil pencarian.
Halaman detail penyedia menampilkan daftar layanan + harga, area layanan, dan 10 ulasan terbaru.

Profil & Verifikasi Penyedia

must-have

Onboarding penyedia untuk mengisi profil dan layanan, serta alur verifikasi oleh admin sebelum tayang.

Penyedia dapat mengisi profil: nama, foto, kategori keahlian, area layanan, deskripsi, daftar layanan + harga, dan unggah dokumen (KTP/sertifikat) ke storage.
Penyedia baru berstatus default 'pending' dan tidak tampil di katalog sampai admin menyetujui.
Admin dapat approve atau reject dengan alasan; status berubah dan penyedia menerima notifikasi hasilnya.
Validasi form berjalan: field wajib tidak boleh kosong dan harga layanan harus > 0.
Dokumen yang diunggah hanya dapat diakses oleh penyedia bersangkutan dan admin (bukan publik).

Booking & Penjadwalan

must-have

Pembuatan pesanan dengan pilihan layanan, jadwal, alamat, dan siklus status pengerjaan.

Pelanggan memilih layanan, tanggal, slot waktu, alamat, dan catatan untuk membuat booking.
Sistem mencegah double-booking slot waktu yang sama untuk penyedia yang sama.
Booking memiliki siklus status: pending -> accepted -> on_the_way -> in_progress -> completed, dengan cabang cancelled; hanya transisi valid yang diizinkan.
Penyedia dapat menyetujui/menolak booking pending; penolakan mengembalikan slot menjadi tersedia.
Pelanggan dan penyedia dapat melihat riwayat dan detail booking masing-masing (terisolasi per pengguna).

Pembayaran In-App, Escrow & Komisi

must-have

Integrasi pembayaran Midtrans dengan penahanan dana (escrow) sampai pekerjaan selesai dan pemotongan komisi otomatis.

Pembayaran diproses via Midtrans Snap dan mendukung minimal Virtual Account, e-wallet, dan kartu.
Setelah pembayaran sukses, dana berstatus 'paid_held' dan baru dapat dicairkan ke penyedia setelah booking 'completed'.
Komisi platform (mis. 15%) dihitung dan dicatat per transaksi di ledger pendapatan.
Webhook Midtrans memverifikasi signature dan pemrosesan bersifat idempoten (satu notifikasi tidak menghasilkan pembaruan status ganda).
Pembatalan sebelum pengerjaan mengubah status pembayaran sesuai kebijakan dan menandai transaksi untuk penanganan refund.

Rating & Ulasan

must-have

Sistem ulasan pasca-layanan yang memengaruhi rating rata-rata penyedia.

Hanya pelanggan dengan booking berstatus 'completed' yang dapat memberi ulasan, dan maksimal satu ulasan per booking.
Rating memakai skala 1-5 dengan komentar opsional dan tersimpan terkait booking + penyedia.
Rating rata-rata dan jumlah ulasan penyedia diperbarui otomatis setelah ulasan baru masuk.
Ulasan tampil di halaman detail penyedia, terurut dari yang terbaru.
Constraint unik mencegah pelanggan mengirim dua ulasan untuk booking yang sama.

Dashboard Penyedia

must-have

Ruang kerja penyedia untuk mengelola pesanan masuk, status pengerjaan, dan ringkasan pendapatan.

Menampilkan daftar booking pending dengan tombol accept/reject.
Menampilkan booking aktif dengan tombol perbarui status (on_the_way / in_progress / completed).
Menampilkan ringkasan pendapatan: total, tertahan (held), sudah cair (released), dan komisi terpotong.
Hanya menampilkan data milik penyedia yang login (isolasi antar penyedia diverifikasi).
Perubahan status oleh penyedia tercermin pada tampilan booking milik pelanggan setelah refresh.

Dashboard Admin

must-have

Panel operasional untuk verifikasi penyedia, pengelolaan kategori, pemantauan transaksi, dan penandaan sengketa.

Menyediakan antrean verifikasi penyedia dengan aksi approve/reject beserta alasan.
Mendukung CRUD kategori jasa (tambah/edit/nonaktif).
Menampilkan tabel semua booking dengan filter status, detail per booking, dan opsi menandai sebagai sengketa.
Menampilkan ringkasan metrik: jumlah booking, GMV, total komisi, dan jumlah penyedia aktif.
Seluruh halaman admin hanya dapat diakses oleh pengguna berperan admin.

Notifikasi Status

should-have

Notifikasi email (dan opsional WhatsApp) pada peristiwa penting booking.

Notifikasi terkirim saat: booking dibuat, disetujui penyedia, ditandai selesai, dan permintaan ulasan.
Isi notifikasi memuat detail booking dan tautan menuju halaman terkait.
Kegagalan pengiriman notifikasi tercatat di log dan tidak menggagalkan transaksi utama (booking/pembayaran tetap tersimpan).

Tech Stack

Frontend: Next.js 14 (App Router) + TypeScript + Tailwind CSS + shadcn/ui; React Hook Form + Zod untuk form dan validasi input.

Backend: Next.js Route Handlers (REST) sebagai lapisan API; logika domain di src/server; Prisma ORM; endpoint webhook untuk Midtrans; validasi payload dengan Zod.

Database: PostgreSQL (Supabase) diakses via Prisma; Supabase Storage untuk foto profil dan dokumen verifikasi.

Hosting: Vercel untuk aplikasi & API; Supabase untuk database/auth/storage; Midtrans untuk pembayaran; Resend untuk email transaksional.

Autentikasi memakai Supabase Auth (email+password/OTP) dengan RBAC 3 peran (pelanggan/penyedia/admin). Stack dipilih karena populer, dokumentasinya melimpah, gratis di tahap awal, dan cepat dieksekusi oleh AI coding agent. Bila skala backend membesar, backend dapat dipisah ke NestJS. Gunakan Prisma migrations untuk skema dan Vercel Cron/queue sederhana bila butuh job async untuk payout.

Tasks (siap kirim ke AI agent)

Inisialisasi proyek & infrastruktur· 1-2 hari

Menyiapkan repositori Next.js dengan TypeScript, Tailwind, shadcn/ui, Prisma, Supabase client, tooling kualitas kode, dan variabel lingkungan.

Lihat isi perintah

Buat proyek Next.js 14 (App Router) + TypeScript bernama marketplace-jasa-rumah dengan `npx create-next-app@latest --ts --tailwind --app --src-dir`. Pasang dan konfigurasikan: shadcn/ui (`npx shadcn@latest init`), Prisma (`npm i -D prisma` + `npm i @prisma/client`), `@supabase/supabase-js`, Zod, React Hook Form. Buat struktur folder: src/app, src/components, src/lib (berisi db.ts sebagai singleton PrismaClient dan supabase.ts sebagai client), src/server (logika domain). Buat file .env.example berisi DATABASE_URL, DIRECT_URL, NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY, SUPABASE_SERVICE_ROLE_KEY, MIDTRANS_SERVER_KEY, NEXT_PUBLIC_MIDTRANS_CLIENT_KEY, RESEND_API_KEY. Konfigurasi ESLint + Prettier dan tambahkan skrip npm: dev, build, lint, typecheck (tsc --noEmit). Pasang Husky pre-commit yang menjalankan lint + typecheck. Definition of Done: `npm run dev` berjalan tanpa error, halaman placeholder di / tampil, `npm run lint` dan `npm run typecheck` lulus, dan README memuat langkah setup env & menjalankan proyek.

Skema database & model data· 1-2 hari· Butuh dulu: T1

Mendefinisikan skema Prisma untuk pengguna, profil penyedia, kategori, layanan, booking, pembayaran, dan ulasan beserta seed data.

Lihat isi perintah

Di prisma/schema.prisma, definisikan model: User (id, email, role enum {CUSTOMER, PROVIDER, ADMIN}, name, phone, createdAt), ProviderProfile (id, userId unik, bio, photoUrl, serviceArea, status enum {PENDING, VERIFIED, REJECTED, SUSPENDED}, avgRating default 0, reviewCount default 0, verifiedAt), ServiceCategory (id, name, slug unik, iconKey, isActive), Service (id, providerId, categoryId, title, description, priceIDR int, durationMinutes), ProviderDocument (id, providerId, type, fileUrl), Booking (id, customerId, providerId, serviceId, scheduledAt, address, notes, status enum {PENDING, ACCEPTED, ON_THE_WAY, IN_PROGRESS, COMPLETED, CANCELLED, REJECTED}, createdAt), Payment (id, bookingId unik, amountIDR, commissionIDR, netToProviderIDR, status enum {PENDING, PAID_HELD, RELEASED, REFUNDED, FAILED}, midtransOrderId unik, rawWebhook Json), Review (id, bookingId unik, customerId, providerId, rating int, comment, createdAt). Tambahkan indeks untuk kolom filter (providerId, categoryId, status) dan unique constraint yang mencegah double-book (providerId + scheduledAt) serta satu review per booking. Buat prisma/seed.ts yang mengisi 3 kategori (AC, Ledeng, Listrik), 1 admin, 5 penyedia VERIFIED dengan beberapa Service, dan beberapa Booking contoh. Definition of Done: `npx prisma migrate dev` sukses membuat tabel, `npx prisma db seed` mengisi data, dan `npx prisma studio` menampilkan seluruh relasi dengan benar.

Autentikasi & kontrol akses berbasis peran· 2 hari· Butuh dulu: T2

Mengimplementasikan registrasi/login via Supabase Auth, sinkronisasi user ke DB, serta proteksi rute per peran.

Lihat isi perintah

Implementasikan auth memakai Supabase Auth. Buat halaman src/app/(auth)/login dan src/app/(auth)/register dengan React Hook Form + Zod (email, password, pilih peran CUSTOMER atau PROVIDER saat register; ADMIN dibuat manual/seed). Setelah signup di Supabase, buat/sinkronkan record User di tabel Prisma beserta role. Buat helper src/server/auth.ts: getSession(), requireUser(), dan requireRole(role) yang dipakai di Route Handlers dan Server Components. Buat middleware.ts yang memproteksi /dashboard/provider (hanya PROVIDER), /dashboard/admin (hanya ADMIN), dan /checkout (harus login); jika tidak berhak redirect ke /login. Sediakan tombol Logout. Definition of Done: bisa register+login sebagai pelanggan dan penyedia, sesi bertahan setelah refresh, akses ke 3 rute terproteksi ditolak untuk peran yang salah (redirect ke /login), tidak ada password plaintext di DB/log, dan `npm run typecheck` lulus.

Onboarding profil penyedia & verifikasi· 2-3 hari· Butuh dulu: T3

Form pengisian profil dan layanan penyedia, unggah dokumen, serta status verifikasi yang menentukan visibilitas di katalog.

Lihat isi perintah

Buat alur onboarding penyedia di src/app/dashboard/provider/profile menggunakan React Hook Form + Zod: field nama, bio, foto, area layanan, kategori keahlian, dan daftar Service (title, description, priceIDR, durationMinutes) yang bisa ditambah/hapus dinamis. Implementasikan unggah foto & dokumen ke Supabase Storage (bucket privat untuk dokumen KTP/sertifikat), simpan URL ke ProviderDocument. Buat Route Handlers di src/app/api/provider/profile (GET/PUT) dan src/app/api/provider/services (POST/DELETE) yang memanggil helper requireRole('PROVIDER'). Penyedia baru berstatus PENDING dan tidak tampil di katalog. Buat komponen ProviderStatusBanner yang menampilkan status verifikasi (pending/rejected+alasan/verified). Definition of Done: penyedia dapat menyimpan profil + minimal 1 layanan (validasi harga > 0 dan field wajib terisi), dokumen tersimpan di bucket privat (tidak dapat diakses publik), status default PENDING, dan `npm run typecheck` lulus.

Katalog, pencarian & halaman detail penyedia· 2-3 hari· Butuh dulu: T2, T3

Halaman publik untuk menjelajah kategori, mencari & memfilter penyedia, dan melihat detail penyedia beserta ulasan.

Lihat isi perintah

Bangun halaman katalog publik. src/app/page.tsx menampilkan 3 kategori (AC, Ledeng, Listrik) dengan ikon & deskripsi. src/app/search menampilkan daftar penyedia dengan input pencarian kata kunci + filter kategori + filter area, dipanggil via Route Handler src/app/api/search yang melakukan query Prisma HANYA untuk penyedia status VERIFIED (server-side filtering + pagination). Buat komponen ProviderCard (nama, avgRating, reviewCount, harga mulai, badge Terverifikasi). Buat halaman detail src/app/providers/[id] yang menampilkan daftar layanan + harga, area layanan, dan 10 ulasan terbaru (terurut createdAt desc), plus tombol 'Pesan' menuju alur booking. Definition of Done: pencarian mengembalikan hasil terfilter dengan benar (uji dengan data seed 500 penyedia; respons < 1 detik), penyedia PENDING/REJECTED tidak pernah muncul, halaman detail menampilkan layanan & ulasan sesuai data, dan layout responsif di mobile & desktop.

Alur booking & siklus status· 3 hari· Butuh dulu: T5

Pembuatan booking dengan penjadwalan dan alamat, pencegahan double-book, serta manajemen transisi status.

Lihat isi perintah

Implementasikan alur booking. Buat src/app/booking/[serviceId] dengan form pilih tanggal + slot waktu (date/time picker), alamat, catatan (React Hook Form + Zod). Route Handler POST src/app/api/bookings membuat Booking status PENDING setelah requireRole('CUSTOMER'); di dalam transaksi Prisma, tolak jika sudah ada booking pada providerId + scheduledAt yang sama (cegah double-book) dan kembalikan error 409. Buat src/server/booking.ts berisi state machine dengan fungsi transition(bookingId, nextStatus) yang HANYA mengizinkan transisi valid: PENDING->ACCEPTED/REJECTED/CANCELLED, ACCEPTED->ON_THE_WAY/CANCELLED, ON_THE_WAY->IN_PROGRESS, IN_PROGRESS->COMPLETED. Endpoint PATCH src/app/api/bookings/[id]/status memakai fungsi ini dengan otorisasi peran (penyedia mengubah status pengerjaan, pelanggan/penyedia dapat cancel sesuai aturan). Buat halaman riwayat src/app/dashboard/bookings yang menampilkan booking milik pengguna yang login saja. Definition of Done: booking tercipta dengan status PENDING, double-book slot yang sama ditolak (uji dua request), transisi status ilegal ditolak dengan error jelas, reject/cancel mengembalikan ketersediaan slot, dan pelanggan hanya melihat booking miliknya.

Integrasi pembayaran Midtrans, escrow & komisi· 3 hari· Butuh dulu: T6

Checkout via Midtrans Snap, penahanan dana hingga selesai, webhook idempoten, dan pencatatan komisi/ledger.

Lihat isi perintah

Integrasikan pembayaran Midtrans Snap. Buat Route Handler POST src/app/api/payments/checkout yang membuat record Payment (status PENDING, hitung amountIDR, commissionIDR = 15% dibulatkan, netToProviderIDR = amount - komisi) dan memanggil Midtrans Snap API untuk mendapatkan snap token; kembalikan token ke frontend. Di halaman checkout, muat Snap.js dengan NEXT_PUBLIC_MIDTRANS_CLIENT_KEY dan buka popup pembayaran. Buat webhook POST src/app/api/payments/webhook yang: (1) memverifikasi signature_key Midtrans (SHA512 dari order_id+status_code+gross_amount+server_key), (2) bersifat idempoten (abaikan notifikasi untuk Payment yang statusnya sudah final), (3) saat settlement/capture ubah status Payment ke PAID_HELD dan simpan rawWebhook. Tambahkan fungsi src/server/payout.ts releaseFunds(bookingId) yang hanya berjalan saat Booking COMPLETED: set Payment ke RELEASED dan catat entri di ledger pendapatan (buat model/tabel PayoutLedger jika perlu di migrasi). Definition of Done: pembayaran uji (sandbox) untuk minimal VA & e-wallet berhasil dan mengubah Payment ke PAID_HELD, webhook dengan signature salah ditolak, notifikasi duplikat tidak menggandakan status, dan komisi tercatat benar per transaksi.

Sistem rating & ulasan· 1-2 hari· Butuh dulu: T6

Pengiriman ulasan pasca-layanan oleh pelanggan dan pembaruan agregat rating penyedia.

Lihat isi perintah

Implementasikan ulasan. Buat komponen ReviewForm (rating bintang 1-5 + komentar opsional) yang tampil di halaman detail booking pelanggan HANYA jika status booking COMPLETED. Route Handler POST src/app/api/reviews memvalidasi (requireRole('CUSTOMER'), booking milik pelanggan, status COMPLETED, belum pernah diulas) lalu membuat Review; dalam transaksi Prisma perbarui ProviderProfile.avgRating dan reviewCount (hitung ulang dari agregat Review). Manfaatkan unique constraint bookingId pada Review untuk mencegah ulasan ganda dan tangani error-nya dengan pesan yang jelas. Tampilkan ulasan terbaru di halaman detail penyedia (dari T5). Definition of Done: hanya booking COMPLETED yang bisa diulas, upaya ulasan kedua untuk booking sama ditolak, avgRating & reviewCount penyedia diperbarui otomatis dan akurat, serta ulasan baru muncul di halaman detail penyedia.

Dashboard penyedia (pesanan & pendapatan)· 2 hari· Butuh dulu: T6, T7

Antarmuka penyedia untuk mengelola booking masuk/aktif dan melihat ringkasan pendapatan.

Lihat isi perintah

Bangun dashboard penyedia di src/app/dashboard/provider. Buat tab/bagian: (1) Booking Masuk = daftar booking PENDING dengan tombol Terima/Tolak yang memanggil PATCH /api/bookings/[id]/status. (2) Pekerjaan Aktif = booking ACCEPTED/ON_THE_WAY/IN_PROGRESS dengan tombol perbarui status sesuai state machine (T6). (3) Pendapatan = ringkasan total, tertahan (Payment PAID_HELD), sudah cair (RELEASED), dan total komisi terpotong, dihitung via Route Handler src/app/api/provider/earnings yang mengagregasi Payment milik penyedia. Semua query WAJIB difilter berdasarkan providerId dari sesi (requireRole('PROVIDER')) sehingga penyedia tidak dapat melihat data penyedia lain. Definition of Done: penyedia dapat menerima/menolak dan memperbarui status booking dari dashboard, angka pendapatan sesuai data Payment, isolasi antar penyedia terverifikasi (uji dengan dua akun penyedia), dan perubahan status terlihat pada sisi pelanggan setelah refresh.

T10

Dashboard admin (verifikasi, kategori, monitoring)· 2-3 hari· Butuh dulu: T4, T7

Panel admin untuk verifikasi penyedia, kelola kategori, memantau booking/transaksi, dan menandai sengketa.

Lihat isi perintah

Bangun dashboard admin di src/app/dashboard/admin (dilindungi requireRole('ADMIN')). Bagian: (1) Verifikasi Penyedia = antrean ProviderProfile status PENDING dengan pratinjau dokumen dan tombol Approve/Reject (reject wajib menyertakan alasan); aksi memanggil Route Handler yang mengubah status dan memicu notifikasi (integrasi dengan modul notifikasi bila ada). (2) Kategori = CRUD ServiceCategory (tambah/edit/nonaktifkan). (3) Booking = tabel semua booking dengan filter status, detail per baris, dan tombol Tandai Sengketa. (4) Metrik = ringkasan jumlah booking, GMV (total amountIDR PAID_HELD+RELEASED), total komisi, dan jumlah penyedia aktif, via Route Handler src/app/api/admin/metrics. Definition of Done: admin dapat approve/reject penyedia (status berubah & penyedia jadi tayang setelah approve), CRUD kategori berfungsi, tabel booking dapat difilter dan ditandai sengketa, metrik menampilkan angka yang benar dari data, dan semua endpoint admin menolak akses non-admin.

Risks

Masalah likuiditas dua sisi (chicken-and-egg): tanpa cukup penyedia terverifikasi, pelanggan tidak mendapat pilihan; tanpa cukup pelanggan, penyedia tidak aktif. Mitigasi: fokus 1 kota pilot & rekrut penyedia awal secara manual.
Keandalan penyedia (no-show, kualitas pekerjaan buruk) merusak kepercayaan. Mitigasi: verifikasi admin, sistem rating, dan penahanan dana sampai selesai.
Kepatuhan & keamanan pembayaran (PCI). Mitigasi: gunakan Midtrans hosted/Snap sehingga data kartu tidak menyentuh server sendiri; verifikasi signature webhook.
Sengketa & refund yang rumit pada MVP ditangani manual, berisiko lambat. Mitigasi: SOP admin jelas + status pembayaran PAID_HELD sebagai buffer sebelum pencairan.
Kepercayaan & keselamatan: teknisi masuk ke rumah pelanggan. Mitigasi: verifikasi identitas/dokumen penyedia dan riwayat ulasan.
Kebocoran data dokumen sensitif (KTP) bila bucket salah konfigurasi. Mitigasi: bucket privat + akses terbatas admin/pemilik, tanpa URL publik.
Aspek pajak/regulasi (PPN, status pekerja) belum ditangani di MVP dan bisa jadi kewajiban hukum. Mitigasi: konsultasi legal sebelum skala.

Open Questions

Model komisi: persentase dipotong dari penyedia, ditambahkan sebagai biaya layanan ke pelanggan, atau kombinasi keduanya, dan berapa besarannya?
Kota pilot mana yang akan dipakai untuk peluncuran pertama?
Apakah harga layanan bersifat tetap di depan, atau perlu survei/estimasi terlebih dulu untuk pekerjaan tertentu?
Bagaimana kebijakan pembatalan & refund (tenggat pembatalan gratis, potongan, siapa menanggung biaya)?
Jadwal pencairan dana ke penyedia: instan setelah selesai, harian, atau mingguan?
Sejauh mana kedalaman KYC/verifikasi identitas penyedia yang diperlukan sejak MVP (KTP saja atau plus sertifikasi keahlian)?
Apakah notifikasi WhatsApp diperlukan sejak MVP atau cukup email dulu, mengingat biaya & integrasi gateway WA?