Saya telah mengikuti percakapan akuisisi di mana keuangan diaudit selama berminggu-minggu dan tumpukan teknologi mendapat panduan sore hari dengan slide deck. Uji tuntas teknologi dianggap sebagai formalitas, sesuatu yang ditandatangani oleh CTO dengan cepat sehingga kesepakatan dapat diselesaikan. Lalu enam bulan kemudian pembeli tersebut menemukan bahwa tidak ada seorang pun yang benar-benar memiliki kode sumber tersebut, atau seorang insinyur yang memahami sistem tersebut berhenti begitu saja. Pada saat itu, hal tersebut bukanlah temuan uji tuntas, melainkan tuntutan hukum atau pembangunan kembali.

Jika Anda mengakuisisi bisnis, mengambil saham ekuitas, atau memasuki kemitraan teknis yang mendalam, perangkat lunak sering kali merupakan aset sebenarnya, bukan fungsi pendukung. Uji tuntas teknologi memerlukan ketelitian yang sama seperti neraca, karena basis kode yang rusak atau lisensi yang hilang dapat menghapus nilai yang Anda pikir telah Anda beli.

Temuan paling umum: tidak ada yang memiliki kode tersebut

Ini kedengarannya tidak masuk akal sampai Anda melihatnya tiga kali. Seorang pendiri menyewa pengembang lepas atau agen outsourcing bertahun-tahun yang lalu. Kontrak tersebut, jika ada, tidak pernah menetapkan hak kekayaan intelektual secara eksplisit. Kode tersebut berada di akun GitHub pribadi, bukan akun perusahaan. Domain, listingan toko aplikasi, atau kredensial server produksi didaftarkan menggunakan email pribadi individu, bukan email perusahaan.

Semua ini tidak muncul di demo. Ini muncul ketika Anda mencoba mentransfer kepemilikan setelah penandatanganan, dan orang yang membangunnya tidak dapat dihubungi atau meminta uang untuk menyerahkan akses yang seharusnya tidak mereka pertahankan.

Sepuluh pertanyaan dan seperti apa jawaban buruknya

Tanyakan hal ini secara langsung, secara tertulis, sebelum Anda menandatangani sesuatu yang mengikat:

  1. Siapa yang secara sah memiliki kode sumber, dan dapatkah Anda membuktikannya dengan klausul kontrak atau penugasan? Jawaban buruk: "Kami selalu punya akses ke sana."

  2. Apakah kode ada di repositori milik perusahaan atau akun pribadi? Jawaban buruk: "Ada di GitHub pengembang kami, tapi dia sudah bersama kami selama bertahun-tahun."

  3. Siapa yang memiliki server produksi dan akses domain, dan apakah menggunakan akun perusahaan? Jawaban buruk: "Agen lama kami yang mengelola hosting, kami hanya membayarnya setiap bulan."

  4. Apa yang terjadi jika pimpinan atau satu-satunya teknisi Anda berangkat besok? Jawaban buruk: "Jujur, itu akan menjadi masalah."

  5. Kapan audit keamanan atau uji penetrasi terakhir dilakukan, dan apa yang ditemukan? Jawaban buruk: "Kami belum pernah mengalaminya, namun sejauh ini belum terjadi apa-apa."

  6. Lisensi, API, atau dependensi sumber terbuka pihak ketiga apa yang diandalkan oleh sistem, dan apakah semuanya mematuhi kebijakan? Jawaban buruk: "Tidak yakin, pengembang kami menanganinya."

  7. Apakah ada dokumentasi selain apa yang ada di kepala seseorang? Jawaban buruk: "Ini cukup intuitif setelah Anda melihat kodenya."

  8. Bagaimana kondisi sebenarnya utang teknis, dan apakah ada yang sudah menghitungnya? Jawaban buruk: "Untuk saat ini berfungsi dengan baik."

  9. Apakah ada perselisihan yang belum terselesaikan dengan mantan pengembang atau agensi mengenai kekayaan intelektual atau pembayaran? Keheningan jawaban yang buruk, diikuti dengan pergantian topik.

  10. Dapatkah sistem menangani beban arus dua hingga tiga kali lipat tanpa membangun kembali? Jawaban buruk: "Kami belum benar-benar mengujinya."

Setiap jawaban buruk di atas tidak didiskualifikasi dengan sendirinya. Namun tiga atau lebih di antaranya secara bersamaan akan mengubah penilaian Anda, struktur kesepakatan, atau harga walk-away Anda.

Risiko orang kunci adalah risiko finansial, bukan hanya risiko teknisSatu-satunya tanda bahaya terbesar yang saya cari adalah konsentrasi. Jika satu orang memegang semua kredensial penerapan, memahami satu-satunya integrasi tidak terdokumentasi dengan gateway pembayaran, dan tidak pernah mengambil cuti lebih dari tiga hari dalam dua tahun tanpa terjadi kerusakan, Anda tidak membeli aset yang stabil. Anda membeli ketergantungan pada manusia yang belum menandatangani apa pun yang mengikat mereka untuk tetap tinggal.

Saya telah melihat pola yang persis seperti ini di sebuah perusahaan multifinance yang mengevaluasi kemitraan fintech: seluruh logika penilaian pinjaman target berada di mesin lokal milik satu pengembang, tidak berdokumen, tidak ada disiplin kontrol versi untuk modul penting. Kemitraan dilanjutkan, namun hanya setelah klausul mensyaratkan serah terima yang terdokumentasi dan masa transisi tiga bulan dengan pengembang asli tetap dipertahankan sebagai konsultan berbayar. Klausul itu saja mungkin menyelamatkan kesepakatan itu agar tidak terurai pada tahun pertama.

Postur keamanan dan utang teknis adalah item lini keuangan

Eksposur keamanan dan utang teknis tidak muncul di neraca, namun merupakan kewajiban nyata. Sistem yang belum ditambal dengan data pelanggan adalah tuntutan hukum yang menunggu pemicu. Basis kode yang disatukan oleh tambalan demi tambalan, yang kami bahas lebih mendalam di [Penjelasan Utang Teknis untuk Pemilik Bisnis] (/blog/technical-debt-explained-for-owners), berarti setiap fitur di masa depan memerlukan biaya lebih dari yang seharusnya, sehingga secara diam-diam membebani laba atas investasi Anda. Mintalah angka target Anda untuk mencerminkan hal ini, baik sebagai penilaian yang lebih rendah atau dana remediasi yang dimasukkan ke dalam kesepakatan.

Logika yang sama berlaku untuk platform lama yang mungkin Anda warisi, yang kami cakup dari sisi operasi pembeli di Biaya Tersembunyi Sistem Warisan di Bisnis Anda.

Kesimpulannya

Uji tuntas teknologi bukanlah sebuah kotak centang bagi para pengacara kesepakatan. Di sinilah Anda mengetahui apakah aset yang Anda beli dapat bertahan menghadapi kenyataan setelah tinta mengering. Tanyakan siapa pemilik kode tersebut, secara tertulis. Tanyakan apa yang terjadi jika orang yang memahami sistem tersebut keluar. Mintalah audit keamanan, bahkan yang ringan, sebelum Anda menutupnya. Jika tim teknis Anda sudah terlalu dekat dengan kesepakatan untuk menanyakan pertanyaan ini secara langsung, bawalah seseorang yang independen, maka interaksi seperti itulah yang layak untuk dibicarakan di /partner.