Ringkasan
Perumdam Tirta Pandalungan adalah perusahaan air untuk Kabupaten Jember. Setiap bulan, pembaca meter jalan rute, cek meter pelanggan, tulis pembacaan di form kertas, terus serahkan ke staff data entry yang ketik semua ke sistem. Lambat, rawan error, dan boros.
DIMETRI adalah aplikasi mobile yang taruh data entry di lapangan. Pembaca meter pakai HP mereka untuk log pembacaan on-site. Aplikasi validasi data, flag anomali, dan sync ke sistem billing. Tanpa kertas. Tanpa double entry. Tanpa error transkripsi.
Saya bangun aplikasi mobile dan backend API. Aplikasi harus jalan offline karena pembaca meter tidak selalu punya sinyal. Harus cepat karena mereka punya ratusan meter untuk dibaca per hari. Dan harus akurat karena billing tergantung ini.
Ini jenis proyek yang tidak menang design award, tapi hemat ribuan jam kerja manual. Software infrastruktur. Membosankan, esensial, dan memuaskan kalau jalan.
Klien
Perumdam Tirta Pandalungan melayani lebih dari 100.000 pelanggan di Kabupaten Jember, Jawa Timur. Mereka perusahaan milik pemerintah, yang artinya peduli soal efisiensi dan akuntabilitas. Mereka juga punya budget terbatas, jadi solusinya harus cost-effective.
Proses baca meter adalah bottleneck terbesar mereka. Pembacaan butuh minggu untuk diproses. Error bikin dispute billing. Mereka perlu modernisasi, tapi tidak mampu sistem enterprise besar.
Fitur
Route management assign pembaca meter ke area spesifik dengan daftar pelanggan. Aplikasi tunjukkan rute di peta dan guide pembaca lewat meter yang di-assign secara berurutan. Setiap pelanggan punya profil dengan alamat, nomor meter, dan riwayat pembacaan.
Meter reading adalah fitur inti. Pembaca masukkan pembacaan saat ini, ambil foto meter, dan submit. Aplikasi validasi pembacaan terhadap data historis — kalau terlalu tinggi atau rendah, di-flag untuk review. Koordinat GPS di-log untuk verifikasi pembaca ada on-site.
Mode offline itu kritis. Pembaca download data rute mereka di awal hari dan kerja offline. Pembacaan disimpan lokal dan di-sync saat mereka online lagi. Sync-nya smart — handle conflict dan retry upload yang gagal.
Anomaly detection tangkap error umum. Kalau pembacaan lebih rendah dari bulan sebelumnya (kemungkinan meter rollover atau typo), aplikasi kasih warning ke pembaca. Kalau unusually tinggi (kebocoran atau error data entry), butuh konfirmasi. Ini kurangi dispute billing.
Tech Stack
Flutter untuk aplikasi mobile. GetX untuk state management dan routing. SQLite untuk local storage dengan background sync. Google Maps API untuk visualisasi rute dan GPS logging.
Laravel untuk backend API. MySQL untuk database. JWT authentication dengan role-based access. API handle route assignment, reading submission, anomaly detection, dan reporting.
Image compression sebelum upload untuk hemat bandwidth. Retry logic untuk failed sync. Push notification untuk route assignment dan system update.
Peran Saya
Full-stack developer. Saya design database schema, bangun backend API, develop aplikasi mobile, dan deploy keduanya ke production. Saya juga kerja sama dengan klien untuk map workflow mereka yang ada dan identifikasi pain point.
Offline sync adalah bagian paling susah. Pembaca meter bisa offline berjam-jam. Saya harus pastikan data integrity, handle conflict, dan pastikan tidak ada yang hilang. Akhirnya pakai queue-based system yang simpan pembacaan lokal dan sync dalam batch.
Saya juga harus pikir soal edge case. Bagaimana kalau meter rusak? Bagaimana kalau pelanggan tolak akses? Bagaimana kalau pembaca salah ketik? Aplikasi perlu handle skenario ini tanpa blokir workflow.
Training itu penting. Saya jalankan sesi dengan pembaca meter untuk tunjukkan cara pakai aplikasi. Dapat feedback, perbaiki bug, dan sederhanakan UI berdasarkan apa yang mereka butuhkan. Versi pertama punya terlalu banyak fitur. Saya strip down ke essentials.
Aplikasi sudah production lebih dari setahun. Perusahaan air lapor siklus billing lebih cepat, error lebih sedikit, dan kualitas data lebih baik. Pembaca meter suka karena lebih cepat dari kertas. Itu win.