Di Balik Layar Zasha: Pelajaran Coding dari Membangun Marketplace Jasa Lokal

Membangun sebuah platform marketplace dari nol bukan pekerjaan satu malam. Zasha.online — platform jasa lokal yang menghubungkan mitra dan pelanggan — sudah berjalan lebih dari tujuh bulan pengembangan, dan sepanjang perjalanan itu ada banyak pelajaran teknis yang layak dibagikan. Artikel ini merangkum pengalaman coding di balik Zasha: pilihan teknologi, tantangan yang muncul, dan cara menyelesaikannya.

Memilih Stack yang Tepat

Zasha dibangun di atas fondasi yang sederhana tapi solid: PHP 8.2 dengan Laravel 12 sebagai backend, Filament v3 untuk admin panel, dan Flutter untuk aplikasi mobile mitra maupun pelanggan.

Kenapa Laravel? Karena untuk marketplace dengan banyak modul — jastip, jasa tenaga, sampai PPOB — kecepatan pengembangan lebih penting daripada mengejar teknologi yang sedang tren. Laravel menyediakan hampir semua kebutuhan dasar: autentikasi, queue, event broadcasting, sampai validasi. Filament melengkapinya dengan admin panel yang bisa dibangun dalam hitungan jam, bukan minggu.

Flutter dipilih karena satu codebase bisa menghasilkan aplikasi Android sekaligus iOS. Untuk tim kecil, ini penghematan waktu yang sangat besar.

Tiga Jenis Pengguna, Tiga Cara Berpikir

Salah satu tantangan terbesar Zasha adalah melayani tiga jenis pengguna sekaligus: pelanggan yang memesan jasa, mitra yang mengerjakan pesanan, dan admin yang mengawasi semuanya. Ketiganya punya kebutuhan berbeda.

Pelanggan butuh proses pemesanan yang cepat dan jelas. Mitra butuh notifikasi order masuk yang real-time — karena setiap detik keterlambatan berarti potensi kehilangan penghasilan. Admin butuh visibilitas penuh: siapa order apa, saldo siapa yang bergerak, dan transaksi mana yang bermasalah.

Pelajarannya: jangan mendesain satu alur untuk semua. Setiap tipe pengguna perlu dipikirkan sebagai produk tersendiri, meskipun berbagi satu database.

Real-Time Itu Mahal, Kalau Salah Arsitektur

Fitur real-time adalah nyawa marketplace jasa. Ketika pelanggan membuat order, mitra harus tahu detik itu juga. Ketika mitra menerima tawaran, pelanggan harus langsung melihat statusnya berubah.

Awalnya semua terasa sederhana: pakai satu layanan broadcasting untuk semuanya. Tapi kenyataannya, layanan pihak ketiga seperti Pusher Cloud dihitung per pesan — dan event order yang frekuensinya tinggi bisa membuat tagihan membengkak.

Solusinya: pisahkan jalur. Event order dan transaksi berjalan lewat Laravel Reverb yang di-hosting sendiri, sementara Pusher Cloud hanya dipakai untuk chat. Sebagai jaring pengaman, ada polling setiap 30 detik kalau koneksi WebSocket terputus. Arsitektur ini menurunkan biaya sekaligus menjaga keandalan.

Pelajarannya: sebelum memakai layanan berbayar per-request, hitung dulu frekuensi event-nya. Yang murah di awal bisa jadi mahal di skala.

Escrow: Kepercayaan Dibangun Lewat Kode

Marketplace jasa hidup dari kepercayaan. Pelanggan takut uangnya hilang, mitra takut kerjanya tidak dibayar. Jawabannya adalah sistem escrow: saldo pelanggan ditahan saat order dibuat, dan baru dilepas ke mitra setelah pekerjaan selesai.

Implementasinya menuntut kedisiplinan tinggi di level kode. Setiap pergerakan saldo harus tercatat sebagai transaksi yang bisa diaudit — komisi tercatat sebagai pengurangan, top-up sebagai penambahan, semuanya dalam satu tabel mutasi yang konsisten. Satu bug kecil di logika saldo bisa berarti kehilangan uang sungguhan, bukan sekadar error di layar.

Bug Adalah Guru Terbaik

Tujuh bulan pengembangan berarti tujuh bulan bertemu bug. Beberapa yang paling berkesan:

Order yang "menggantung" di status menunggu karena event penolakan tidak terkirim — mengajarkan pentingnya memastikan setiap perubahan status punya event yang benar-benar ter-broadcast, bukan sekadar tersimpan di database.

Tombol yang tidak terlihat karena warnanya menyatu dengan latar — mengingatkan bahwa testing di device asli dengan berbagai kondisi layar itu wajib, bukan opsional.

Karakter yang tampil rusak (mojibake) — pelajaran klasik tentang konsistensi encoding UTF-8 dari database sampai ke tampilan aplikasi.

Untuk melacak semua ini, Zasha punya sistem dokumentasi error internal sendiri. Setiap error yang muncul di production dicatat, didokumentasikan penyebab dan solusinya, sehingga bug yang sama tidak perlu diselesaikan dua kali.

Workflow: Diskusi Dulu, Baru Eksekusi

Satu kebiasaan yang terbukti menghemat banyak waktu: memisahkan fase berpikir dari fase mengetik kode. Setiap fitur atau perbaikan didiskusikan dulu — apa masalahnya, apa opsinya, apa trade-off-nya — baru setelah keputusan jelas, eksekusi dilakukan. AI coding assistant membantu mempercepat eksekusi, tapi keputusan arsitektur tetap harus lahir dari pemahaman manusia terhadap bisnisnya.

Menulis kode itu cepat. Menghapus kode yang salah arah jauh lebih lambat.

Penutup

Membangun Zasha mengajarkan satu hal besar: marketplace bukan soal fitur yang banyak, tapi soal alur yang bisa dipercaya. Uang harus bergerak dengan benar, notifikasi harus sampai tepat waktu, dan setiap bug harus jadi dokumentasi agar tidak terulang.

Perjalanan Zasha masih panjang. Tapi setiap baris kode yang ditulis hari ini adalah fondasi untuk platform jasa lokal yang lebih matang besok.