Checklist Saya Sebelum Terima Klien Freelance Baru

Tiap freelancer pasti punya minimal satu proyek yang disesalin. Punya saya ngajarin bahwa scope teknis itu nggak pernah jadi bagian yang beresiko — saya bisa estimasi kode. Yang nggak bisa saya estimasi dari awal itu hubungan sama klien-nya sendiri, dan pas itu udah keliatan jelas, saya udah tiga minggu jalan dan udah komit secara finansial. Checklist ini yang beneran saya jalanin sekarang sebelum bilang iya ke apapun, hasil belajar murni dari kontrak-kontrak yang berantakan.

Klien bisa jelasin masalahnya, atau cuma solusinya? Ini filter pertama dan nangkep lebih banyak dari yang kamu kira. Klien yang bilang “saya butuh dashboard React dengan enam fitur ini” udah mutusin solusinya duluan tanpa perlu ngerti masalah yang lagi diselesaikan. Klien yang bilang “tim support kami ngabisin dua jam sehari nyocokin manual dua spreadsheet” itu lagi jelasin masalah, dan itu orang yang beneran bisa saya bantu, karena masih ada ruang buat push back kalau ternyata dashboard enam fitur itu bentuk yang salah buat masalah sebenarnya. Kalau seseorang cuma bisa ngomong pakai bahasa solusi dan jadi defensif pas saya tanya “kenapa pendekatan ini spesifiknya,” itu sinyal scope-nya bakal berubah-ubah terus, karena sebenarnya belum ada kesepakatan soal apa yang lagi diselesaikan.

Siapa yang sign off, dan beneran berapa orang itu? Sekarang saya tanya langsung: “kalau ini udah selesai, siapa yang mutusin sesuai standar atau nggak?” Kalau jawabannya satu orang, bagus. Kalau jawabannya samar-samar — “nanti timnya yang review” — itu red flag buat scope creep pelan-pelan di mana setiap stakeholder yang nggak pernah ditanya dari awal, tiba-tiba punya opini pas review final. Ini beneran kejadian di satu proyek portfolio site: orang yang nge-hire saya suka banget, terus tiga orang lain di perusahaan itu baru liat pertama kali pas launching, dan masing-masing minta perubahan yang beda-beda. Nggak ada satupun dari itu ada di brief awal karena ketiga orang itu emang nggak pernah dilibatin pas ngedefinisiin proyeknya.

Struktur pembayarannya gimana, dan mereka udah pernah bayar freelancer sebelumnya? Bukan pertanyaan jebakan — saya tanya terus terang aja. Klien yang udah pernah kerja sama kontraktor biasanya punya ritme normal: deposit di awal, pembayaran per milestone, cadence invoice yang jelas. Klien yang baru pertama kali nggak otomatis jelek, tapi saya belajar buat lebih eksplisit soal terms pembayaran secara tertulis sama mereka, karena “nanti dibayar kalau udah selesai” dari orang yang belum pernah ngatur freelancer itu bukan niat jahat, cuma asumsi yang mereka sendiri belum sadar itu masalah. Minta deposit sebelum mulai bukan soal nggak percaya — itu tes kecil apa proses pembayarannya beneran jalan sebelum taruhannya makin gede.

Timeline-nya emang preferensi mereka, atau beneran ada deadline eksternal? “Kami butuh ini dalam tiga minggu” bisa beda banget artinya tergantung itu preferensi atau deadline eksternal yang keras — deck fundraising, launching konferensi, tanggal kontraktual sama klien mereka sendiri. Sekarang saya tanya langsung, karena preferensi yang lunak masih ada ruang buat negosiasi scope kalau ada yang makan waktu lebih lama dari perkiraan, sedangkan deadline eksternal yang keras nggak ada ruang itu. Tau mana yang lagi saya hadapin ngubah cara saya rencanain seluruh engagement-nya, dan ngubah apa yang saya berani janjiin di minggu pertama.

Mereka udah punya infrastruktur, atau saya yang bangun fondasinya dari nol? Ini mempengaruhi scope sekaligus beban kerja saya sendiri lebih dari yang biasanya klien sadari. Klien yang udah punya VPS, udah punya CI pipeline, udah punya design system itu proyek yang beda banget sama yang saya juga harus bangun hosting-nya, mutusin proses deploy-nya, milih semua dependency dari nol. Dua-duanya nggak salah, tapi harganya beda, timeline-nya beda, dan saya udah lebih dari sekali under-quote gara-gara nggak nanya ini dari awal.

Saya bisa bayangin nggak hari Selasa biasa kerja sama orang ini? Ini item paling “nggak profesional” di list-nya dan justru paling berguna. Semua di atas bisa lolos di atas kertas tapi hubungannya tetep bikin capek sehari-hari — Slack ngeping terus di luar jam yang disepakatin, feedback yang datang sebagai rewrite ulang brief-nya bukan catatan atas hasil kerja, atau nada di email-email awal yang udah keliatan nggak sabaran padahal kerjaannya belum mulai. Sekarang saya lebih percaya insting ini dibanding dulu. Kontrak-kontrak yang saya sesalin bukan yang punya masalah teknis susah. Itu yang dari percakapan awalnya udah kerasa agak ganjil, dan saya sendiri yang ngeyakinin diri buat nggak notice itu karena scope-nya kedengaran menarik atau rate-nya bagus.

Satu hal lagi yang saya tambahin setelah pengalaman buruk: saya tanya apa yang terjadi kalau proyeknya dibatalin di tengah jalan. Bukan karena saya ngarepin itu kejadian, tapi karena cara orang jawab itu ngasih tau banyak. Klien yang udah mikirin ini bakal jawab kayak “kamu invoice buat milestone yang lagi jalan terus kita pisah jalan” — jelas, adil, udah dipikirin. Klien yang jadi nggak nyaman atau ngeremehin pertanyaan ini (“nggak bakal kejadian kok, kenapa ngomongin ini”) itu orang yang belum beneran mikirin gimana exit yang adil, yang jadi jauh lebih penting justru pas keadaan beneran berantakan. Saya nambahin ini ke list setelah satu proyek dibatalin gara-gara reorg internal di perusahaan klien, tanpa rencana sama sekali gimana ngurus kerjaan yang udah dikerjain. Akhirnya kelar juga, tapi makan waktu seminggu bolak-balik yang nggak nyaman, yang sebenarnya bisa dihindarin total kalau ada obrolan lima menit dari awal.

Semua ini bukan soal jadi paranoid ke klien baru — kebanyakan orang yang saya ajak kerja lolos semua ini tanpa saya perlu nanya langsung sebagian besarnya, karena keluar sendiri natural pas obrolan pertama. Checklist ini bukan tembok buat nolak orang. Ini cuma list pertanyaan yang harusnya saya tanyain keras-keras dulu, bukan cuma nebak-nebak jawabannya, dulu waktu rate bagus dan stack yang menarik cukup buat bikin saya lewatin itu semua.