Blog

Keamanan website sering dianggap urusan orang IT. Padahal ada banyak hal yang bisa Anda cek sendiri hari ini, tanpa perlu bisa coding sama sekali. Sepuluh hal itu adalah: gembok HTTPS di browser, kekuatan password admin, siapa saja yang punya akses, update CMS dan plugin, kondisi backup, spam di form kontak, alamat halaman admin, kepemilikan domain dan hosting, password email bisnis, serta hasil pencarian nama bisnis Anda di Google.

Anggap artikel ini seperti cek kesehatan ringan. Sebagian poin bisa Anda periksa langsung dalam lima menit. Sebagian lagi berupa pertanyaan yang tepat untuk diajukan ke developer atau vendor website Anda. Tidak perlu panik kalau ada yang bermasalah. Yang penting Anda tahu kondisinya, lalu tahu harus minta apa.

1. Gembok HTTPS aktif dan tidak kedaluwarsa

Buka website Anda di browser. Lihat bagian kiri kolom alamat. Kalau ada ikon gembok kecil, berarti sertifikat SSL aktif dan koneksi pengunjung terenkripsi. Klik gembok itu, biasanya ada informasi sampai kapan sertifikat berlaku. Coba juga akses website dengan mengetik http:// di depannya. Website yang sehat akan otomatis berpindah ke versi https://.

Kenapa penting? Browser modern menampilkan peringatan “Not Secure” atau “Tidak Aman” pada website tanpa HTTPS. Calon pelanggan yang melihat peringatan itu biasanya langsung menutup halaman. Google juga menjadikan HTTPS sebagai salah satu sinyal ranking.

Kalau gembok tidak muncul atau ada peringatan sertifikat, minta vendor memasang SSL dan mengatur perpanjangan otomatis. Sertifikat gratis seperti Let’s Encrypt sudah cukup untuk mayoritas website bisnis, jadi ini seharusnya bukan biaya besar.

2. Password admin tidak gampang ditebak

Cek password yang Anda pakai untuk masuk ke dashboard website. Kalau masih berupa nama bisnis plus angka tahun, tanggal lahir, atau kata seperti “admin123”, ganti hari ini juga. Cek juga satu hal yang sering terlewat: apakah password itu dipakai juga di akun lain seperti email atau media sosial.

Password yang sama di banyak tempat itu risikonya berlipat. Kalau satu layanan bocor, semua akun Anda ikut terbuka. Gunakan password yang panjang dan unik untuk tiap akun. Aplikasi pengelola password bisa membantu supaya Anda tidak perlu menghafal semuanya.

Tanyakan juga ke vendor apakah login admin bisa dipasangi verifikasi dua langkah. Fitur ini membuat akun tetap aman walaupun password sempat bocor.

3. Audit siapa saja yang punya akses admin

Masuk ke dashboard website, cari menu daftar pengguna atau users. Baca satu per satu. Apakah semua nama di situ masih relevan? Sering sekali ditemukan akun bekas karyawan, bekas vendor lama, atau akun uji coba yang tidak pernah dihapus.

Setiap akun admin adalah satu pintu masuk. Makin banyak pintu, makin besar peluang ada yang lupa dikunci. Akun bekas karyawan yang masih aktif juga berisiko dipakai orang yang sudah tidak punya kepentingan dengan bisnis Anda.

Hapus akun yang tidak terpakai. Untuk akun yang masih perlu, turunkan levelnya sesuai kebutuhan. Orang yang hanya menulis artikel tidak perlu akses admin penuh. Kalau Anda tidak bisa mengakses menu ini sendiri, minta vendor menunjukkan daftar semua akun beserta levelnya.

4. Update CMS dan plugin

Poin ini terutama untuk pengguna WordPress dan CMS sejenis. Masuk ke dashboard dan lihat apakah ada notifikasi update. Angka merah di menu updates yang menunjukkan belasan item tertunda adalah tanda website jarang dirawat.

Mayoritas kasus website WordPress yang dibobol terjadi lewat plugin versi lama yang celah keamanannya sudah diketahui publik. Penyerang tidak menarget bisnis Anda secara khusus. Mereka memakai program otomatis yang memindai ribuan website sekaligus untuk mencari celah yang sama.

Tanyakan ke vendor siapa yang bertanggung jawab menjalankan update rutin, seberapa sering, dan apakah ada backup sebelum update dijalankan. Kalau jawabannya tidak jelas, sepakati jadwal perawatan bulanan secara tertulis.

5. Backup: ada, di mana, dan kapan terakhir dites

Ini poin yang jarang bisa dicek sendiri, tapi pertanyaannya sederhana. Ajukan tiga pertanyaan ini ke vendor atau developer Anda. Pertama, apakah website di-backup otomatis dan seberapa sering. Kedua, di mana backup disimpan, apakah di server yang sama atau di tempat terpisah. Ketiga, kapan terakhir kali backup dites dengan restore sungguhan.

Pertanyaan ketiga itu yang paling penting. Backup yang tidak pernah dites restore itu seperti alat pemadam yang tidak pernah dicek isinya. Baru ketahuan kosong justru saat kebakaran. Backup yang disimpan di server yang sama dengan website juga percuma kalau servernya yang bermasalah.

Jawaban yang sehat kira-kira begini: backup harian otomatis, disimpan di lokasi terpisah, dan pernah diuji restore. Kalau vendor tidak bisa menjawab, minta itu dijadikan bagian dari layanan perawatan.

6. Form website tidak dibanjiri spam

Cek kotak masuk email yang menampung kiriman form kontak website Anda. Kalau isinya dipenuhi pesan promosi aneh berbahasa asing, tautan mencurigakan, atau teks acak, berarti form Anda belum punya proteksi.

