Kenapa Kami Akhirnya Bangun Fitur Inventory (Padahal Awalnya Mau Skip)

Awalnya, Inventory Nggak Ada di Roadmap V1

Waktu kami bikin roadmap awal CrescendPOS, inventory sengaja kami taruh di versi berikutnya. Alasannya masuk akal: POS itu tentang transaksi — terima pesanan, proses pembayaran, cetak struk. Inventory management itu domain yang berbeda, lebih kompleks, dan bisa jadi produk tersendiri.

Kami nggak mau CrescendPOS jadi software yang mencoba melakukan segalanya tapi nggak ada yang bener. Jadi kami bilang, "Inventory nanti dulu."

Tapi kemudian sesuatu terjadi yang bikin kami berubah pikiran.

Pertanyaan yang Terus Muncul: "Besok Harus Belanja Apa?"

Setiap kali kami ngobrol sama pemilik usaha F&B — baik yang sudah pakai CrescendPOS maupun yang belum — ada satu pertanyaan yang hampir selalu muncul: "Besok saya harus belanja apa, berapa banyak?"

Ini bukan pertanyaan tentang fitur software. Ini pertanyaan survival bisnis sehari-hari. Dan jawabannya, untuk kebanyakan usaha kecil, adalah: "feeling." Mereka belanja berdasarkan kebiasaan dan perkiraan kasar. Kadang kebanyakan, bahan basi. Kadang kekurangan, pelanggan kecewa.

Yang bikin kami tergerak bukan cuma frekuensi pertanyaannya, tapi dampaknya. Waste bahan baku itu langsung makan profit. Kehabisan stok itu langsung kehilangan penjualan. Di bisnis F&B dengan margin yang sudah tipis, keduanya bisa jadi perbedaan antara untung dan rugi di akhir bulan.

Kami nggak bisa terus bilang "itu fitur versi depan" ketika masalahnya ada sekarang.

Pertimbangan Internal: Mau Seberapa Dalam?

Begitu kami memutuskan untuk bangun inventory, pertanyaan berikutnya langsung muncul: sampai mana?

Inventory management itu spectrum. Di ujung simpel, kamu cuma track stok: "Kopi Arabika tersisa 2 kg." Di ujung kompleks, kamu punya resep per produk, konversi unit otomatis, reorder point dengan notifikasi, dan integrasi supplier.

Kami punya perdebatan internal yang cukup panjang soal ini. Tim yang satu bilang, "Kalau mau bangun, bangun yang lengkap sekalian." Tim yang lain bilang, "Kalau terlalu kompleks, user kecil nggak akan pakai."

Akhirnya kami ambil jalan tengah yang kami sebut "progressive complexity" — mulai dari yang simpel, tapi arsitekturnya sudah disiapkan untuk yang kompleks.

Yang Kami Bangun: Simple Stock Tracking

Versi pertama inventory di CrescendPOS sengaja kami buat sesederhana mungkin:

• Track stok per produk. Setiap produk bisa punya jumlah stok yang diupdate manual oleh pemilik atau manager.
• Stok otomatis berkurang waktu transaksi. Jual satu Es Kopi Susu, stok Es Kopi Susu berkurang satu. Simpel, langsung.
• Low stock alert. Kamu bisa set minimum stok per produk. Waktu stok turun di bawah angka itu, sistem kasih notifikasi.
• Produk otomatis "habis" waktu stok nol. Kalau stok Es Kopi Susu habis, produk otomatis ditandai "Stok Habis" di layar POS supaya kasir nggak jual sesuatu yang nggak bisa dibuat.
• Stock adjustment log. Setiap perubahan stok tercatat — siapa yang ubah, kapan, dari berapa ke berapa, dan alasannya apa.

Itu saja. Nggak ada resep, nggak ada konversi unit, nggak ada reorder otomatis. Dan itu keputusan yang sadar.

Yang Kami Sengaja Nggak Bangun (dan Kenapa)

Ada beberapa fitur yang hampir kami bangun tapi akhirnya kami tunda:

Resep (recipe management). Idealnya, waktu kamu jual satu Es Kopi Susu, sistem otomatis kurangi stok kopi 20 gram, susu 150ml, es batu 5 buah, dan cup 1 buah. Ini powerful tapi juga sangat kompleks — setiap produk harus punya breakdown bahan baku yang akurat, dan kamu harus maintain database bahan baku yang terpisah dari database produk.

