3 Kesalahan Fatal Sebelum Bikin Aplikasi yang Bisa Bikin Lo Makin Ribet
Nggak perlu ngerti coding. Gue kasih tahu cara menjelaskan masalah, proses bisnis, dan kebutuhan sistem lo ke developer atau AI biar nggak mulai dari arah yang salah.
Lo Abis Nonton Reel Gue? Nih Panduan Lengkapnya
Kalau lo baru selesai nonton reel gue soal kesalahan sebelum bikin aplikasi, welcome. π
Di reel, gue cuma sempet nunjukin 1-2 poinnya doang. Nggak sempet gue kasih template-nya, contoh lengkapnya, sampai worksheet yang bisa lo isi sendiri sebelum ketemu developer atau ngobrol sama AI.
Makanya di sini gue tulis semuanya β 3 kesalahan fatal, 4 template siap pakai, contoh dialog lengkap, prompt AI yang bisa lo copy, dan worksheet 10 bagian buat bikin brief aplikasi lo sendiri.
Intinya: lo nggak perlu ngerti coding. Lo cuma perlu bisa menjelaskan masalah, proses, dan hasil yang lo mau.
Baca sampai habis, biar lo nggak mulai proyek aplikasi dari arah yang salah.
3 Kesalahan Fatal Sebelum Bikin Aplikasi yang Bisa Bikin Lo Makin Ribet
Nggak perlu ngerti coding. Gue kasih tahu cara menjelaskan masalah, proses bisnis, dan kebutuhan sistem lo ke developer atau AI biar nggak mulai dari arah yang salah.
Sebelum Mulai
Kalau lo lagi kepikiran bikin aplikasi buat bisnis, gue mau bilang satu hal dulu: lo nggak perlu ngerti coding.
Serius. Lo nggak perlu tahu Laravel. Nggak perlu tahu React. Nggak perlu tahu database. Nggak perlu tahu server.
Yang paling penting dari sisi lo bukan: "Aplikasi ini dibuat pakai apa?" Tapi: "Masalah apa yang mau gue selesaikan?"
Nah, ini kelihatannya sederhana. Tapi justru di bagian ini banyak orang mulai salah.
Dan menurut gue wajar banget. Kalau kita nggak pernah bikin aplikasi sebelumnya, ya kita mikirnya memang: "Gue butuh aplikasi buat absensi." "Gue butuh aplikasi buat stok." "Gue butuh aplikasi buat data customer."
Masalahnya, kalau baru mulai dari situ, developer atau AI belum punya informasi yang cukup buat ngerti kebutuhan lo.
Makanya di sini gue mau kasih lo: 3 kesalahan yang sering terjadi waktu bisnis mulai bikin aplikasi, cara berpikir yang lebih gampang, cara ngomong ke developer, cara ngobrol dengan AI, dan template yang bisa langsung lo pakai.
Dan tenang. Gue bakal jelasin pakai bahasa manusia. Bukan bahasa dokumentasi software. π
Kesalahan #1 β "Gue Butuh Aplikasi Buat X"
Jangan mulai dari nama fiturnya. Mulai dari masalahnya.
Ini mungkin kelihatan sepele. Misalnya lo bilang: "Gue mau bikin aplikasi absensi." Oke. Terus? Absensi yang kayak gimana? Masalah lo sebenarnya apa?
Apakah: karyawan sering lupa absen? owner susah tahu siapa yang masuk? admin capek rekap? ada banyak cabang? jam kerja berbeda-beda? lo butuh tahu keterlambatan? lo butuh laporan bulanan? atau sebenarnya masalahnya bukan absensi sama sekali?
Nah. Ini yang sering nggak kepikiran. Kita langsung melihat solusinya, sebelum benar-benar menjelaskan masalahnya.
Coba bandingin
Versi 1: "Gue butuh aplikasi untuk data karyawan."
Dengan kalimat ini, developer atau AI masih bisa nanya: "Data apa?" "Siapa yang input?" "Untuk apa?" "Apa yang sekarang jadi masalah?" "Prosesnya bagaimana?"
Dan itu normal. Bukan berarti mereka nggak ngerti. Memang informasinya belum cukup. π
Versi 2: "Sekarang data karyawan gue masih dicatat di Excel. Kalau ada karyawan baru, admin harus update beberapa file. Kalau ada perubahan data, kadang file yang satu sudah berubah tapi file yang lain belum. Gue pengen punya satu tempat supaya data karyawan lebih gampang dikelola dan nggak perlu input berkali-kali."
Nah. Ini beda. Sekarang kita sudah tahu: kondisi sekarang, masalahnya, siapa yang terlibat, kenapa masalahnya muncul, hasil yang diinginkan. Dan kita bahkan belum ngomongin coding sama sekali.
Jadi kalau lo punya ide aplikasi...
Jangan mulai dengan: "Gue butuh fitur A." Coba mulai dengan: "Sekarang gue punya masalah A." Lalu lanjut: "Masalah ini terjadi karena B." Dan: "Gue pengen kondisi akhirnya jadi C." Sederhana.
Template #1 β Ubah "Fitur" Jadi "Problem"
Aplikasi yang kepikiran mau gue buat: β
Masalah apa yang sebenarnya mau gue beresin? β
Siapa yang paling sering mengalami masalah ini? β
Sekarang masalah ini diselesaikan pakai apa? β
Apa yang paling bikin ribet dari cara sekarang? β
Kalau masalah ini selesai, apa yang jadi lebih gampang? β
Kesalahan #2 β Terlalu Sibuk Mikirin Teknis
Baru punya ide aplikasi... langsung mikir: "Pakai programming language apa?" "Pakai database apa?" "Pakai framework apa?" "Pakai server mana?" "Pakai AI apa?" "Pakai arsitektur apa?"
Bro... bentar. π
Kalau lo pemilik bisnis, pertanyaan pertama lo seharusnya bukan itu. Pertanyaan pertama lo:
"Masalah bisnis gue selesai nggak kalau sistem ini dibuat?"
Karena buat apa aplikasinya dibuat dengan teknologi yang super keren kalau orang di bisnis lo tetap: copy-paste, buka Excel, cari data di WhatsApp, tanya orang, bikin rekap manual. π
Teknologinya boleh keren. Tapi masalah bisnisnya tetap harus selesai.
Bukan berarti teknis nggak penting
Penting. Banget. Tapi ada orang yang memang tugasnya mikirin itu. Kalau lo bekerja dengan developer, agency, atau orang teknis: biarkan mereka membantu menentukan bagian teknisnya.
Tugas lo adalah menjelaskan: "Ini masalah bisnis gue." "Ini proses gue sekarang." "Ini yang bikin ribet." "Ini hasil yang gue mau." Nah, dari situ mereka bisa mulai mencari cara yang tepat.
Contoh gampang
Misalnya lo punya restoran. Lo bilang: "Gue mau aplikasi yang pakai React, Laravel, PostgreSQL, terus ada API." Oke. Tapi... masalah bisnisnya apa? π
Bandingin dengan: "Sekarang pesanan dari beberapa channel masuk ke tempat yang berbeda. Staff harus ngecek beberapa tempat dan kadang ada pesanan yang kelewat. Gue pengen semua pesanan bisa masuk ke satu tempat supaya staff nggak perlu bolak-balik cek."
Nah. Sekarang kita punya masalah. Baru kita cari solusi. Dan solusinya belum tentu custom application. Bisa jadi: software yang sudah ada, integrasi, automation, konfigurasi, atau memang custom system.
Kita belum tahu. Dan itu nggak apa-apa. Justru jangan memutuskan solusinya sebelum kita ngerti masalahnya.
Kesalahan #3 β "Yang Penting Developer / AI Kerjain Aja"
Nah. Menurut gue ini yang paling fatal.
Lo memang nggak perlu ngerti teknis. Tapi bukan berarti setelah kasih brief: "Nih, bikin aplikasi." terus lo pergi. π
Karena ada proses di tengahnya. Dan dalam proses itu, lo bakal ditanya. Banyak. Kadang pertanyaannya sederhana. Kadang lo mikir: "Lho, kok ditanya sampai situ?" Ya karena mereka lagi mencoba memahami bisnis lo.
Contohnya begini
Lo bilang: "Gue mau sistem buat data customer." Developer mungkin tanya: "Customer-nya siapa?" Lo jawab: "Ya customer saya." π
Nah, belum cukup. Mereka mungkin lanjut: "Data apa yang perlu disimpan?" "Siapa yang input?" "Customer bisa lihat datanya nggak?" "Kalau datanya berubah siapa yang boleh edit?" "Kalau ada customer baru prosesnya bagaimana?" "Kalau customer sudah tidak aktif bagaimana?" Dan seterusnya.
Bukan mereka ribet. Memang pertanyaannya diperlukan supaya sistem yang dibuat nggak asal jadi.
Jadi kalau ditanya...
Lo nggak harus selalu punya jawaban sempurna. Kalau memang nggak tahu? Bilang aja nggak tahu. Serius.
Lo bisa bilang: "Gue belum tahu, bantu gue pikirin." Atau: "Sekarang prosesnya belum jelas, kita bisa bahas bareng?" Atau bahkan: "Gue nggak tahu bagian ini."
Nggak masalah. Menurut gue jauh lebih sehat daripada sok tahu. Karena kalau lo kasih jawaban asal... developer atau AI akan menganggap: "Oke, berarti memang begitu." Terus sistemnya dibangun berdasarkan asumsi tadi.
Dan beberapa minggu kemudian: "Lho kok aplikasinya begini?" Ya... karena dari awal informasinya juga begitu. π
Nah, Sekarang Gue Mau Ajarin Cara Ngobrolnya
Ini bagian yang menurut gue paling berguna. Karena gue nggak mau lo selesai baca terus cuma "Oh iya, ternyata gue nggak boleh ngomong teknis." Terus besok pas ketemu developer: "Terus gue harus ngomong apa?" π
Nah. Gue kasih template-nya.
Bagian 1 β Cara Menjelaskan Masalah ke Developer
Lo bisa mulai dengan kalimat:
"Gue punya masalah di bisnis gue dan gue pengen lihat apakah ini bisa dibantu dengan sistem."
Terus jelaskan 5 hal:
- Masalah gue sekarang apa? β
- Siapa yang mengalami masalah ini? β
- Sekarang prosesnya bagaimana? β
- Bagian mana yang paling bikin ribet? β
- Kondisi yang gue mau seperti apa? β
Udah. Nggak perlu langsung kasih solusi teknis.
Bagian 2 β Ceritakan Prosesnya
Ini bagian yang kadang bikin orang bingung. Padahal gampang. Ceritain aja seperti lo cerita ke teman.
Misalnya: "Customer masuk dari Instagram." "Terus admin balas." "Kalau tertarik, datanya dicatat." "Terus sales follow up." "Kalau deal, finance bikin invoice." "Setelah bayar, masuk ke tim operasional."
Selesai. Nggak perlu "Kemudian sistem melakukan asynchronous API request..." π Nggak perlu. Ceritain aja apa yang manusia lakukan sekarang.
Template #2 β Ceritakan Proses Bisnis Lo
Langkah 1: β
Langkah 2: β
Langkah 3: β
Langkah 4: β
Langkah 5: β
Kalau prosesnya lebih panjang, tambah sendiri. Kalau cuma 3 langkah? Ya 3 langkah. Nggak perlu dibikin panjang supaya kelihatan pintar. π
Bagian 3 β Cari Bagian yang Paling Bikin Ribet
Dari proses tadi, tandai bagian yang: paling sering dilakukan, paling sering salah, paling makan waktu, paling bikin orang harus nanya orang lain, paling sering bikin data hilang, paling bikin owner turun tangan.
Karena kita nggak harus memperbaiki semuanya sekaligus. Kadang satu bagian yang diberesin sudah bikin hidup tim jauh lebih enak.
Template #3 β Bagian Paling Ribet
Bagian yang paling bikin ribet: β
Kenapa ribet? β
Seberapa sering terjadi? β
Siapa yang paling kena dampaknya? β
Kalau bagian ini lebih gampang, apa yang berubah? β
Bagian 4 β Jelaskan Hasil yang Lo Mau
Jangan cuma bilang: "Gue mau dashboard." Karena dashboard itu cuma bentuk. Yang lebih penting: "Gue mau bisa melihat apa?"
Misalnya bukan: "Gue mau dashboard sales." Tapi: "Gue pengen setiap pagi bisa tahu berapa lead baru, berapa yang sudah di-follow up, dan mana yang belum."
Nah. Sekarang jelas. Dashboard cuma salah satu cara untuk mendapatkan hasil itu. Bisa jadi memang dashboard. Bisa jadi report. Bisa jadi notifikasi. Bisa jadi automation. Kita lihat nanti.
Template #4 β Hasil yang Gue Mau
Setelah sistem ini selesai, gue pengen bisa:
- β
- β
- β
Hal yang sekarang paling pengen gue hilangkan: β
Hal yang sekarang paling pengen gue permudah: β
Contoh Lengkap
Misalnya ada owner restoran. Dia datang dan bilang: "Gue mau bikin aplikasi stok." Oke. Kalau berhenti di situ... gue belum tahu apa-apa. π Tapi kita ngobrol.
Owner: "Sekarang kalau barang datang, staff catat di buku."
Gue: "Terus?"
Owner: "Nanti admin masukin lagi ke Excel."
Gue: "Terus kalau barang dipakai?"
Owner: "Kadang dicatat, kadang nggak."
Gue: "Terus lo tahu stok sekarang dari mana?"
Owner: "Biasanya tanya staff."
Nah. Sekarang masalahnya mulai kelihatan. Ternyata masalahnya bukan sekadar "Butuh aplikasi stok." Masalahnya lebih seperti:
"Data stok nggak selalu diperbarui dengan konsisten, jadi owner susah tahu jumlah stok sebenarnya."
Dan itu jauh lebih jelas.
Dari sini kita bisa lanjut
Kita tanya: Siapa yang mencatat barang masuk? Siapa yang mencatat barang keluar? Kapan data diperbarui? Apa yang terjadi kalau barang rusak? Apa yang terjadi kalau jumlah fisik berbeda dengan data? Siapa yang perlu melihat stok? Apakah owner perlu notifikasi kalau stok tertentu menipis?
Nah. Baru kita mulai punya gambaran sistem. Dan perhatikan: kita belum ngomong Laravel, React, PostgreSQL, API, Server. Nggak perlu. Karena kita masih menyelesaikan satu hal dulu: "Sebenarnya bisnis ini butuh apa?"
Sekarang Kalau Lo Ngobrol Sama AI?
Nah, ini malah menarik. Karena AI bisa membantu lo mengurai masalah bisnis. Tapi jangan mulai dengan "AI, bikin aplikasi stok untuk saya." Terus berharap "Selesai." π AI juga belum tahu bisnis lo.
Prompt Awal yang Bisa Lo Pakai
Gue mau bikin sistem untuk bisnis gue, tapi gue nggak ngerti IT.
Jangan langsung bikin aplikasinya.
Gue mau lo bantu gue memahami dulu masalah dan proses bisnis gue.
Tolong tanyain gue satu per satu tentang:
1. masalah yang mau gue selesaikan
2. siapa yang mengalami masalah
3. proses yang sekarang berjalan
4. bagian yang paling ribet
5. kesalahan yang sering terjadi
6. informasi yang perlu dilihat
7. siapa saja yang akan menggunakan sistem
Jangan pakai bahasa teknis yang rumit.
Kalau jawaban gue belum jelas, bantu gue dengan contoh
supaya gue lebih gampang jawab.
Kalau menurut lo gue belum punya cukup informasi,
jangan menebak. Tanya gue lagi.
Setelah semua informasi cukup, baru bantu gue membuat
gambaran sistem yang sederhana dan mudah dipahami.
Terus AI Mungkin Nanya
"Siapa yang bertanggung jawab memasukkan data stok?" Kalau lo tahu: "Admin gudang." Ya jawab.
Kalau nggak tahu? Bilang aja: "Gue belum tahu." Kalau bingung maksudnya apa: "Maksud pertanyaan ini apa?" Kalau lo punya beberapa kemungkinan: "Kayaknya admin, tapi kadang staff juga."
Itu semua jawaban yang valid. Lo nggak sedang ujian. π
Kalau AI Mulai Ngomong Teknis?
Misalnya tiba-tiba dia bilang: "Kita bisa menggunakan REST API dengan relational database..." Lo bisa jawab:
"Skip dulu bagian teknisnya. Jelaskan ke gue dari sisi bisnis dan pengguna."
Simple. Karena tujuan lo bukan menjadi programmer. Tujuan lo adalah: memastikan sistem yang dibuat memang menyelesaikan masalah lo.
Kalau Developer yang Ngerjain?
Prinsipnya sama. Lo nggak perlu bilang: "Mas, saya ingin menggunakan framework X dengan database Y." Lebih baik bilang: "Ini masalah gue." "Ini proses gue sekarang." "Ini yang paling bikin ribet." "Ini hasil yang gue mau."
Lalu: "Menurut lo, cara paling masuk akal buat menyelesaikan ini apa?"
Nah. Sekarang developer bisa ikut mikir. Bukan cuma jadi tukang bikin fitur.
Satu Hal yang Menurut Gue Penting Banget
Jangan takut kalau developer banyak nanya
Kadang owner bisa mikir: "Kok banyak banget pertanyaannya?" Menurut gue justru... bagus. Karena artinya mereka sedang mencoba memahami kebutuhan lo.
Lo malah perlu waspada kalau lo bilang: "Gue butuh sistem buat X." Terus dibalas: "Siap Pak. Dua minggu jadi." π
Karena... dia tahu apa?
Makanya jangan merasa terganggu kalau ada proses discovery. Itu bagian penting dari bikin aplikasi.
Cheat Sheet β Kalau Besok Lo Mau Ngobrol Sama Developer / AI
Simpan 7 pertanyaan ini.
- Masalah apa yang mau gue selesaikan?
- Siapa yang mengalami masalah ini?
- Sekarang prosesnya bagaimana?
- Bagian mana yang paling bikin ribet?
- Bagian mana yang paling sering salah?
- Kalau masalah ini selesai, kondisi idealnya seperti apa?
- Siapa saja yang akan menggunakan sistem?
Kalau lo sudah bisa jawab tujuh ini... lo sudah punya bahan ngobrol yang jauh lebih bagus. Dan sekali lagi: belum ada satu pun pertanyaan tentang coding. π
Bonus β Cara Cek Apakah Brief Lo Sudah Cukup Jelas
Coba kasih brief lo ke orang yang nggak terlibat di bisnis lo. Terus tanya:
"Menurut lo, masalah yang gue ceritain apa?"
Kalau dia bisa menjelaskan kembali dengan cukup mirip... berarti kemungkinan lo sudah cukup jelas.
Kalau dia malah bilang: "Gue nggak ngerti." Nah. jangan buru-buru salahin dia. Mungkin memang penjelasan lo yang masih terlalu abstrak. Coba ceritakan lagi pakai contoh.
Misalnya bukan: "Proses approval kita nggak efisien." Tapi: "Sekarang kalau staff mau minta approval, dia kirim WhatsApp ke manager. Kalau manager belum baca, staff harus follow up. Kadang request-nya ketumpuk."
Nah. Sekarang orang lebih gampang ngerti.
Final Worksheet β Bikin Brief Aplikasi Lo Sendiri
01 β Masalah. Masalah utama yang mau gue selesaikan: β
02 β Siapa yang Kena. Siapa yang paling sering mengalami masalah ini? β
03 β Proses Sekarang. Sekarang prosesnya dari awal sampai akhir bagaimana? β
04 β Bagian Paling Ribet. Bagian mana yang paling makan waktu / bikin bingung / sering salah? β
05 β Penyebab. Menurut gue, kenapa masalah ini terjadi? β Kalau nggak tahu: "Gue belum tahu." Nggak apa-apa. Justru tulis begitu.
06 β Hasil yang Gue Mau. Kalau masalah ini sudah beres, gue pengen bisa: β
07 β Pengguna. Siapa saja yang akan menggunakan sistem ini? β
08 β Informasi. Informasi apa yang mereka perlu lihat / input? β
09 β Aturan. Ada aturan khusus yang perlu diperhatikan? Contoh: hanya manager yang boleh approve, staff nggak boleh melihat data tertentu, customer cuma bisa melihat datanya sendiri. β
10 β Prioritas. Kalau kita cuma boleh membereskan SATU masalah dulu, masalah apa yang paling penting? β
Sekarang Coba Baca Ulang
Kalau sebelum ini lo cuma punya: "Gue mau bikin aplikasi X." sekarang lo sudah punya: problem, orang yang kena problem, proses sekarang, bagian yang ribet, penyebab yang mungkin, hasil yang diinginkan, pengguna, informasi, aturan, prioritas.
Nah. Ini jauh lebih enak buat dibawa ngobrol ke developer. Atau dibawa ngobrol ke AI.
Dan yang paling penting... lo nggak perlu ngerti coding untuk sampai di tahap ini. Lo cuma perlu ngerti bisnis lo sendiri.
Penutup
Kalau lo baca sampai sini, gue apresiasi banget.
Dan gue harap sekarang satu hal jadi lebih jelas: Bikin aplikasi itu bukan dimulai dari "mau bikin fitur apa?"
Biasanya lebih enak dimulai dari: "Masalah apa yang sebenarnya mau kita beresin?"
Setelah itu baru kita lihat: prosesnya sekarang bagaimana? siapa yang terlibat? bagian mana yang ribet? hasil akhirnya mau seperti apa?
Baru setelah itu... kita cari solusi. Dan solusi itu belum tentu langsung "Bikin aplikasi custom." Bisa jadi software yang sudah ada cukup. Bisa jadi cuma perlu integrasi. Bisa jadi automation. Bisa jadi prosesnya yang perlu dibenerin. Bisa juga memang akhirnya butuh aplikasi custom.
Nggak apa-apa. Yang penting kita nggak menentukan jawabannya sebelum tahu pertanyaannya.
Dan satu hal lagi. Kalau nanti lo ngobrol sama developer atau AI lalu mereka banyak bertanya... jangan langsung merasa: "Waduh, gue nggak ngerti IT."
Justru mungkin mereka sedang melakukan bagian yang memang perlu dilakukan. Lo nggak perlu tahu bagaimana aplikasinya dibuat. Tapi lo perlu ikut menjelaskan kenapa aplikasi itu dibuat.
Karena kalau orang yang paling ngerti bisnisnya nggak ikut kasih input... ya akhirnya orang lain cuma bisa menebak-nebak.
Dan menurut gue... itu salah satu cara paling gampang bikin aplikasi yang technically jalan, tapi ternyata nggak terlalu berguna. π
Kalau lo mau belajar lebih banyak soal sistem, AI, website, dan digitalisasi bisnis...
Follow @denganloren di Instagram. Gue bakal terus bahas hal-hal yang gue temuin sebagai orang yang memang kerjaannya bikin sistem.
Tapi gue bakal tetap ngomongin dari sisi: "Ini gunanya buat bisnis lo apa?" bukan cuma "Ini teknologinya pakai apa?"
Karena menurut gue... lo nggak harus jadi programmer untuk bisa bikin keputusan teknologi yang bagus buat bisnis lo.
Lo cuma perlu tahu: masalah lo apa, proses lo bagaimana, dan hasil seperti apa yang lo mau.
Sisanya? Kita cari bareng.
Penulis

Lorencius Alvin Purnama
Co-Founder & Managing Director
Before Exclolab, Loren spent a decade embedded in service businesses across Southeast Asia β not as an outside consultant, but as the person who sits with the team, watches how work actually flows, and figures out where the system is breaking down. He developed the Discovery methodology at Exclolab from that experience: the idea that you cannot design a good system until you understand the one it's replacing. At Exclolab, he owns the Discovery phase and the client relationship from first conversation through final deployment.