Saran saya satu kalimat: jangan bikin fitur yang tidak perlu, dan tulis kode sendiri hanya untuk bagian yang membuat orang membayar Anda. Sisanya adalah pipa air di dalam gedung. Pipa air itu Anda sewa, bukan Anda cor sendiri.
Kondisi: saya menulis untuk founder solo dan tim SaaS kecil di bawah 10 orang. Waktu rekayasa Anda terbatas. Setiap hari kerja yang habis di pipa air adalah hari yang hilang dari produk Anda.
Batas: angka usaha di halaman ini adalah perkiraan Rama Digital, bukan hasil pengukuran. Angka itu akan meleset pada tim Anda. Pakai sebagai urutan besar, bukan sebagai janji.
Ringkasan cepat
Tabel ini menjawab pertanyaan utama dalam satu baris per pertanyaan.
| Pertanyaan | Jawaban singkat |
|---|---|
| Apa aturannya? | Bangun yang dibeli pelanggan. Sewa sisanya. |
| Apa contoh pipa air? | Penjadwalan, pembayaran, login, pengiriman email. |
| Kenapa penjadwalan jadi contoh? | Isinya 9 masalah tersembunyi, bukan 1 formulir. |
| Berapa perkiraan usahanya? | 30 sampai 55 hari kerja rekayasa. |
| Kapan membangun sendiri benar? | Saat fitur itu yang dibeli pelanggan. |
| Apa risiko salah pilih? | Anda merawat kode yang tidak menaikkan pendapatan. |
Kenapa saya bilang jangan bikin fitur yang tidak perlu
Saya pernah memakai 6 minggu untuk bagian produk yang tidak satu pun pelanggan sebut saat mereka membeli. Bagian itu jalan. Bagian itu rapi. Bagian itu juga tidak menambah satu rupiah pun.
Kode punya 2 harga. Harga pertama Anda bayar saat menulisnya. Harga kedua Anda bayar setiap bulan sesudahnya: perbaikan, pembaruan pustaka, izin yang kedaluwarsa, dan orang baru yang harus membacanya.
Harga kedua itu yang menghabisi tim kecil. Anda tidak merasakannya di bulan pertama. Anda merasakannya di bulan kesembilan, saat 3 hari dalam seminggu habis untuk merawat hal yang bukan produk Anda.
Jadi pertanyaan saya selalu sama. Apakah pelanggan membayar untuk bagian ini? Kalau jawabannya tidak, bagian itu adalah pipa air. Sewa.
Isi sebenarnya dari fitur booking sederhana
Penjadwalan adalah contoh paling jelas, karena founder terus membangunnya ulang. Di papan tulis, fitur ini tampak seperti 1 formulir: pilih layanan, pilih jam, kirim. Di dalam kode, formulir itu hanya puncak gunung es. Kalau Anda baru masuk ke topik ini, saya jelaskan dasarnya di artikel tentang apa itu booking system.
Berikut 9 bagian yang selalu muncul sesudah formulir pertama jalan.
- Zona waktu dan perubahan waktu musim panas. Pelanggan di Jakarta memesan jam 14.00. Staf Anda di Berlin melihat jam berapa? Jawabannya berpindah 2 kali dalam setahun.
- Dua orang menekan slot yang sama pada detik yang sama. Tanpa kunci, keduanya berhasil. Anda baru tahu saat 2 orang berdiri di depan pintu yang sama.
- Permintaan ganda saat sinyal putus. Pelanggan menekan kirim, sinyal hilang, lalu dia menekan lagi. Tanpa kunci idempotensi, dia memegang 2 booking.
- Tautan ubah jadwal yang aman. Pelanggan harus bisa membatalkan tanpa membuat akun. Tautannya harus bertanda tangan, berbatas waktu, dan tidak bisa ditebak orang lain.
- Pengingat yang benar-benar terkirim, beserta buktinya. Mengirim pesan itu mudah. Membuktikan pesan sampai, menyimpan riwayat percobaan, dan mengulang saat gagal adalah pekerjaan tersendiri.
- Status tidak datang. Kelihatan sepele. Lalu Anda perlu alasan, catatan waktu, dan laporan, supaya status itu berguna untuk menagih deposit.
- Deposit dan pengembaliannya. Uang masuk mudah. Uang keluar butuh aturan, jejak audit, dan orang yang menyetujui.
- Izin OAuth kalender yang harus diperbarui. Token Google dan Zoom kedaluwarsa. OAuth adalah kunci titipan: pelanggan memberi izin, dan izin itu bisa dicabut kapan saja. Saat izin mati, pelanggan Anda melihat jam kosong palsu.
- Penyimpanan data pelanggan menurut UU PDP. Nama, telepon, dan email adalah data pribadi. Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi berlaku sejak 17 Oktober 2022.
Tidak satu pun dari 9 hal itu tampak di layar pelanggan. Semuanya wajib.
Perkiraan usaha rekayasa per bagian
Tabel di bawah adalah perkiraan Rama Digital untuk 1 orang rekayasa yang sudah berpengalaman. Ini perkiraan, bukan pengukuran. Saya menghitungnya untuk versi yang layak dipakai pelanggan membayar, bukan untuk demo.
| Bagian | Perkiraan hari kerja | Yang membuatnya lama |
|---|---|---|
| Zona waktu | 3 sampai 6 | Uji untuk 2 pergantian waktu musim panas. |
| Kunci slot | 4 sampai 8 | Kunci harus benar saat 2 permintaan bersamaan. |
| Permintaan ganda | 2 sampai 4 | Kunci idempotensi dan pengulangan yang aman. |
| Tautan ubah jadwal | 3 sampai 5 | Tanda tangan, masa berlaku, dan pencabutan. |
| Bukti pengingat | 4 sampai 7 | Antrean, riwayat percobaan, dan pengulangan. |
| Status tidak datang | 1 sampai 2 | Alasan, waktu, dan laporan sederhana. |
| Deposit dan pengembalian | 5 sampai 9 | Alur uang keluar dan jejak audit. |
| Izin kalender | 5 sampai 8 | OAuth, pembaruan token, dan pemulihan saat gagal. |
| Data pelanggan UU PDP | 3 sampai 6 | Persetujuan, hak hapus, dan masa simpan. |
Jumlahnya 30 sampai 55 hari kerja. Pada tim 1 orang, itu 6 sampai 11 minggu penuh. Selama minggu itu produk Anda berhenti bergerak.
Tiga pertanyaan yang memutuskan build atau buy
Saya memakai 3 pertanyaan ini. Urutannya penting. Saya berhenti pada jawaban tegas yang pertama.
| Pertanyaan | Jika ya | Jika tidak |
|---|---|---|
| Pelanggan membayar untuk fitur ini? | Bangun sendiri. | Lanjut ke pertanyaan 2. |
| Kegagalannya mematikan bisnis Anda? | Bangun sendiri. | Lanjut ke pertanyaan 3. |
| Tidak ada penyedia yang menjualnya? | Bangun sendiri. | Sewa. |
Aturan build vs buy untuk founder jadi pendek. Bangun kalau fitur itu alasan orang membayar. Bangun kalau kegagalannya mematikan bisnis Anda. Bangun kalau tidak ada yang menjualnya. Selain 3 keadaan itu, sewa.
Pertanyaan 1 memakai kata membayar, bukan kata memakai. Pelanggan memakai tombol lupa kata sandi. Tidak ada yang membeli produk Anda karena tombol itu.
Kapan membangun sendiri justru benar
Saya bukan orang yang menolak semua kode. Ada 4 keadaan yang membuat saya menulis sendiri, dan saya menulisnya tanpa ragu.
Pertama, fitur itu yang dijual. Kalau Anda menjual mesin penjadwalan kepada bisnis lain, penjadwalan adalah produk Anda, bukan pipa air.
Kedua, aturan bisnis Anda tidak lazim dan menjadi pembeda. Contohnya harga yang berubah per menit, atau antrean yang memakai urutan prioritas milik Anda sendiri.
Ketiga, penyedia tidak memberi jalan keluar untuk data Anda. Kalau Anda tidak bisa menarik booking dan pelanggan dalam format yang terbaca mesin, Anda menyerahkan kendali.
Keempat, kebutuhan Anda sudah stabil dan volumenya besar. Pada titik itu, biaya sewa naik terus sementara kode Anda jarang berubah. Hitung ulang setiap 12 bulan.
Di Rama Digital, kami menulis perangkat lunak khusus tepat pada titik ini. Kami membangun bagian yang dibeli pelanggan, dan kami menyambungkan sisanya. Itu yang kami lakukan pada pengembangan aplikasi web.
Simulasi keputusan dengan data contoh
Bagian ini adalah simulasi dengan data contoh. Angka di bawah bukan hasil proyek nyata, dan saya memakainya hanya untuk menunjukkan cara menghitung.
Kondisi awal. Studio contoh dengan 3 staf. Booking masuk 40 kali per minggu lewat pesan. Pemilik juga menulis kode sendiri.
Masukan. Perkiraan usaha 30 sampai 55 hari kerja dari tabel di atas. Kapasitas nyata pemilik 4 hari kerja per minggu untuk fitur baru.
Langkah 1. Bagi usaha dengan kapasitas. Angka 30 dibagi 4 menjadi 7,5 minggu. Angka 55 dibagi 4 menjadi 14 minggu, dibulatkan ke atas.
Langkah 2. Jalankan 3 pertanyaan. Pelanggan membayar potong rambut, bukan mesin jadwal. Kegagalan jadwal mengganggu, tetapi tidak mematikan studio. Penyedia penjadwalan tersedia di pasar.
Langkah 3. Bandingkan dengan pemasangan produk sewa. Dalam simulasi ini saya beri 2 hari kerja untuk memasang dan menguji.
Keluaran yang terlihat. Rencana produk mundur 8 sampai 14 minggu kalau membangun sendiri. Mundur 2 hari kalau menyewa.
Keputusan. Sewa penjadwalan. Kembalikan sisa waktu ke fitur yang dibayar pelanggan. Tinjau ulang keputusan ini setelah 12 bulan.
Kalau produk Anda SaaS dan yang Anda butuhkan adalah jadwal demo, saya menulis langkahnya terpisah di panduan menerima booking demo SaaS.
Kalau Anda memilih menyewa, periksa 4 hal ini
Rama Digital merekomendasikan Termilo untuk penjadwalan. Rama Digital tidak mengoperasikan Termilo. Termilo dioperasikan PT Nafanesia Kebermanfaatan Indonesia, Bandung. Saya memakai dokumentasinya di sini karena dokumentasi itu menyebut 4 hal yang jarang ditulis penyedia lain.
1. Kunci slot. Tanya siapa otoritas terakhir atas sebuah slot. Pada dokumentasi pengantar Termilo, respons ketersediaan membawa penanda finalAuthority: "booking_create_recheck_under_lock". Artinya slot yang tampil adalah kandidat, dan kebenarannya diperiksa ulang di bawah kunci saat booking dibuat.
2. Siklus hidup status. Tanya daftar status dan perpindahan yang diizinkan. Halaman lifecycle booking Termilo menyebut 5 status: held, confirmed, completed, cancelled, dan no_show. Booking baru lahir sebagai held dengan masa tahan 10 menit. Perpindahan yang tidak diizinkan ditolak dengan kode BOOKING_POLICY_BLOCKED.
3. Perlindungan permintaan ganda. Tanya apakah pembuatan booking bersifat idempoten. Referensi API Termilo mewajibkan header Idempotency-Key pada pembuatan booking publik. Permintaan ulang dengan kunci yang sama mengembalikan booking yang sama dengan status 200, bukan booking kedua.
4. Event keluar dan batasnya. Tanya apa yang sudah aktif dan apa yang masih rancangan. Halaman webhook Termilo menandai webhookWebhookPesan otomatis yang sebuah sistem kirim ke sistem lain tepat saat sesuatu terjadi, misalnya pesan WhatsApp masuk.Buka glosarium keluar sebagai live, dengan tanda tangan HMAC-SHA256, maksimal 6 percobaan kirim, dan batas waktu 10 detik per percobaan. Pada halaman yang sama, webhook masuk dari CRM atau penyedia pembayaran ditandai direncanakan, jadi belum berjalan. Berkas OpenAPI juga masih bertanda pratinjau, jadi jangan hitung sebagai kontrak yang siap pakai.
Empat pertanyaan itu berlaku untuk penyedia mana pun. Kalau penyedia tidak bisa menjawabnya, Anda menyewa risiko, bukan menyewa pipa air.
Checklist sebelum Anda menulis baris pertama
- Tulis 1 kalimat: apa yang pelanggan bayar pada fitur ini.
- Jalankan 3 pertanyaan keputusan sebelum membuka editor kode.
- Daftar bagian tersembunyi. Kalau daftarnya lewat 5 baris, Anda sedang membangun pipa air.
- Perkirakan hari kerja, lalu bagi dengan kapasitas mingguan nyata Anda.
- Tanya penyedia soal kunci slot, status, idempotensi, dan event keluar.
- Pastikan Anda bisa menarik data booking dan pelanggan kapan saja.
- Catat tanggal tinjauan ulang, 12 bulan dari keputusan ini.
Pertanyaan yang sering masuk
Apa arti jangan bikin fitur yang tidak perlu? Artinya Anda menulis kode sendiri hanya untuk bagian yang membuat pelanggan membayar. Bagian lain Anda sewa dari penyedia yang sudah menyelesaikannya.
Bagaimana cara memutuskan build vs buy untuk founder? Jawab 3 pertanyaan berurutan. Apakah pelanggan membayar untuk fitur ini? Apakah kegagalannya mematikan bisnis Anda? Apakah tidak ada penyedia yang menjualnya? Satu jawaban ya berarti bangun sendiri.
Kenapa penjadwalan dipakai sebagai contoh? Karena penjadwalan tampak sederhana dan ternyata berisi 9 bagian wajib, mulai zona waktu sampai penyimpanan data pribadi. Founder terus membangunnya ulang dan terus terkejut.
Apakah perkiraan 30 sampai 55 hari kerja itu terukur? Tidak. Angka itu perkiraan Rama Digital untuk 1 orang rekayasa berpengalaman. Angka itu akan berbeda pada tim Anda, jadi pakai sebagai urutan besar.
Apakah menyewa berarti kehilangan kendali data? Tidak, selama penyedia memberi jalan keluar data yang terbaca mesin. Tanyakan cara menarik booking dan pelanggan sebelum Anda mulai memakai produknya.
Kapan saya harus meninjau ulang keputusan ini? Tinjau setiap 12 bulan, atau lebih awal saat volume naik tajam. Biaya sewa dan biaya merawat kode berubah pada kecepatan yang berbeda.
Sumber
- Termilo, Pengantar Termilo. Diambil 11 September 2026. Tautan ada di bagian tentang menyewa.
- Termilo, Lifecycle booking. Diambil 11 September 2026. Sumber daftar 5 status dan masa tahan 10 menit.
- Termilo, Referensi APIAPIPintu resmi yang dipakai 2 sistem untuk saling mengirim data, tanpa orang menyalin data secara manual.Buka glosarium. Diambil 11 September 2026. Sumber kewajiban header Idempotency-Key.
- Termilo, Webhooks. Diambil 11 September 2026. Sumber status live, 6 percobaan kirim, dan catatan webhook masuk yang direncanakan.
- Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi, basis data peraturan BPK. Tanggal berlaku 17 Oktober 2022.
