Membangun KosPro: Aplikasi Kelola Kos dari Masalah Nyata ke Play Store

Sebagian besar artikel di blog ini membahas cara kerja sama dengan software house. Kali ini kami membuka dapur sendiri. KosPro adalah aplikasi kelola kos yang kami bangun dan rilis sendiri di Google Play. Artikel ini menceritakan bagaimana KosPro lahir: masalah apa yang diselesaikan, fitur apa yang sengaja kami tunda di versi pertama, kenapa memilih Flutter dan Supabase, dan apa yang kami pelajari di sepanjang jalan.

Kami menulisnya bukan untuk promosi, tetapi karena cerita ini adalah contoh paling konkret dari cara kami bekerja. Kalau kamu pemilik usaha yang sedang memikirkan aplikasi untuk operasional, pola yang sama kemungkinan besar berlaku untuk bisnismu.

Masalah yang ingin diselesaikan: tagihan telat yang tidak terpantau

Ide KosPro datang dari pengamatan sederhana terhadap cara pemilik kos mengelola usahanya. Hampir semuanya masih manual: pembayaran dicatat di buku tulis, penghuni diingatkan satu per satu lewat chat WhatsApp, status kamar kosong hanya ada di kepala, dan tidak ada laporan keuangan yang rapi. Masalahnya berlipat ketika pemilik punya lebih dari satu lokasi.

Yang menarik, masalah terbesar bukan di pencatatan, tetapi di tagihan telat yang tidak terpantau:

• Tanggal jatuh tempo tiap penghuni berbeda, mengikuti tanggal masuk masing-masing, jadi tidak ada "hari tagihan" yang seragam.
• Pembayaran lewat transfer bercampur dengan transaksi lain di rekening.
• Penghuni yang telat sering baru ketahuan berminggu-minggu kemudian, karena tidak ada yang mengingatkan.
• Saat pemilik mendelegasikan ke penjaga kos atau berganti admin, riwayat pembayaran ikut hilang.

Kalau kamu pernah membaca artikel kami soal kapan bisnis belum butuh AI, ini contoh persisnya. Masalahnya bukan "kurang pintar", tetapi "kurang rapi". Solusinya bukan AI, melainkan satu sumber kebenaran untuk data penghuni dan tagihan, status yang jelas, dan pengingat otomatis.

Discovery: merancang di atas kertas dulu

Sebelum satu baris kode ditulis, kami menyusun alur aplikasi per layar dan wireframe sederhana (lo-fi) untuk tiap halaman: daftar properti, kamar, penghuni, notifikasi, pengaturan, sampai laporan. Dokumen ini jadi kontrak scope: kalau sebuah layar tidak ada di situ, ia tidak masuk versi pertama.

Tiga hal yang kami anggap wajib dijawab oleh versi pertama:

1. Siapa yang belum bayar bulan ini, dan siapa yang sebentar lagi jatuh tempo.
2. Kamar mana yang kosong, kamar mana yang terisi.
3. Riwayat pembayaran per penghuni, supaya ada pegangan kalau terjadi perselisihan.

Catatan jujur: daftar keinginan awal kami jauh lebih panjang: integrasi pembayaran, portal untuk penghuni, multi-pengelola, bahkan ide publikasi kamar kosong. Semua itu terdengar bagus dan semua itu menunda rilis. Kami memangkasnya dengan disiplin yang sama seperti yang kami sarankan ke klien di artikel MVP vs produk lengkap. Beberapa di antaranya sampai sekarang belum kami bangun, dan belum ada pengguna yang mengeluh.

Scope versi 1: empat objek, satu alur

Setelah perancangan, scope v1 kami kunci ke empat objek data dan satu alur utama.

Alur utamanya: pemilik menambah properti dan kamar, memasukkan penghuni, lalu aplikasi membuat tagihan bulanan otomatis dan menandai statusnya dengan warna. Hijau sudah bayar, kuning mendekati jatuh tempo, merah telat. Pemilik yang memutuskan kapan sebuah tagihan dianggap lunas, lewat satu tombol di halaman kamar.

Satu detail kecil yang ternyata penting: ambang "segera jatuh tempo" awalnya kami tanam sebagai tujuh hari. Setelah dipakai, ada pemilik yang ingin tiga hari, ada yang ingin dua minggu. Sekarang ini bisa diatur sendiri (3, 5, 7, atau 14 hari). Pelajaran: angka yang terasa "jelas" bagi pembuat aplikasi belum tentu jelas bagi pemakainya.

Keputusan teknologi: Flutter dan Supabase

Flutter karena satu codebase untuk Android dan iOS, dan karena kami sudah menguasainya. Untuk aplikasi operasional seperti ini, kecepatan iterasi jauh lebih penting daripada tampilan yang "seratus persen native".

Supabase karena memberi tiga hal sekaligus tanpa membangun backend dari nol: database PostgreSQL, autentikasi (email serta Google Sign-In supaya pemilik kos tidak perlu mengingat kata sandi baru), dan fungsi terjadwal di server. Fungsi terjadwal inilah yang membuat tagihan bulanan dibuat otomatis dan status telat diperiksa tiap hari, tanpa pemilik harus membuka aplikasi.

