Memilih Tech Stack untuk Sistem SME: Membosankan Itu Menang

Memilih Tech Stack untuk Sistem SME: Membosankan Itu Menang

Tech stack itu keputusan staffing yang menyamar jadi keputusan teknis. Hampir semua proposal sistem bisnis kecil-menengah membahas teknologinya duluan — seberapa cepat render-nya, seberapa modern toolchain-nya saat demo.

Pertanyaan yang sebenarnya menentukan umur sistem itu berbeda: siapa yang bisa direkrut secara lokal dengan gaji wajar, untuk menjaga sistem ini tetap jalan setelah orang yang membangunnya pergi?

Arti sebenarnya dari "membosankan"

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 known unknowns: masalah yang sudah pernah dialami tim lain, seperti apa yang terjadi kalau database kehabisan CPU. Teknologi baru menghadirkan unknown unknowns: mode kegagalan yang belum ditemukan siapa pun. Contoh McKinley sendiri: tim yang tidak sadar bahwa menulis statistik ke database memicu jeda garbage collection — kegagalan yang tak terlihat sampai akhirnya terlihat.

Bayangkan memilih dokter. Dokter umum yang sudah menangani ribuan pasien tahu persis gejala mana yang berbahaya dan mana yang tidak. Dokter baru lulus, sepintar apa pun, belum pernah melihat kasusnya. Teknologi matang sama seperti dokter umum itu — kejutannya sudah lebih dulu ditemukan orang lain.

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 SME, belanjakan token inovasi di bagian bisnis yang butuh — logika inventori, aturan penjadwalan khas operasi — dan serahkan bagian infrastruktur standarnya ke tools yang sudah teruji.

Hitungan pasar tenaga kerja lokal

"Membosankan" juga punya makna finansial langsung: makin lazim teknologinya, makin banyak developer yang bisa direkrut — dan makin wajar gajinya. Stack Overflow Developer Survey 2025 mencatat JavaScript dipakai 68,8% developer profesional, HTML/CSS 63%, SQL 61,3%, Python 54,8%, dan Bash/Shell serta TypeScript sama-sama 48,8%. Di database, PostgreSQL memimpin 58,2% dan MySQL 39,6%, jauh di atas SQLite, SQL Server, dan Redis.

Angka itu tidak mengukur kualitas. Yang diukurnya besarnya pasokan tenaga kerja. Stack dari daftar teratas berarti lowongan normal dan gaji normal saat perlu ganti orang. Stack dari papan bawah survei berarti pencarian sempit dan tarif premium — karena kelangkaan, bukan kemampuan, yang menentukan harga.

Satu bahasa untuk seluruh sistem

Satu kendali lagi yang dipegang pemilik bisnis: berapa bahasa yang benar-benar dibutuhkan sistemnya. Backend satu bahasa, script bahasa kedua, tooling bahasa ketiga — itu stack yang cuma bisa dirawat penuh oleh tim vendor aslinya. Semua orang lain harus onboarding ke tiga ekosistem sekaligus, hanya untuk menyentuh satu sistem.

Rapikan jadi satu runtime — TypeScript untuk backend, frontend, dan script, misalnya — dan satu developer bisa membaca, memperbaiki, mengembangkan seluruh sistemnya. Itu makna praktis bus factor untuk perusahaan sepuluh orang. Bukan soal berapa banyak orang paham kodenya, tapi berapa banyak jenis orang yang perlu direkrut untuk menggantikan yang keluar.

Pengalaman di sistem manajemen hotel ini membuktikannya: menjaga backend, panel admin, dan script internal dalam satu bahasa lebih menentukan keputusan stack dibanding fitur framework mana pun. Cukup satu orang, bukan tiga, untuk menjaga semuanya tetap jalan.

Kenapa framework terbaru jadi liabilitas untuk perusahaan sepuluh orang

Framework berputar dalam siklus jauh lebih pendek dari umur kebanyakan sistem SME. 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 platform team, tooling migrasi, cukup engineer 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 diupdate, tidak ada cadangan yang bisa ditarik — hanya tagihan pemeliharaan yang tidak pernah dianggarkan.

Kurva biaya yang sebenarnya

Sebagian besar biaya software terjadi setelah peluncuran, bukan sebelumnya. Studi tinjauan sejawat soal biaya pemeliharaan software menemukan sekitar 90% biaya siklus hidup sebuah sistem berada di fase pemeliharaan, dengan beberapa estimasi bahkan lebih tinggi. (sumber)

Angka itu seharusnya menentukan seluruh keputusan. Stack tidak dipilih supaya terlihat bagus saat demo peluncuran. Ia dipilih untuk tahun-tahun perbaikan kecil, update dependency, dan pergantian staf yang menyusul. 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 mana pun yang mengusulkan stack

Empat pertanyaan yang menyelesaikan sebagian besar kerja:

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? Framework tanpa riwayat produksi bertahun-tahun masih mencari unknown unknowns-nya. Jangan sampai sistem Anda yang menemukannya duluan.
3. Apa yang terjadi kalau vendornya menghilang? Tanyakan langsung. Vendor yang percaya diri sudah memikirkan ini: dokumentasi, tooling standar, tanpa framework proprietary yang membungkus yang aslinya.
4. Berapa biaya onboarding developer baru ke codebase ini? Satu hari jawaban yang bagus. Satu bulan tanda bahwa yang sulit itu stack-nya, bukan logika bisnisnya.

Penutup

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

Konsultan yang selalu meraih framework terbaru sedang mengoptimalkan resume-nya sendiri, bukan perusahaan sepuluh orang yang harus menjalankan hasilnya lima tahun ke depan. Pilih yang terbukti. Pilih yang mudah dicari orangnya. Belanjakan token inovasi hanya di tempat bisnis benar-benar membutuhkannya.