Spam form bukan sekadar mengganggu. Pesan dari calon pelanggan sungguhan jadi tenggelam dan bisa terlewat. Form tanpa proteksi juga menandakan website dibangun tanpa memikirkan penyalahgunaan, dan itu sinyal untuk memeriksa bagian lain lebih teliti.

Minta vendor memasang proteksi seperti reCAPTCHA, Turnstile, atau teknik honeypot yang bekerja diam-diam tanpa mengganggu pengunjung. Pemasangannya cepat dan efeknya langsung terasa.

7. Halaman admin tidak mudah ditemukan orang

Coba buka alamat website Anda ditambah /wp-admin atau /admin dari browser biasa. Kalau halaman login langsung muncul begitu saja, siapa pun di internet bisa menemukannya juga, termasuk program otomatis yang kerjanya menebak password ribuan kali.

Halaman login yang terbuka lebar bukan berarti pasti dibobol. Tapi itu mengundang percobaan terus menerus. Selain risiko tembus, serangan tebak password yang bertubi-tubi juga bisa membuat website melambat.

Solusinya bisa Anda minta ke vendor: ubah alamat halaman login dari alamat bawaan, batasi jumlah percobaan login yang gagal, atau batasi akses halaman admin hanya dari jaringan tertentu. Cukup satu atau dua lapisan tambahan, efeknya sudah besar.

8. Domain dan hosting atas nama sendiri

Tiga pertanyaan untuk diri sendiri. Apakah domain terdaftar atas nama Anda atau perusahaan Anda, bukan atas nama vendor? Apakah Anda pegang akses ke akun registrar domain dan panel hosting? Apakah Anda tahu tanggal kedaluwarsa domain dan hosting?

Kasus domain hangus itu nyata dan sering terjadi. Domain terdaftar atas nama vendor, kerja sama berakhir, tagihan perpanjangan tidak ada yang mengurus, lalu domain mati. Website hilang, email bisnis ikut mati, dan domain yang sudah hangus bisa dibeli orang lain. Membangunnya kembali jauh lebih mahal daripada mencegahnya.

Kalau saat ini semuanya masih dipegang vendor, minta serah terima kepemilikan secara baik-baik. Daftar lengkap akses apa saja yang wajib Anda pegang sudah kami tulis di checklist serah terima proyek dari vendor. Setelah itu, pasang pengingat tanggal perpanjangan di kalender dan nyalakan perpanjangan otomatis kalau memungkinkan.

9. Email bisnis tidak berbagi password dengan website

Poin ini kelihatan sepele, tapi email adalah kunci induk dari hampir semua akun bisnis Anda. Reset password website, akses registrar domain, notifikasi hosting, semuanya lewat email. Kalau password email sama dengan password admin website, satu kebocoran cukup untuk membuka semuanya.

Cara ceknya cukup jujur pada diri sendiri. Apakah password email bisnis Anda sama atau mirip dengan password website, media sosial, atau marketplace? Kalau ya, ganti password email lebih dulu karena akun itu yang paling kritis, lalu nyalakan verifikasi dua langkah.

Kalau email bisnis dikelola vendor, tanyakan siapa saja yang memegang aksesnya dan pastikan Anda punya akses pemulihan sendiri.

10. Cek nama bisnis Anda di Google

Buka Google, lalu ketik site:namadomainanda.com dengan domain Anda sendiri. Perintah ini menampilkan semua halaman website Anda yang terindeks Google. Baca hasilnya pelan-pelan. Semua judul halaman seharusnya Anda kenali.

Kalau muncul halaman berbahasa asing yang tidak pernah Anda buat, judul tentang obat-obatan, judi online, atau produk yang tidak ada hubungannya dengan bisnis Anda, itu gejala klasik website yang sudah disusupi. Penyerang menumpang otoritas domain Anda untuk menyebar halaman spam, sering kali tanpa mengubah tampilan website sama sekali sehingga pemiliknya tidak sadar berbulan-bulan.

Kalau menemukan halaman seperti ini, jangan hapus sembarangan. Foto atau screenshot dulu hasilnya, lalu bawa ke developer untuk pembersihan menyeluruh. Menghapus halaman spam tanpa menutup celah masuknya hanya membuat halaman itu muncul lagi minggu depan.

Tiga tanda website sudah kena hack yang sering telat disadari

Selain sepuluh poin di atas, kenali juga tiga gejala yang sering luput karena tampilan website terlihat normal.

• Hasil pencarian Google berbeda dengan tampilan asli. Judul dan deskripsi di Google berubah jadi teks aneh, padahal saat dibuka langsung website tampak biasa saja. Penyerang memang sengaja hanya menampilkan konten spam ke mesin pencari.
• Pengunjung dialihkan ke situs lain. Ada pelanggan yang mengeluh dibuang ke situs judi atau iklan saat membuka website Anda dari HP, padahal dari laptop Anda semuanya normal. Pengalihan seperti ini sering dipasang hanya untuk pengunjung dari perangkat atau sumber tertentu.
• Peringatan merah dari browser atau Google. Muncul label “Situs ini mungkin diretas” di hasil pencarian, atau layar merah peringatan saat website dibuka. Kalau sudah sampai tahap ini, Google sudah mendeteksi masalahnya lebih dulu daripada Anda.

Kalau salah satu tanda ini muncul, langkah pertamanya bukan panik lalu menghapus file atau halaman sembarangan. Jejak serangan justru dibutuhkan developer untuk menemukan celah masuknya. Yang perlu Anda lakukan: catat gejalanya lengkap dengan screenshot, ganti password admin dan email, lalu hubungi developer atau vendor untuk pembersihan dan penutupan celah. Kalau website sedang menyimpan data pelanggan, sampaikan juga itu ke developer supaya penanganannya diprioritaskan.

Mulai dari yang paling mudah hari ini

