Stack yang Dibilang 'Membosankan' Itu Justru yang Meloloskan Due Diligence Akuisisi Kami

Due diligence teknis biasanya momen paling menegangkan dalam proses akuisisi — bukan karena kodenya pasti jelek, tapi karena enggak ada yang benar-benar tahu apa yang bakal ditemukan sampai orang asing mulai nge-clone repo dan baca commit history dari hari pertama. Tim pembeli sudah mengalokasikan lima hari kerja penuh buat ini, lengkap dengan dua engineer senior yang katanya "biasa nemuin hal-hal yang bikin deal batal di menit terakhir." Punya kami selesai dalam waktu kurang dari dua hari. Di Slack channel bersama yang dibuat khusus buat proses ini, lead engineer-nya nulis satu kalimat yang aku screenshot dan masih tersimpan di galeri sampai sekarang: "Ini pertama kalinya dalam tiga due diligence bulan ini aku enggak nemu dependency yang udah deprecated sejak 2021."

Keputusan Membosankan yang Dulu Terasa Seperti Kemunduran

Tiga tahun sebelumnya, keputusan itu sama sekali enggak terasa membanggakan. Dua kali tim kecilku — waktu itu baru bertiga — ngajak pindah ke framework frontend yang lagi ramai dibahas di Twitter, alasannya bukan teknis sama sekali: "biar gampang hiring, orang-orang maunya nulis CV dengan skill yang lagi dicari." Aku nolak dua kali. Bukan karena framework itu buruk, tapi karena setiap kali aku bandingin, keuntungannya cuma di persepsi, sementara ongkosnya nyata — migrasi beberapa bulan, dokumentasi internal yang harus ditulis ulang, dan tim yang harus belajar pola baru di tengah kami masih ngejar product-market fit. Aku pilih tetap di stack yang "boring": server-rendered dengan satu framework backend yang sudah stabil lebih dari satu dekade, dependency eksternal seminim mungkin, dan satu aturan yang nggak pernah aku tawar — setiap modul baru harus punya test sebelum di-merge, enggak peduli deadline-nya sedang mepet.

Waktu itu rasanya kayak nahan tim dari kemajuan. Satu engineer bahkan resign sebagian karena alasan itu — bilang dia pengen kerja di tempat yang "stack-nya lebih modern." Aku enggak bisa membantah dia salah soal preferensi pribadinya. Aku cuma enggak tahu keputusan itu bakal dites ulang, dengan taruhan jauh lebih besar, tiga tahun kemudian.

Due Diligence Bukan Soal Fitur, tapi Soal Risiko yang Enggak Kelihatan Sehari-hari

Yang baru aku ngerti setelah ngobrol panjang sama tim audit: due diligence teknis itu hampir enggak pernah nanya "fitur apa yang kalian punya." Pertanyaannya selalu soal risiko yang enggak muncul di demo — siapa satu-satunya orang yang ngerti bagian infra tertentu (bus factor), berapa banyak dependency yang udah enggak di-maintain lagi oleh upstream-nya, apakah ada test yang jalan otomatis atau cuma mengandalkan "udah dicoba manual kok," dan apakah dokumentasi deployment-nya bisa diikuti orang yang belum pernah pegang sistemnya sama sekali. Mereka nyeritain, tanpa nyebut nama perusahaan lain, bahwa dua kandidat akuisisi sebelum kami batal di tahap ini — satu karena separuh backend-nya ditulis pakai library yang maintainer-nya udah berhenti ngerespons isu GitHub lebih dari setahun, satu lagi karena coverage test-nya cuma 12 persen dan separuh dari itu test yang gagal tapi dibiarin karena "udah biasa gitu."

MacBook dengan baris-baris kode di layarnya di atas meja kerja yang sibuk
MacBook dengan baris-baris kode di layarnya di atas meja kerja yang sibuk

Buat mereka, "boring" itu bukan kata negatif. Stack yang stabil dan sudah teruji selama bertahun-tahun berarti lebih sedikit kejutan, lebih mudah diprediksi biaya maintenance-nya pasca-akuisisi, dan — ini yang paling sering mereka tekankan — lebih sedikit risiko satu orang kunci keluar lalu sistem jadi enggak ada yang ngerti. Fitur yang lebih canggih dari kompetitor bisa dibangun belakangan. Codebase yang jadi kotak hitam enggak bisa dibeli ulang semudah itu.

Minggu yang Berubah Jadi Alasan Deal Ditutup Lebih Cepat dari Jadwal

Karena audit selesai lebih cepat dari jadwal, tim legal di kedua pihak jadi punya waktu ekstra buat negosiasi detail kontrak yang biasanya diburu-buru di hari-hari terakhir — klausul earn-out, masa transisi tim, sampai jaminan soal lisensi open-source yang kami pakai. Lead engineer yang sama bilang ke tim M&A mereka bahwa risiko teknis dari sisi kami "paling rendah dari semua target yang pernah mereka review tahun ini," dan kalimat itu — bukan pitch deck, bukan proyeksi pertumbuhan — yang jadi argumen utama waktu valuasi dibahas ulang di menit-menit akhir. Deal yang awalnya diperkirakan butuh tiga minggu buat kelar, ditandatangani sepuluh hari lebih cepat.

Laptop abu-abu dan hitam di atas permukaan meja
Laptop abu-abu dan hitam di atas permukaan meja

Engineer yang resign tiga tahun lalu? Aku kirim pesan singkat waktu deal ini resmi, bukan buat menyindir, tapi karena aku jujur pengen dia tahu alasannya sudah punya jawaban: stack yang dia anggap ketinggalan zaman itu sekarang jadi satu-satunya alasan kontrak terbesar dalam hidup perusahaan ini kelar tanpa drama.

Takeaway

Kalau kamu bangun sesuatu yang suatu hari mungkin diakuisisi, diaudit investor, atau sekadar jadi vendor tetap buat klien enterprise, jangan anggap "stack yang membosankan" sebagai pilihan yang kalah dari yang trendi. Due diligence enggak menilai seberapa modern tools-mu — dia menilai seberapa kecil risiko yang enggak kelihatan sehari-hari: dependency yang rapuh, dokumentasi yang cuma ada di kepala satu orang, dan test yang dilewati karena "udah biasa gitu." Keputusan yang terasa seperti kemunduran hari ini — menolak migrasi, ngotot nulis test, milih library yang sudah teruji daripada yang lagi ramai dibahas — baru kelihatan nilainya pas ada orang asing yang nge-audit semuanya dari nol, dan waktu itu datang lebih cepat dari yang kamu kira.

---

Sumber gambar cover: Glenn Carstens-Peters di Unsplash Sumber gambar: Christopher Gower di Unsplash Sumber gambar: Ales Nesetril di Unsplash

The conversation 0

No comments yet. Start the conversation.

Comments are reviewed before appearing. Links are masked.