Kami dengar dari pengguna bahwa bahkan usaha menengah yang punya 20-30 produk sering struggle untuk maintain resep yang akurat. Bahan berubah, porsi nggak konsisten antar staff, supplier ganti. Fitur resep yang nggak akurat lebih berbahaya daripada nggak punya fitur resep — karena kamu percaya angka yang salah.

Konversi unit otomatis. Beli kopi dalam kilogram, track usage dalam gram. Beli susu dalam liter, track dalam mililiter. Konsepnya simpel, tapi edge case-nya banyak dan bikin UI jadi rumit untuk user yang cuma mau tahu "sisa berapa."

Reorder point otomatis. Sistem yang secara otomatis suggest "saatnya order 5 kg kopi lagi." Ini butuh data historis yang panjang dan pattern recognition yang akurat. Di fase awal, datanya belum cukup untuk suggestion yang bisa diandalkan.

Semuanya masuk rencana — tapi kami nggak mau rilis fitur setengah matang yang bikin user frustrasi.

Filosofi Progressive Complexity

Ide di balik pendekatan kami ini sederhana: mulai dari yang berguna sekarang, bukan dari yang lengkap nanti.

Usaha kecil yang baru mulai pakai POS nggak butuh recipe management yang canggih. Mereka butuh tahu: "apakah stok gue masih cukup buat besok?" Itu pertanyaan yang bisa dijawab dengan simple stock tracking.

Begitu bisnis tumbuh dan mulai butuh fitur yang lebih advanced, fitur itu harusnya tersedia tanpa mengharuskan mereka pindah ke software lain. Tapi fitur advanced itu nggak boleh bikin pengalaman user baru jadi overwhelming.

Makanya pendekatan kami:

• Default experience tetap simpel. Buka fitur inventory, set stok per produk, selesai. Nggak ada wizard 10 langkah yang harus dilalui.
• Kompleksitas opt-in. Fitur-fitur advanced (waktu nanti tersedia) bisa diaktifkan satu per satu. Nggak perlu semuanya sekaligus.
• Data backward-compatible. Data stok yang kamu input hari ini tetap berguna waktu fitur resep tersedia nanti. Nggak ada yang perlu diulang dari nol.

Dampak yang Nggak Kami Antisipasi

Setelah rilis fitur inventory sederhana ini, ada beberapa efek yang jujur nggak kami prediksi sebelumnya:

Waste berkurang karena visibility. Begitu pemilik usaha bisa lihat pergerakan stok per hari, mereka jadi lebih sadar tentang pola konsumsi. "Oh ternyata di hari Selasa kita cuma pakai setengah dari stok weekend." Awareness ini sendiri — tanpa fitur canggih apa pun — udah cukup bikin mereka adjust perilaku belanja.

"Stok Habis" di POS mengurangi janji palsu. Sebelum ada fitur ini, kasir kadang tetap terima pesanan walau bahan sudah habis — karena mereka nggak tahu atau lupa. Pelanggan sudah bayar, baru dikasih tahu "maaf, habis." Dengan status stok yang live di layar POS, masalah ini hilang.

Stock adjustment log membangun trust. Beberapa pemilik usaha cerita bahwa begitu ada log siapa yang adjust stok dan kenapa, "shrinkage misterius" berkurang. Bukan karena ada yang ketahuan curang — tapi karena accountability mencegah masalah sebelum terjadi.

Apa yang Kami Pelajari dari Proses Ini

Pengalaman bangun fitur inventory mengajarkan kami beberapa hal:

• Dengarkan frekuensi, bukan volume. Satu user yang minta fitur kompleks dengan detail bisa sangat persuasif. Tapi 50 user yang bertanya hal simpel yang sama — itu sinyal yang lebih kuat.
• Roadmap boleh berubah. Kami awalnya taruh inventory di V2. Tapi realita pasar menunjukkan ini dibutuhkan lebih cepat. Kekakuan terhadap roadmap bisa jadi kelemahan kalau bikin kamu mengabaikan kebutuhan nyata.
• "Nanti" harus punya tanggal. Waktu kami bilang "resep management nanti," kami memastikan ada timeline yang jelas. "Nanti" tanpa tanggal itu sama saja "nggak pernah."
• Simple beats comprehensive kalau comprehensive nggak jadi-jadi. Lebih baik kasih user simple stock tracking yang jalan hari ini daripada janji recipe management yang baru ready 6 bulan lagi.

Inventory mungkin bukan fitur yang bikin orang bilang "wow" waktu demo. Tapi ini fitur yang bikin mereka bilang "ini yang gue butuhkan" waktu operasional sehari-hari. Dan itu yang kami kejar.