Kalau Anda pemilik bisnis yang duduk di rapat sementara dua developer berdebat soal framework, ini yang sebenarnya perlu Anda tahu soal cara memilih tech stack: framework jarang sepenting siapa yang bisa Anda rekrut untuk merawatnya lima tahun dari sekarang. Saya sudah duduk di kedua sisi meja itu, sebagai developer yang punya opini dan sebagai orang yang harus menjelaskan keputusan ini ke founder non-teknis, dan kriteria yang benar-benar melindungi bisnis hampir tidak pernah jadi topik yang pertama kali diperdebatkan developer.
Benchmark performa, elegansi syntax, apakah sebuah framework "modern", ini semua topik yang disukai engineer untuk diperdebatkan. Tapi untuk 95% web app bisnis, semua itu tidak relevan dengan berhasil tidaknya proyek. Yang sebenarnya menentukan keberhasilan adalah apakah Anda bisa menemukan orang untuk membangun dan kemudian merawatnya, dan apakah sistem itu tetap berjalan tanpa drama selama bertahun-tahun.
Ini versi percakapan yang akan saya lakukan langsung dengan Anda, sebagai pemilik bisnis yang menyetujui keputusan, bukan developer yang membuatnya.
Empat pertanyaan ini harus dijawab sebelum nama teknologi apa pun disebut
Sebelum "React vs Vue" atau "Node vs PHP" masuk ke ruangan, jawab dulu ini:
- Siapa yang akan membangun ini? Tim in-house, agency, atau freelancer?
- Siapa yang akan merawatnya di tahun ketiga? Tim yang sama, agency lain, atau siapa pun yang bisa Anda temukan saat itu?
- Aplikasi ini sebenarnya untuk apa? Alat internal, produk yang dipakai langsung oleh pelanggan, sesuatu yang perlu scale ke ribuan pengguna, atau sesuatu yang melayani 50 staf?
- Berapa lama sistem ini harus bertahan? Microsite untuk kampanye punya standar yang berbeda dari sistem operasional inti.
Jawaban dari empat pertanyaan ini menyingkirkan sebagian besar perdebatan teknologi sebelum dimulai. Alat internal untuk lima tahun yang dirawat oleh siapa pun yang bisa Anda rekrut secara lokal punya batasan yang sama sekali berbeda dari aplikasi pelanggan yang menargetkan scale cepat dengan tim engineering khusus.
Hiring pool mengalahkan benchmark performa
Ini kebenaran yang tidak nyaman bagi engineer yang suka berdebat soal teknis: framework tercepat dan paling elegan sekalipun tidak ada gunanya kalau Anda tidak bisa merekrut siapa pun di kota Anda yang menguasainya cukup baik untuk merawatnya tanpa Anda.
Di Indonesia, hiring pool praktis untuk web app bisnis kurang lebih seperti ini:
| Stack | Ukuran hiring pool | Kecocokan use case umum |
|---|---|---|
| React / Next.js | Besar | Web app yang dipakai pelanggan, dashboard, sebagian besar software bisnis |
| PHP (Laravel) | Besar | Alat internal, admin panel, situs berbasis CMS |
| .NET | Besar di sektor enterprise/finance | Sistem yang butuh strong typing, industri yang teregulasi |
| Node.js (Nest.js dll.) | Menengah-besar | API, backend service yang dipasangkan dengan front end React |
| Framework niche/baru | Kecil | Jarang sepadan dengan risikonya untuk aplikasi bisnis, kecuali ada kebutuhan teknis spesifik yang mengharuskannya |
Memilih stack dengan hiring pool besar berarti kalau developer atau agency awal Anda menghilang, dan ini lebih sering terjadi daripada yang dibayangkan pemilik bisnis, Anda bisa menemukan penggantinya dalam hitungan minggu, bukan bulan. Memilih stack niche karena "secara teknis lebih unggul" berarti Anda mempertaruhkan kelangsungan bisnis pada satu orang atau satu agency yang tidak boleh pergi. Itu taruhan yang buruk, sebagus apa pun teknologinya.
Kemampuan dirawat selama lima tahun mengalahkan benchmark
Web app bisnis bukan proyek riset. Ia harus tetap berfungsi, dan tetap bisa dirawat, di tahun kelima, kemungkinan besar oleh orang yang tidak membangunnya. Ini mengubah arti kata "bagus".
Teknologi yang membosankan, terdokumentasi dengan baik, dan banyak dipakai, lebih tahan lama dibanding teknologi yang canggih dan mutakhir, karena:
- Dokumentasi dan dukungan komunitas bertahan. Framework yang banyak dipakai punya satu dekade jawaban Stack Overflow dan tutorial. Yang niche punya server Discord yang mungkin masih aktif atau tidak lima tahun lagi.
- Upgrade berjalan bertahap, bukan lompatan curam. Framework populer menjaga jalur backward compatibility. Proyek yang lebih kecil kadang memaksa rewrite yang menyakitkan saat maintainer-nya berganti arah atau meninggalkan proyek.
- Onboarding developer baru lebih cepat. Kalau stack Anda umum, karyawan baru sudah produktif dalam hitungan hari. Kalau stack-nya obscure, siapkan waktu ramp-up berminggu-minggu, bahkan untuk developer yang bagus sekalipun.
Inilah kenapa, untuk sebagian besar aplikasi bisnis yang pernah saya scoping, mulai dari sistem booking bengkel otomotif sampai alat inventaris ritel, saya default ke React atau Next.js di front end dan Node.js atau .NET di back end, bukan karena keduanya pilihan paling menarik, tapi karena keduanya taruhan jangka panjang paling aman untuk bisnis yang bukan bergerak di bidang software itu sendiri.
Kapan sebenarnya layak menyimpang
Ada alasan yang sah untuk memilih sesuatu yang kurang umum, tapi alasan itu harus eksplisit, bukan kebetulan:
- Industri yang teregulasi (finance, kesehatan) di mana stack tertentu punya tooling compliance yang sudah terbukti.
- Tim yang sudah ada dengan keahlian mendalam di stack tertentu, di mana beralih justru lebih mahal biaya retraining-nya dibanding manfaat dari hiring pool yang lebih luas.
- Kebutuhan teknis yang benar-benar tidak biasa, seperti pemrosesan real-time yang berat, yang ditangani buruk oleh stack mainstream.
Tidak satu pun dari ini berlaku untuk sebagian besar web app bisnis. Kalau alasan developer Anda memilih sebuah stack adalah "ini lebih modern" atau "ini lebih seru ditulis", itu preferensi, bukan justifikasi bisnis, dan Anda perlu minta mereka membuktikan alasannya lewat empat pertanyaan di atas.
Kesimpulan: putuskan sebagai pemilik bisnis, bukan developer
Cara memilih tech stack untuk web app bisnis pada akhirnya bermuara pada dua pertanyaan yang tidak ada hubungannya dengan keanggunan teknis: bisakah Anda merekrut untuknya secara konsisten, dan apakah sistem itu masih bisa dirawat di tahun kelima tanpa bergantung pada satu orang yang tidak tergantikan. Yang membosankan dan umum hampir selalu menang dari yang canggih dan langka. Kalau Anda sedang mengevaluasi proposal saat ini dan justifikasinya lebih mengandalkan kehebohan teknis ketimbang hiring pool dan daya tahan jangka panjang, itu layak dipertanyakan sebelum Anda menyetujui budgetnya.