Memilih Teknologi Perangkat Lunak yang Bisa Dirawat UKM

Pilih teknologi perangkat lunak yang bisa dirawat tim Anda setelah proyek selesai. Tech stack berarti kumpulan bahasa, basis data, dan alat yang dipakai membangun sistem. Untuk UKM, pengalaman tim, kemudahan mencari pengganti, serta biaya dukungan perlu masuk perbandingan sejak awal. Kecepatan demo saja tidak cukup untuk menilai umur sistem.

Periksa siapa yang dapat direkrut di pasar lokal untuk memelihara sistem, serta bagaimana pekerjaan diteruskan jika pembuat awalnya tidak tersedia.

Teknologi matang mengurangi ketidakpastian

Dan McKinley punya kerangka yang jelas soal ini. Dalam esainya soal infrastruktur, ia memperlakukan teknologi baru sebagai anggaran: "anggap setiap perusahaan punya sekitar tiga token inovasi." Belanjakan token itu di tempat yang benar-benar menciptakan keunggulan bisnis. Di luar itu, pakai saja yang membosankan dan terbukti. (Choose Boring Technology)

Argumennya soal risiko, bukan selera. Teknologi matang menghadirkan risiko yang sudah dikenali: masalah yang pernah dialami tim lain, seperti apa yang terjadi kalau basis data kehabisan CPU. Teknologi baru menghadirkan risiko yang belum dikenali: bentuk kegagalan yang masih sulit diperkirakan. Contoh McKinley sendiri: tim yang tidak sadar bahwa menulis statistik ke basis data memicu jeda pembersihan memori (garbage collection) — masalah yang baru terlihat ketika sistem digunakan.

Teknologi matang memiliki lebih banyak pengalaman penggunaan yang dapat dijadikan rujukan. Tim dapat mempelajari masalah, batas kapasitas, dan cara pemulihan dari praktik yang sudah tersedia.

McKinley mencontohkan MySQL, Postgres, PHP, Python, memcached, Squid, dan Cron sebagai teknologi membosankan: matang, dipahami baik, mode kegagalannya sudah diketahui. Membosankan tidak pernah berarti buruk. Untuk sistem usaha kecil dan menengah, belanjakan token inovasi di bagian bisnis yang butuh — logika inventori, aturan penjadwalan khas operasi — dan serahkan bagian infrastruktur standarnya ke alat yang sudah teruji.

Hitungan pasar tenaga kerja lokal

"Membosankan" juga punya makna finansial langsung: makin lazim teknologinya, pilihan pengembang yang mengenalnya dapat lebih luas. Biaya perekrutan tetap perlu diperiksa secara lokal. Survei Pengembang Stack Overflow 2025 mencatat JavaScript dipakai 68,8% pengembang profesional, HTML/CSS 63%, SQL 61,3%, Python 54,8%, dan Bash/Shell serta TypeScript sama-sama 48,8%. Di basis data, PostgreSQL memimpin 58,2% dan MySQL 39,6%, jauh di atas SQLite, SQL Server, dan Redis.

Survei global ini menunjukkan penggunaan yang dilaporkan responden, bukan jumlah lowongan, gaji, atau kualitas kandidat di Indonesia. Periksa lowongan lokal dan bicara dengan calon pemelihara sebelum memilih. Teknologi yang banyak dipakai dapat memperluas pilihan, tetapi tidak menjamin perekrutan mudah.

Satu bahasa untuk seluruh sistem

Satu kendali lagi yang dipegang pemilik bisnis: berapa bahasa yang benar-benar dibutuhkan sistemnya. Beberapa bahasa menambah kebutuhan belajar, tetapi tidak berarti sistem hanya bisa dirawat vendor aslinya. Jika sistem memakai tiga ekosistem, pemelihara baru perlu mempelajari ketiganya sesuai bagian yang ditangani.