Untuk langganan Premium, kami memakai RevenueCat. Ini bukan pilihan pertama kami, dan ceritanya kami bahas di pelajaran monetisasi dari KosPro.

Yang ingin kami tekankan ke pembaca non-teknis: ketiganya adalah layanan siap pakai yang menghemat berminggu-minggu kerja. Untuk aplikasi operasional usaha kecil, hampir selalu lebih bijak memakai layanan seperti ini daripada membangun server sendiri. Kisaran biayanya kami bahas di biaya bikin aplikasi di Indonesia 2026.

Yang lebih rumit dari perkiraan: tanggal

Fitur yang kelihatannya paling sepele, "buat tagihan tiap bulan", justru yang paling banyak memakan waktu. Tanggal masuk 31 Januari jatuh tempo kapan di Februari? Penghuni yang pindah kamar di tengah bulan ditagih bagaimana? Pembayaran sebagian dicatat sebagai apa? Zona waktu server dan ponsel berbeda, tagihan dibuat di hari yang salah?

Tidak ada satu pun dari pertanyaan itu yang ada di daftar fitur. Semuanya muncul saat mengerjakan. Ini alasan kami selalu memasang cadangan waktu untuk "aturan bisnis" di estimasi proyek klien, dan alasan tahap testing di SDLC tidak boleh dipangkas.

Untuk mengujinya, kami membuat data tiruan berukuran ekstrem: seratus properti dengan seratus kamar masing-masing, lengkap dengan penghuni yang telat, yang hampir jatuh tempo, dan yang lunas. Kalau aplikasi masih lancar dengan sepuluh ribu kamar, pemilik dengan tiga puluh kamar tidak akan punya masalah.

Rilis ke Google Play

Dari commit pertama di awal April 2026 sampai tersedia di Google Play pada akhir Juli 2026, KosPro memakan waktu sekitar empat bulan dengan tim kecil, dikerjakan berdampingan dengan pekerjaan lain. Angka ini relevan kalau kamu sedang menaksir proyek serupa: aplikasi operasional sederhana untuk satu jenis usaha, tanpa integrasi pembayaran, tetapi dengan langganan dan otomatisasi.

Beberapa hal yang memakan waktu di luar coding dan perlu kamu masukkan ke jadwal proyek apa pun:

• Akun developer dan verifikasi. Google meminta verifikasi identitas organisasi untuk akun atas nama PT, dan ini punya jeda tersendiri.
• Materi listing. Ikon, grafis fitur, tangkapan layar, deskripsi dalam dua bahasa, kebijakan privasi di domain sendiri. Semuanya diperiksa.
• Review dan kepatuhan. Aplikasi dengan akun pengguna dan pembelian dalam aplikasi diperiksa lebih teliti, termasuk soal data pengguna.

Versi iOS kami siapkan dari codebase yang sama, termasuk konfigurasi pembelian dalam aplikasinya, dan akan menyusul.

Setelah rilis: yang tidak kami duga

Begitu dipakai orang lain, beberapa hal muncul yang tidak terpikir saat merancang:

1. Pendaftaran akun sampah. Ada pendaftaran memakai email sekali pakai. Kami menambahkan pemblokiran domain email sekali pakai dan pencatatan percobaan login. Di versi 2.0.1, ini justru jadi pembaruan utama.
2. Aplikasi lama yang tidak diperbarui. Pengguna tidak otomatis memperbarui aplikasi. Kami menambahkan mekanisme pembaruan wajib dan pembaruan anjuran supaya versi lama tidak rusak saat server berubah.
3. Pengingat ke penghuni, bukan hanya ke pemilik. Permintaan paling sering: "bisa tidak aplikasinya yang menagih?" Jawabannya menjadi fitur Premium: pemilik menghubungkan WhatsApp miliknya sendiri ke aplikasi, lalu pengingat tagihan dikirim otomatis ke penghuni dengan template pesan yang bisa diubah.

Apa yang bisa kamu bawa ke bisnismu

• Mulai dari status, bukan dari fitur. Pertanyaan "siapa yang belum bayar?" lebih berharga daripada sepuluh fitur lain. Temukan pertanyaan setara di usahamu.
• Aturan tanggal dan uang selalu lebih rumit dari dugaan. Sisihkan waktu untuk itu.
• Pakai layanan siap pakai untuk yang bukan inti bisnismu. Autentikasi, database, langganan. Bangun sendiri hanya yang membedakan produkmu.
• Rancang batas gratis dan berbayar sejak awal. Ini memengaruhi struktur data, bukan sekadar harga.

Itu juga cara kami menangani proyek klien. Produk yang kami bangun sendiri, termasuk Cuplikin, adalah tempat kami menguji proses itu sebelum menerapkannya ke layanan untuk klien.

Langkah selanjutnya

Kalau usahamu punya masalah serupa, data tersebar, tagihan tidak terpantau, atau proses yang bergantung pada ingatan orang, kami bisa bantu merancang aplikasi yang tepat ukurannya. Mulai dari konsultasi gratis atau chat lewat WhatsApp.