Tidak perlu menyelesaikan semuanya dalam sehari. Mulai dari yang bisa dicek lima menit: gembok HTTPS, pencarian site: di Google, dan daftar pengguna di dashboard. Sisanya jadikan daftar pertanyaan untuk vendor Anda di pertemuan berikutnya. Vendor yang baik akan senang ditanya soal ini, karena artinya Anda peduli pada aset digital sendiri.

Kalau website Anda dibangun sudah lama dan tidak ada yang bisa menjawab pertanyaan-pertanyaan di atas, mungkin ini waktu yang tepat mempertimbangkan membangun ulang website dengan fondasi yang aman dari awal, lengkap dengan serah terima akses yang jelas.

Dan kalau dari checklist ini Anda menemukan sesuatu yang mencurigakan tapi bingung harus mulai dari mana, hubungi tim Arrazy. Ceritakan saja gejalanya, nanti kami bantu memetakan langkahnya.

Anda mengirim brief yang sama ke tiga vendor. Penawaran yang masuk selisihnya berkali lipat. Ada yang murah sekali, ada yang terasa mahal, dan semuanya sama-sama bilang sanggup mengerjakan apa yang Anda minta. Jawaban singkatnya begini. Harga aplikasi custom bisa beda jauh karena empat hal utama: scope yang ditafsirkan berbeda, siapa yang mengerjakan, kualitas yang tidak kelihatan saat demo, dan layanan setelah aplikasi rilis.

Kami menulis ini dari posisi orang dalam. Kami pernah kalah tender karena penawaran kami dianggap kemahalan. Kami juga pernah diminta membenahi aplikasi murah yang ujungnya lebih mahal daripada membangun ulang dari awal. Artikel ini membedah satu per satu faktor yang membuat penawaran bisa selisih jauh, supaya Anda bisa membandingkan dengan adil, bukan sekadar memilih angka terkecil.

Scope yang sama di brief, beda jauh di kepala vendor

Ini penyebab paling sering. Istilah seperti “aplikasi kasir” atau “aplikasi manajemen stok” itu bukan satu barang yang bakunya sama di semua tempat. Satu vendor membacanya sebagai 10 fitur. Vendor lain membacanya sebagai 40 fitur. Keduanya jujur, tapi mereka menghitung barang yang berbeda.

Contoh nyata. Aplikasi kasir versi sederhana isinya input barang, catat transaksi, cetak struk. Versi lengkapnya bisa punya multi cabang, manajemen stok dengan stok opname, laporan laba rugi, hak akses per karyawan, integrasi pembayaran digital, sampai mode offline saat internet mati. Nama di proposal sama-sama “aplikasi kasir”. Beban kerjanya bisa beda empat kali lipat.

Kalau brief Anda hanya satu paragraf, setiap vendor akan mengisi kekosongannya dengan asumsi masing-masing. Vendor yang menawar murah mungkin berasumsi versi minimal. Vendor yang menawar mahal mungkin sudah menghitung skenario lengkap. Selisih harga di tahap ini belum tentu soal mahal atau murah. Sering kali itu soal dua tafsir yang tidak pernah disamakan.

Siapa yang mengerjakan: satu orang atau satu tim

Faktor kedua adalah struktur orang di baliknya. Freelancer solo bisa menawar jauh lebih murah karena semua peran dia pegang sendiri. Dia yang desain, dia yang koding, dia yang tes, dia juga yang balas chat Anda. Tidak ada biaya tim yang harus ditanggung.

Vendor dengan tim menghitung beberapa orang sekaligus. Developer yang menulis kode, QA yang mencari bug sebelum Anda yang menemukannya, dan project manager yang menjaga jadwal serta jadi jembatan komunikasi. Setiap peran itu digaji, dan gaji itu masuk ke harga penawaran Anda.

Konsekuensinya nyata, bukan sekadar teori. Aplikasi yang dites hanya oleh pembuatnya sendiri hampir selalu lolos dengan bug yang tidak dia sadari, karena dia mengetes dengan cara dia memakai, bukan cara user memakai. Dan kalau freelancer tunggal sakit, pindah kerja, atau menghilang di tengah proyek, tidak ada orang kedua yang paham kodenya. Proyek berhenti total. Di tim, ada orang lain yang bisa melanjutkan.

Bukan berarti freelancer selalu pilihan buruk. Untuk aplikasi kecil dengan risiko rendah, freelancer yang bagus bisa sangat masuk akal. Tapi untuk sistem yang dipakai operasional harian bisnis Anda, sebagian dari selisih harga itu adalah harga dari tidak bergantung pada satu orang.

Kualitas yang tidak kelihatan di demo

Dua aplikasi bisa terlihat identik saat demo. Tampilan mirip, fitur jalan, tombol berfungsi. Yang membedakan harganya justru hal-hal yang tidak muncul di layar presentasi.

Pertama, keamanan. Apakah password disimpan dengan benar, apakah aplikasi tahan terhadap serangan umum seperti SQL injection, apakah data pelanggan Anda tidak bocor lewat celah yang sudah lama dikenal. Mengerjakan ini butuh waktu dan keahlian, dan hasilnya tidak kelihatan sama sekali sampai ada insiden.

Kedua, backup dan pemulihan. Aplikasi murah sering tidak punya backup otomatis. Semuanya baik-baik saja sampai server bermasalah dan data transaksi bertahun-tahun hilang dalam satu malam.

Ketiga, kemampuan menangani banyak user. Aplikasi yang lancar dipakai dua orang saat demo bisa melambat parah saat dipakai lima puluh kasir di jam sibuk. Membuat aplikasi yang kuat di beban tinggi butuh arsitektur yang dipikirkan sejak awal, bukan tambalan belakangan.