Menggunakan satu bahasa, misalnya TypeScript untuk sisi server, antarmuka, dan skrip, dapat memudahkan pengembang memahami keseluruhan sistem. Bagi perusahaan sepuluh orang, ini mengurangi kebutuhan keahlian yang terpisah. Ketergantungan pada satu pemelihara (bus factor) tetap harus ditangani melalui dokumentasi dan pembagian pengetahuan.

Pengalaman di sistem manajemen hotel ini menjadi contoh pertimbangan ini: penggunaan satu bahasa pada sistem server, panel pengelola, dan skrip internal menjadi pertimbangan utama. Satu pengembang dapat memahami ketiga bagian tersebut, meskipun dokumentasi dan pembagian pengetahuan tetap diperlukan.

Perhitungkan umur dukungan kerangka kerja

Perkembangan kerangka kerja dapat berlangsung lebih cepat daripada pergantian sistem bisnis. Lihat saja dekade terakhir dunia front-end: Backbone, Knockout, dan Ember digantikan AngularJS, lalu React, lalu penulisan ulang total ke Angular, lalu Vue. Tim yang mengejar tiap gelombang membayarnya dengan penulisan ulang berkali-kali.

Perusahaan besar bisa menyerap perputaran itu: ada tim platform, alat migrasi, dan cukup tenaga teknis untuk menjalankan satu skuad di framework lama sambil skuad lain menulis ulang. Perusahaan sepuluh orang tidak punya semua itu. Saat framework pilihan vendor dua tahun lalu diam-diam berhenti diperbarui, tidak ada cadangan yang bisa ditarik — hanya tagihan pemeliharaan yang tidak pernah dianggarkan.

Kurva biaya yang sebenarnya

Biaya pemeliharaan perlu dianggarkan bersama biaya pembangunan. Studi tinjauan sejawat soal biaya pemeliharaan perangkat lunak menemukan sekitar 90% biaya siklus hidup sebuah sistem berada di fase pemeliharaan, dengan beberapa estimasi bahkan lebih tinggi. (sumber)

Perkiraan 90% tersebut bukan persentase universal untuk setiap sistem UKM. Implikasi yang berguna ialah menyiapkan anggaran pemeliharaan bersama anggaran peluncuran. Pertimbangkan perbaikan, pembaruan komponen, dan pergantian staf selama umur sistem. Menghemat dua minggu waktu build sekarang, lalu membayar enam bulan risiko penulisan ulang di tahun ketiga — itu pertukaran buruk, walaupun demonya memukau.

Pertanyaan untuk vendor yang mengusulkan teknologi

Empat pertanyaan berikut membantu menilai usulan teknologi:

1. Bisakah kami merekrut untuk ini secara lokal, dengan gaji wajar? Kalau jawaban jujurnya "cuma dari tim kami," itu bukan stack. Itu ketergantungan pada satu perusahaan.
2. Di mana lagi ini sudah dipakai di produksi, sudah berapa lama? Kerangka kerja tanpa riwayat penggunaan bertahun-tahun memiliki lebih sedikit bukti tentang batas dan kegagalannya.
3. Apa yang terjadi kalau vendornya menghilang? Tanyakan langsung. Vendor yang percaya diri sudah memikirkan ini: alat standar dan dokumentasi, termasuk penjelasan lapisan khusus milik vendor.
4. Berapa biaya menyiapkan pengembang baru untuk memelihara kode ini? Tanyakan cakupan perkiraan: akses, dokumentasi, penyiapan lingkungan, aturan bisnis, dan pengujian. Lama penyiapan saja belum menunjukkan apakah masalahnya berada pada teknologi.

Penutup

Membosankan adalah keputusan bisnis, bukan kurangnya ambisi. Kesediaan membangun apa pun yang dibutuhkan klien — berlaku pada cara proyek dikerjakan, bukan pada berapa banyak teknologi yang ditumpuk di dalamnya.

Perusahaan sepuluh orang perlu menilai kemampuan merawat hasil proyek selama lima tahun, bukan hanya daya tarik demonstrasinya. Pilih teknologi dengan bukti penggunaan dan calon pemelihara yang tersedia. Gunakan teknologi baru ketika manfaat bisnisnya sepadan dengan risiko tambahan.