Saya pernah berada di kedua sisi meja ini, sebagai vendor yang mempresentasikan penawaran dan sebagai pihak yang mengevaluasi siapa yang layak diajak kerja sama. Pertanyaan yang perlu diajukan ke tech partner sebelum menandatangani apa pun sebenarnya tidak rumit, tapi hampir tidak ada yang menanyakannya di pertemuan pertama, dan begitu jawabannya benar-benar penting, kontrak sudah terlanjur diteken.

Sebagian besar seleksi vendor berfokus pada harga, portofolio, dan timeline. Ketiganya penting, tapi itu justru hal-hal yang paling mudah dipoles saat presentasi. Pertanyaan-pertanyaan di bawah ini jauh lebih sulit dipoles, karena vendor yang memang kompeten di bidang ini punya jawaban yang jelas, sementara vendor yang tidak kompeten akan mengelak, mengalihkan, atau memberi jawaban yang terdengar meyakinkan tapi sebenarnya tidak mengikat apa pun.

Tanyakan ini sebelum Anda tanda tangan, bukan setelah milestone pertama molor.

1. Siapa yang benar-benar menulis kode, dan di mana mereka berada?

Minta jawaban yang spesifik. Apakah orang yang ada di meja ini, tim dengan nama jelas, atau sekadar "pool engineer kami" yang berganti-ganti tiap proyek? Jawaban yang kabur di sini adalah pertanda kualitas yang tidak konsisten ke depannya. Partner yang baik bisa menyebutkan dengan tepat siapa saja yang ada di timnya dan apa saja yang pernah mereka kerjakan.

2. Siapa pemilik kode dan IP setelah kerja sama berakhir?

Ini pertanyaan paling krusial dan paling sering dilewatkan oleh pemilik bisnis. Kalau kontrak diam atau kabur soal kepemilikan IP, asumsikan posisi default vendor menguntungkan mereka, bukan Anda. Anda perlu klausul yang eksplisit: Anda yang memiliki kode, dokumentasi, dan hak untuk membawanya ke developer lain tanpa batasan apa pun. Kalau vendor ragu-ragu di sini, keraguan itu sendiri sudah jadi jawabannya.

Ini terkait langsung dengan keputusan build-versus-buy yang mestinya dihadapi pemilik bisnis bahkan sebelum memilih partner. Kalau Anda belum menjalankan framework itu, ada baiknya dilakukan lebih dulu: Build vs Buy Software: Kerangka Keputusan untuk Pemilik Bisnis.

3. Apa yang terjadi kalau kita berbeda pendapat soal scope?

Setiap proyek pasti mengalami momen di mana klien mengira sesuatu sudah termasuk dalam scope, sementara vendor menganggapnya sebagai change request. Minta mereka menjelaskan, secara konkret, bagaimana situasi ini diselesaikan. Partner yang baik punya proses yang jelas: dokumen scope yang tertulis, prosedur change request, dan satu orang bernama yang punya wewenang memutuskan. Partner yang buruk hanya bilang "nanti kita cari jalan tengah," yang artinya siapa pun yang punya leverage lebih besar yang menang, dan di awal hubungan kerja, biasanya itu mereka.

4. Ceritakan satu proyek yang gagal. Apa yang terjadi?

Ini prediktor terbaik dari seluruh daftar ini, dan itu karena caranya menjawab, bukan sekadar isi jawabannya.

Vendor dengan pengalaman nyata akan menceritakan kisah yang spesifik: apa yang salah, apa yang mereka lewatkan, apa yang mereka ubah setelahnya. Mereka akan mengakui bagian yang memang kesalahan mereka. Vendor yang bilang "kami tidak pernah punya proyek gagal" atau memberi cerita di mana klien sepenuhnya disalahkan sedang menunjukkan bagaimana mereka akan membicarakan proyek Anda kalau nanti ada yang salah. Semua orang pernah gagal di suatu titik. Yang jadi penanda bukan kegagalannya, tapi kejujuran soal itu.

5. Bagaimana cara Anda menyampaikan kabar buruk di tengah proyek?