Keempat, kode yang bisa dirawat. Kode yang rapi dan terdokumentasi membuat penambahan fitur di tahun kedua jadi murah dan cepat. Kode yang asal jadi membuat setiap perubahan kecil terasa seperti operasi besar, dan sering kali developer lain menolak menyentuhnya. Anda tidak bisa melihat perbedaan ini di demo. Anda baru merasakannya setahun kemudian.

Teknologi dan infrastruktur di baliknya

Cara vendor membangun aplikasi juga sangat menentukan harga. Ada vendor yang memakai template jadi atau platform no-code, lalu menyesuaikan seperlunya. Ada yang membangun dari nol sesuai proses bisnis Anda. Keduanya sah, tapi harganya jelas beda jauh.

Template dan no-code cepat dan murah di awal. Cocok kalau kebutuhan Anda memang standar. Masalah muncul kalau proses bisnis Anda tidak persis sama dengan asumsi template. Anda yang akhirnya menyesuaikan cara kerja ke aplikasinya, bukan sebaliknya. Beberapa platform no-code juga mengikat Anda pada biaya langganan yang terus berjalan, dan aplikasi tidak bisa dipindah keluar dari platform itu.

Bangun dari nol lebih mahal karena semua dibuat mengikuti alur kerja Anda. Tapi hasilnya milik Anda sepenuhnya dan bisa dikembangkan ke arah mana pun.

Infrastruktur juga sering luput dari perbandingan. Server yang layak untuk aplikasi bisnis, dengan spesifikasi cukup, monitoring, dan backup, biayanya berbeda jauh dengan hosting murah yang sebenarnya untuk website profil. Sebagian vendor memasukkan biaya server yang layak ke penawaran. Sebagian memakai yang paling murah supaya angka penawarannya menang. Angka totalnya jadi tidak sebanding, padahal kelihatannya sama-sama “sudah termasuk server”.

Layanan setelah rilis, dan apa yang dipotong vendor banting harga

Aplikasi itu bukan proyek yang selesai saat serah terima. Bug pasti ada, kebutuhan pasti berkembang, dan sistem bisa mati di waktu yang paling tidak enak. Di sinilah penawaran antar vendor sering beda isi walau beda harganya tidak kelihatan di halaman depan proposal.

Hal yang perlu Anda cek: berapa lama garansi bug setelah rilis, apakah ada paket maintenance bulanan, dan seberapa cepat vendor merespons kalau sistem down saat operasional. Vendor yang menjanjikan respons cepat harus menyiapkan orang untuk siaga, dan itu ada biayanya. Vendor yang tidak menjanjikan apa-apa memang bisa lebih murah, karena setelah serah terima Anda pada dasarnya sendirian.

Lalu soal banting harga. Kami akan jujur di sini, karena polanya hampir selalu sama. Vendor yang menawar jauh di bawah pasar jarang memotong fitur, karena fitur itu yang dilihat klien. Yang dipotong adalah hal-hal yang tidak kelihatan: waktu testing dipangkas, dokumentasi tidak dibuat, keamanan dikerjakan seadanya, backup dilewati, dan kode ditulis secepatnya tanpa memikirkan perawatan.

Risikonya jatuh ke Anda, bukan ke vendor. Aplikasi tetap terlihat jadi di hari serah terima. Masalahnya muncul tiga sampai enam bulan kemudian, saat bug bermunculan, data bermasalah, dan vendor aslinya sudah sulit dihubungi. Beberapa klien kami datang persis di titik ini, dan biaya membenahinya sering lebih besar dari selisih harga yang dulu dihemat. Murah di depan bisa jadi mahal di belakang. Bukan karena semua vendor murah nakal, tapi karena angka yang terlalu rendah memang tidak cukup untuk membayar pekerjaan yang utuh.

Cara membandingkan penawaran secara adil

Setelah tahu faktor-faktor di atas, cara membandingkannya jadi lebih jelas. Intinya satu: pastikan Anda membandingkan barang yang sama.

• Samakan scope secara tertulis. Buat daftar fitur yang rinci, termasuk jumlah user, jumlah cabang, dan laporan apa saja yang dibutuhkan. Kirim daftar yang sama ke semua vendor dan minta penawaran mengacu ke daftar itu, bukan ke tafsir masing-masing.
• Tanya apa yang tidak termasuk. Ini pertanyaan yang paling jarang diajukan dan paling banyak membongkar. Apakah testing termasuk. Apakah server dan domain termasuk, dan untuk berapa lama. Apakah training user termasuk. Apakah revisi setelah rilis termasuk, dan sampai kapan. Sebagai pembanding, contoh rincian per komponen untuk aplikasi tingkat menengah kami tulis di artikel biaya pembuatan aplikasi Android dan iOS.
• Tanya siapa yang mengerjakan. Satu orang atau tim. Kalau tim, siapa saja perannya. Kalau orang kuncinya berhalangan, siapa penggantinya.
• Tanya soal garansi dan maintenance. Berapa lama garansi bug, berapa biaya maintenance setelahnya, dan berapa lama waktu respons kalau sistem mati.
• Tanya siapa yang memegang source code. Pastikan sejak awal bahwa source code diserahkan ke Anda, bukan ditahan vendor. Detail apa saja yang harus Anda terima saat proyek selesai sudah kami tulis lengkap di checklist serah terima proyek aplikasi dari vendor.

Dengan lima hal itu tertulis hitam di atas putih, selisih harga antar vendor biasanya langsung bisa dijelaskan. Anda akan lihat vendor mana yang murah karena memang scope-nya kecil, dan mana yang murah karena ada yang dipotong diam-diam.

Kalau Anda sedang membandingkan penawaran dan ingin pembanding yang jelas isinya, silakan lihat layanan pembuatan sistem aplikasi kami. Kami terbiasa merinci scope, apa yang termasuk dan tidak termasuk, serta skema garansi sejak awal. Atau kalau mau lebih cepat, hubungi kami dan bawa penawaran yang sudah Anda terima. Kami bisa bantu membacanya, bahkan kalau akhirnya Anda memilih vendor lain.

Brief website adalah catatan singkat berisi gambaran proyek yang Anda serahkan ke developer sebelum diskusi dimulai. Tidak perlu rumit. Cukup satu sampai dua halaman yang menjawab pertanyaan dasar: website ini untuk apa, isinya apa saja, dan siapa yang berhak memutuskan. Dokumen sesederhana ini sering jadi pembeda antara proyek yang selesai tepat waktu dengan proyek yang molor karena revisi tidak habis-habis.

Ada tujuh hal yang perlu Anda isi sebelum ketemu developer mana pun: tujuan website dalam satu kalimat, dua sampai tiga referensi website yang Anda suka, daftar konten yang sudah siap, daftar halaman yang dibutuhkan, status domain dan hosting, rentang budget beserta target waktu, lalu siapa PIC dan pengambil keputusan. Artikel ini membahas satu per satu, termasuk alasan kenapa developer selalu menanyakan hal-hal itu di awal.

Kenapa brief yang jelas bikin proyek lebih cepat dan murah

Kami menulis ini dari sisi meja yang satunya. Sebagai software house, kami menerima banyak permintaan yang bunyinya kurang lebih sama: “mau bikin website, kira-kira berapa ya?” Pertanyaan itu wajar. Tapi tanpa gambaran proyek, jawaban paling jujur dari developer adalah rentang harga yang lebar, dan biasanya diambil dari sisi yang aman untuk mereka.

Logikanya sederhana. Kalau lingkup pekerjaan kabur, developer akan menebak. Tebakan itu dilapisi buffer supaya mereka tidak rugi kalau ternyata permintaannya membengkak di tengah jalan. Anda yang membayar buffer itu. Sebaliknya, brief yang jelas membuat estimasi lebih presisi, timeline lebih realistis, dan revisi berkurang drastis karena semua pihak membayangkan hasil akhir yang sama sejak awal.

Brief juga menyaring ekspektasi Anda sendiri. Saat menulis tujuan website dalam satu kalimat, banyak calon klien baru sadar bahwa yang mereka butuhkan ternyata lebih sederhana dari bayangan awal. Atau sebaliknya, lebih kompleks. Dua-duanya lebih baik diketahui sebelum kontrak diteken, bukan sesudahnya.

Tujuan website dan referensi yang Anda suka

1. Tujuan website: cukup satu kalimat

Tulis satu kalimat yang menjawab: setelah pengunjung membuka website ini, mereka diharapkan ngapain? Chat ke WhatsApp? Mengisi form penawaran? Membeli langsung? Sekadar percaya bahwa bisnis Anda kredibel sebelum mereka datang ke toko?

Developer menanyakan ini karena satu tujuan utama menentukan hampir semua keputusan desain. Website yang tujuannya “pengunjung chat WA” akan punya tombol WhatsApp di mana-mana dan halaman yang pendek. Website yang tujuannya “pengunjung beli langsung” butuh katalog, keranjang, dan integrasi pembayaran. Struktur, biaya, dan waktu pengerjaannya beda jauh. Kalau tujuannya lebih dari satu, urutkan mana yang paling penting.

2. Referensi: dua sampai tiga website, plus alasannya

Cari dua sampai tiga website yang menurut Anda enak dilihat, lalu tulis kenapa Anda menyukainya. Bagian “kenapa” ini yang paling sering dilewatkan. “Saya suka website A karena bagus” tidak membantu siapa pun. “Saya suka website A karena warnanya kalem dan menunya sedikit” langsung bisa diterjemahkan jadi keputusan desain.

Developer menanyakan referensi bukan untuk meniru, tapi untuk menangkap selera Anda tanpa harus lewat lima putaran revisi desain. Referensi juga tidak harus dari industri yang sama. Website hotel yang rapi bisa jadi acuan untuk website catering, selama Anda bisa menjelaskan bagian mana yang ingin diambil semangatnya.

Konten yang sudah siap dan halaman yang dibutuhkan

3. Cek dulu konten yang sudah Anda punya

Buat daftar sederhana berisi status konten Anda saat ini:

• Logo: sudah ada file aslinya atau baru gambar kecil dari media sosial
• Foto produk atau kegiatan: sudah ada yang layak tampil atau perlu foto ulang
• Teks profil perusahaan: sudah tertulis atau baru ada di kepala
• Daftar layanan atau produk beserta deskripsinya
• Testimoni pelanggan, kalau ada

Kenapa developer peduli soal ini? Karena konten adalah penyebab molor nomor satu di proyek website. Desain bisa selesai dalam dua minggu, lalu website menganggur sebulan menunggu teks profil yang “sebentar lagi jadi”. Kalau dari awal jelas konten mana yang belum ada, developer bisa membantu menyiapkannya atau setidaknya memasukkan waktu tunggunya ke timeline.

4. Daftar halaman yang realistis

Tulis halaman apa saja yang Anda butuhkan. Untuk kebanyakan bisnis, daftarnya tidak panjang: beranda, tentang kami, layanan atau produk, galeri, dan kontak. Hindari jawaban “pokoknya yang lengkap” karena kata lengkap itu bisa berarti lima halaman atau lima puluh halaman, dan harganya jelas beda.

Daftar halaman dipakai developer untuk menghitung lingkup kerja. Setiap halaman butuh desain, konten, dan pengujian. Kalau ragu suatu halaman perlu atau tidak, tanyakan saja saat diskusi. Menghapus halaman dari rencana itu gratis. Menambah halaman setelah proyek jalan hampir selalu ada biayanya.