Tanyakan ini secara langsung: kalau ada deadline yang akan molor, kapan kami akan tahu, dari siapa, dan seberapa jauh sebelumnya? Vendor yang bagus dalam eksekusi menyampaikan kabar buruk lebih awal, disertai rencana, bukan sekadar permintaan maaf. Vendor yang kurang bagus cenderung menghilang begitu deadline mendekat, lalu memunculkan masalahnya di detik-detik terakhir, saat pilihan Anda sudah paling terbatas.

6. Seperti apa 30 hari pertama, secara konkret?

Anda ingin jawaban yang spesifik: sesi discovery, audit teknis, dokumen scope, milestone kickoff. Jawaban yang kabur ("kami akan mengenal bisnis Anda dulu") berarti bulan pertama tidak terstruktur dan Anda yang membayar kurva belajar mereka.

7. Siapa yang jadi point of contact kami sebenarnya, dan seberapa cepat mereka bisa dihubungi?

Minta nama, bukan sekadar tim. Tanyakan seberapa cepat orang itu merespons pesan, dan apa yang terjadi kalau dia tidak bisa dihubungi selama seminggu. Ini lebih penting dari kedengarannya, karena perbedaan antara kerja sama yang lancar dan yang bikin frustrasi biasanya terletak pada seberapa cepat pertanyaan dijawab, bukan seberapa bagus kodenya.

8. Bisakah kami bicara dengan klien sebelumnya, idealnya yang pengalamannya tidak sepenuhnya mulus?

Referensi yang cuma pernah mengalami hal-hal lancar itu berguna tapi terbatas. Referensi dari proyek yang sempat meleset lalu berhasil diselesaikan justru memberi gambaran jauh lebih jelas soal bagaimana vendor bekerja di bawah tekanan, kondisi yang sebenarnya paling menentukan.

9. Bagaimana posisi Anda soal dokumentasi dan handover?

Tanyakan dokumentasi apa saja yang akan Anda terima: keputusan arsitektur, instruksi setup, akses environment, kredensial admin. Partner yang merencanakan hubungan jangka panjang yang sehat mendokumentasikan sambil berjalan. Partner yang berencana membuat dirinya sulit tergantikan menyimpan pengetahuan itu hanya di kepala mereka sendiri, yang jadi jebakan entah itu disengaja atau tidak.

10. Bagaimana Anda menentukan harga untuk change request, dan bisa kami lihat contohnya?

Setiap proyek pasti berubah scope-nya. Minta contoh nyata bagaimana change request sebelumnya diestimasi dan diberi harga, bukan sekadar kebijakan di atas kertas. Ini menunjukkan logika harga mereka sekaligus seberapa besar friksi yang bisa Anda perkirakan begitu scope-nya bergeser, dan itu pasti terjadi.

Sinyal di balik kesepuluh pertanyaan ini

Tidak satu pun dari pertanyaan ini soal kemampuan teknis, dan itu memang disengaja. Sebagian besar vendor yang ada di meja evaluasi Anda bisa menulis kode yang kompeten. Pembedanya adalah bagaimana mereka menangani kepemilikan, perbedaan pendapat, dan kabar buruk, karena momen-momen itulah yang menentukan apakah hubungan kerja bertahan lewat milestone pertama. Kalau Anda ingin cara terstruktur untuk menimbang jawaban vendor sekaligus mempertimbangkan opsi membangun in-house lebih dulu, tulisan terkait soal itu ada di sini: Build vs Buy Software: Kerangka Keputusan untuk Pemilik Bisnis.

Kesimpulan

Harga dan portofolio membawa Anda ke shortlist. Sepuluh pertanyaan ini yang menentukan siapa yang benar-benar bisa dipercaya dengan codebase dan budget Anda saat keadaan mulai sulit, dan itu pasti akan terjadi. Kalau cuma sempat menanyakan satu, tanyakan pertanyaan nomor 4 lebih dulu. Cara seseorang bicara soal kegagalannya sendiri memberi tahu Anda hampir semua yang perlu diketahui sebelum tanda tangan. Kalau Anda sedang mengevaluasi tech partner saat ini dan ingin pendapat teknis kedua atas jawaban-jawaban yang Anda terima, itu obrolan yang layak dilakukan di /partner.