Domain dan hosting: sudah punya atau belum, atas nama siapa

Poin kelima ini sering dianggap urusan teknis yang bisa dipikirkan nanti. Padahal jawabannya cuma dua pertanyaan: apakah Anda sudah punya domain dan hosting, dan kalau sudah, terdaftar atas nama siapa.

Bagian “atas nama siapa” itu penting. Cukup banyak kasus bisnis yang domainnya didaftarkan atas nama vendor lama atau karyawan yang sudah keluar, lalu kesulitan mengaksesnya saat mau pindah atau perpanjang. Domain adalah alamat bisnis Anda di internet. Idealnya terdaftar atas nama Anda atau perusahaan Anda, dengan akses akun yang Anda pegang sendiri, siapa pun yang mengerjakan websitenya.

Developer menanyakan ini di awal karena memengaruhi rencana kerja. Kalau domain sudah ada, mereka perlu akses untuk mengarahkannya ke server baru. Kalau belum, pembelian domain bisa sekalian diurus, dan Anda tinggal memastikan kepemilikannya jelas sejak hari pertama.

Budget, target waktu, dan siapa yang memutuskan

5. Kenapa jujur soal budget justru menguntungkan Anda

Banyak calon klien menahan angka budget karena takut dimanfaatkan. Kekhawatiran itu bisa dipahami, tapi menyembunyikan budget biasanya malah merugikan. Tanpa angka, developer akan menawarkan paket standar yang belum tentu cocok, atau bolak-balik menyusun ulang penawaran sampai ketemu angka yang pas. Itu buang waktu dua belah pihak.

Dengan rentang budget yang jelas, misalnya lima sampai sepuluh juta, developer yang baik akan menyusun solusi terbaik di dalam rentang itu. Fitur mana yang masuk sekarang, mana yang bisa ditunda ke tahap dua. Kalau kebutuhan Anda memang tidak mungkin dikerjakan dengan budget itu, Anda juga akan tahu lebih cepat, sebelum keluar biaya apa pun. Sepaket dengan budget, tulis juga target waktu: apakah ada momen tertentu seperti pembukaan cabang atau event yang websitenya harus tayang sebelum itu.

6. Tentukan PIC dan pengambil keputusan

Tulis dua nama di brief Anda. Pertama, PIC: orang yang jadi kontak sehari-hari, mengirim materi, dan menjawab pertanyaan developer. Kedua, pengambil keputusan: orang yang kata “oke”-nya bersifat final untuk desain dan konten. Boleh orang yang sama, dan justru lebih sederhana kalau begitu.

Developer menanyakan ini karena revisi yang muter hampir selalu bersumber dari keputusan yang tidak jelas pemiliknya. Desain sudah disetujui PIC, lalu minggu depan dibatalkan pemilik usaha yang baru sempat melihat. Kejadian seperti ini bisa mengulang pekerjaan dua minggu. Kalau pengambil keputusan orangnya sibuk, sepakati saja titik-titik mana yang butuh persetujuannya, misalnya cukup di desain awal dan sebelum tayang.

Contoh brief yang sudah jadi

Supaya kebayang bentuk akhirnya, ini contoh brief fiktif dari sebuah usaha catering rumahan. Perhatikan betapa pendeknya:

• Usaha: Catering Dapur Renjana, melayani nasi kotak dan prasmanan untuk acara kantor dan hajatan di Purwokerto dan sekitarnya.
• Tujuan website: pengunjung melihat daftar paket dan harga, lalu chat ke WhatsApp untuk pesan.
• Referensi: website catering X karena daftar menunya rapi dengan foto besar, website bakery Y karena warnanya hangat dan terasa homey. Tidak suka website yang banyak animasi.
• Konten siap: logo (file dari desainer masih ada), sekitar 40 foto masakan hasil foto sendiri, daftar 6 paket beserta harga. Belum ada: teks profil usaha, testimoni masih berupa screenshot chat.
• Halaman: beranda, daftar paket dan harga, galeri, tentang kami, kontak.
• Domain dan hosting: belum punya. Ingin domain .com atas nama pemilik usaha.
• Budget dan waktu: 4 sampai 7 juta. Target tayang sebelum musim hajatan, sekitar 2 bulan dari sekarang.
• PIC: Rani (admin, pegang WhatsApp usaha). Keputusan final: Bu Sari (pemilik), cukup dilibatkan saat pilih desain dan sebelum website tayang.

Brief seperti ini bisa Anda tulis dalam satu jam. Dengan dokumen ini, developer mana pun bisa langsung memberi estimasi yang masuk akal di pertemuan pertama, bukan janji “nanti kami hitung dulu” yang menggantung berminggu-minggu.

Setelah brief siap, apa langkah berikutnya

Kirim brief Anda ke beberapa penyedia jasa pembuatan website, lalu bandingkan respons mereka. Dari cara developer menanggapi brief, Anda bisa menilai banyak hal: apakah mereka membaca dengan teliti, apakah pertanyaannya menunjukkan pemahaman, dan apakah estimasinya dijelaskan dengan alasan yang jelas.

Satu catatan untuk nanti. Brief yang rapi di awal sebaiknya ditutup dengan serah terima yang rapi di akhir. Setelah proyek berjalan, sempatkan baca checklist serah terima proyek dari vendor supaya Anda tahu apa saja yang wajib Anda terima saat proyek selesai, termasuk akses dan kredensial.

Kalau briefnya sudah jadi dan Anda ingin tahu kira-kira berapa biayanya, silakan kirim brief Anda ke tim Arrazy. Kami akan membalas dengan estimasi biaya dan waktu yang jujur, termasuk kalau menurut kami ada bagian yang sebaiknya disederhanakan dulu. Brief Anda tidak harus sempurna. Yang penting mulai ditulis.

Saat proyek aplikasi selesai, ada lima kelompok hal yang wajib kamu terima dari vendor: akses dan kepemilikan penuh (source code, hosting, domain, database, akun pihak ketiga), dokumentasi teknis, kejelasan legal dan lisensi, kesepakatan garansi serta penanganan bug, dan yang terakhir, kepastian bahwa tidak ada satu pun aset yang “disandera” vendor. Kalau salah satu dari lima ini tidak kamu pegang, proyekmu belum benar-benar selesai, berapa pun invoice yang sudah lunas.

Kami menulis ini dari posisi yang mungkin terdengar aneh: kami sendiri software house. Artinya kami tahu persis celah mana yang sering dimanfaatkan vendor untuk membuat klien bergantung selamanya. Sebagian besar klien baru sadar ada masalah justru saat mau pindah vendor, lalu menemukan bahwa domain bukan atas nama mereka atau source code tidak pernah diserahkan. Artikel ini membocorkan daftar lengkapnya, item per item, supaya kamu bisa menagih hakmu sebelum terlambat.

1. Akses dan Kepemilikan: Ini yang Paling Sering Ditahan

Ini kelompok paling penting sekaligus paling sering bermasalah. Prinsipnya sederhana. Kamu yang bayar, kamu yang punya. Semua akses harus atas nama kamu atau perusahaanmu, bukan atas nama vendor.

• Source code dalam bentuk repository Git, bukan file zip. Ini penting. File zip hanya potret satu momen. Repository Git menyimpan seluruh riwayat perubahan kode, siapa mengubah apa dan kapan. Developer baru yang meneruskan proyekmu akan sangat terbantu oleh riwayat ini. Minta kamu dijadikan owner di GitHub, GitLab, atau Bitbucket, atau minta repository dipindahkan ke akun organisasimu.
• Akun hosting dan domain atas nama kamu. Domain adalah identitas bisnismu. Kalau terdaftar atas nama vendor, secara administratif itu milik mereka. Cek di registrar siapa pemiliknya. Hosting juga sama. Idealnya kamu yang bikin akun, vendor hanya diberi akses kerja yang bisa dicabut kapan saja.
• Akses database. Data pelanggan, transaksi, dan konten adalah asetmu yang paling berharga. Minta kredensial database plus cara melakukan backup. Tanpa ini, datamu ada di tangan orang lain.
• Akun layanan pihak ketiga. Payment gateway, API pengiriman, layanan email, push notification, Google Maps, dan sejenisnya. Semua akun ini harus dibuat dengan email perusahaanmu. Khusus payment gateway ini krusial karena menyangkut uang yang mengalir ke rekening. Kalau akunnya milik vendor, uangmu lewat jalur mereka.
• Password admin aplikasi. Terdengar sepele, tapi banyak klien tidak pernah pegang akses admin tertinggi di sistemnya sendiri. Minta akun super admin, lalu ganti password-nya setelah serah terima.

Satu tips praktis. Jangan tunggu hari serah terima untuk mengecek semua ini. Cicil dari awal proyek. Akun-akun dibuat atas nama kamu sejak hari pertama, jauh lebih mudah daripada proses migrasi di akhir.

2. Dokumentasi: Bekal untuk Developer Setelahnya

Aplikasi tanpa dokumentasi itu seperti mesin tanpa buku manual. Masih jalan, tapi begitu ada masalah, tidak ada yang tahu harus mulai dari mana. Dokumentasi yang layak kamu minta minimal mencakup tiga hal.

• Cara deploy. Langkah-langkah memasang aplikasi dari nol sampai jalan di server. Termasuk kebutuhan server, versi bahasa pemrograman, dan perintah yang harus dijalankan. Tanpa ini, pindah server bisa jadi proyek tersendiri yang mahal.
• Daftar environment variable. Ini konfigurasi rahasia seperti kunci API, kredensial database, dan setting per server. Biasanya tidak ikut tersimpan di repository demi keamanan. Justru karena itu harus diserahkan terpisah dan tercatat. Aplikasi yang kodenya lengkap tapi environment variable-nya hilang tetap tidak bisa jalan.
• Dokumentasi API, kalau ada. Kalau aplikasimu punya backend yang diakses aplikasi mobile atau sistem lain, minta dokumentasi endpoint-nya. Cukup format sederhana seperti Postman collection atau Swagger. Ini menghemat berminggu-minggu kerja developer berikutnya.

Dokumentasi tidak perlu setebal skripsi. Satu file README yang jujur dan up to date jauh lebih berharga daripada dokumen 50 halaman yang tidak pernah diperbarui.

3. Legal dan Lisensi: Hitam di Atas Putih

Bagian ini sering dilewati karena dianggap formalitas. Padahal di sinilah sengketa biasanya bermula.

• Kepemilikan kode harus tertulis di kontrak. Di banyak yurisdiksi, tanpa klausul penyerahan hak, hak cipta kode secara default bisa tetap di tangan pembuatnya. Jadi jangan berasumsi. Pastikan kontrak menyebut jelas bahwa hasil kerja, termasuk source code, menjadi milik klien setelah pelunasan.
• Lisensi library dan komponen berbayar. Hampir semua aplikasi modern dibangun di atas library pihak ketiga. Sebagian gratis, sebagian berbayar per proyek atau per tahun. Minta daftar komponen berbayar yang dipakai, atas nama siapa lisensinya, dan berapa biaya perpanjangannya. Kamu tidak mau kaget aplikasi berhenti berfungsi karena lisensi template atau plugin kedaluwarsa.
• Perjanjian maintenance yang terpisah dan jelas. Setelah garansi habis, siapa yang merawat sistem? Berapa biayanya, apa saja cakupannya, dan bagaimana cara mengakhirinya? Perjanjian maintenance yang bagus juga menyebut apa yang terjadi kalau kontrak berakhir. Yang penting, maintenance harus jadi pilihan, bukan keterpaksaan karena hanya vendor itu yang pegang akses.

4. Serah Terima Teknis: Garansi, Bug, dan Batas Revisi

Aplikasi yang baru rilis hampir pasti masih punya bug. Itu normal. Yang tidak normal adalah kalau tidak ada kesepakatan soal siapa yang memperbaikinya dan sampai kapan. Sebelum tanda tangan berita acara serah terima, pastikan hal-hal berikut sudah disepakati.

• Masa garansi bug. Di industri ini umumnya 1 sampai 3 bulan setelah go live. Dalam periode ini, error yang berasal dari kode vendor diperbaiki tanpa biaya. Pastikan definisinya jelas: garansi mencakup bug, bukan fitur baru.
• Format pelaporan bug. Sepakati lewat mana bug dilaporkan, entah grup chat, email, atau tools tiket. Sepakati juga informasi apa yang perlu kamu sertakan, misalnya screenshot dan langkah untuk mereproduksi masalah, plus estimasi waktu respons. Tanpa jalur yang jelas, laporan bug gampang hilang dan dua pihak saling menunggu.
• Batas revisi. Bedakan tiga hal ini sejak awal: bug (masuk garansi), revisi minor (biasanya ada jatahnya di kontrak), dan fitur baru (kerjaan baru dengan biaya baru). Perselisihan klien dan vendor paling sering terjadi karena tiga hal ini dicampur aduk. Vendor merasa dimintai kerja gratis, klien merasa ditagih untuk hal yang seharusnya beres.

Minta juga sesi serah terima teknis, semacam walkthrough. Vendor menjelaskan arsitektur sistem ke kamu atau ke tim IT-mu, direkam kalau perlu. Satu jam sesi ini bisa menyelamatkanmu dari kebingungan bertahun-tahun.

5. Tanda Bahaya: Pola Vendor yang Perlu Kamu Waspadai

Sekarang bagian yang jarang dibahas terbuka. Ada beberapa pola yang berulang kali kami dengar dari klien yang datang setelah kecewa dengan vendor sebelumnya. Polanya mirip di mana-mana.

• Source code disandera. Vendor menolak menyerahkan kode dengan alasan “itu aset kami” atau “nanti disalahgunakan”. Padahal kontrak tidak menyebut demikian, atau bahkan tidak ada kontrak sama sekali. Akibatnya klien tidak bisa pindah ke developer lain tanpa membangun ulang dari nol.
• Domain dan hosting atas nama vendor. Saat hubungan baik, ini tidak terasa. Saat hubungan memburuk atau vendor menghilang, domainmu ikut hilang. Ada bisnis yang terpaksa ganti alamat website, ganti email perusahaan, dan kehilangan reputasi yang sudah dibangun bertahun-tahun hanya karena domain tidak pernah atas nama mereka.
• Biaya tebusan di akhir. Modusnya, biaya proyek di awal terlihat murah. Begitu kamu mau memutus hubungan, muncul tagihan “biaya migrasi”, “biaya rilis source code”, atau angka perpanjangan maintenance yang tiba-tiba melonjak. Murah di depan, mahal saat mau keluar.
• Semua serba lisan. Vendor yang menghindari kontrak tertulis dan berita acara serah terima biasanya sedang menjaga ruang abu-abu. Ruang abu-abu itu hampir selalu menguntungkan pihak yang pegang akses, dan itu bukan kamu.

Perlu adil juga. Tidak semua vendor yang menahan sesuatu berarti nakal. Kadang pembayaran memang belum lunas, dan menahan serah terima sampai pelunasan itu wajar. Yang jadi masalah adalah ketika kewajibanmu sudah beres tapi hakmu tidak kunjung diserahkan.

Pertanyaan yang Sebaiknya Kamu Ajukan Sebelum Kontrak

Semua masalah di atas jauh lebih murah dicegah daripada diperbaiki. Sebelum tanda tangan kontrak pembuatan sistem atau aplikasi, ajukan pertanyaan-pertanyaan ini ke calon vendormu.

• Setelah lunas, apakah source code jadi milik saya sepenuhnya, dan diserahkan dalam bentuk repository Git?
• Domain, hosting, dan semua akun layanan pihak ketiga akan didaftarkan atas nama siapa?
• Kalau suatu saat saya pindah vendor, apa saja yang saya bawa dan adakah biaya tambahan untuk itu?
• Berapa lama masa garansi bug, dan apa saja cakupannya?
• Apa saja dokumentasi yang saya terima di akhir proyek?
• Adakah komponen berbayar di dalam sistem, dan atas nama siapa lisensinya?

Perhatikan bukan hanya jawabannya, tapi cara menjawabnya. Vendor yang sehat akan menjawab lugas karena pertanyaan ini memang standar. Vendor yang berbelit atau tersinggung saat ditanya soal kepemilikan, itu sinyal yang layak kamu catat.

Posisi Kami Soal Ini

Di Arrazy Inovasi, prinsipnya sederhana. Kode yang kamu bayar adalah milikmu. Repository, akses hosting, database, dan dokumentasi kami serahkan saat serah terima, dan klien bebas melanjutkan dengan tim mana pun. Kami lebih memilih klien bertahan karena puas dengan hasil kerja, bukan karena tidak punya pilihan untuk pergi.

Kalau kamu sedang menghadapi serah terima proyek dan ragu apa saja yang berhak kamu minta, atau sedang menimbang pindah vendor, hubungi kami. Ceritakan situasimu, dan kami bantu petakan langkahnya. Konsultasi awal tidak dipungut biaya, dan tidak ada kewajiban lanjut.