Pemilihan Tech Stack: Antara Ego dan Bisnis

Nganu, jadi beberapa waktu lalu saya duduk di sebuah rapat internal, entah via Zoom, entah via Google Meet, sudah lupa. Yang jelas, seorang rekan tiba-tiba semangat sekali mengusulkan sesuatu:

“Gimana kalau kita migrasi ke microservices sekalian? Biar modern, biar scalable, biar-”

Biar apa? Sistem kami saat itu punya dua fitur utama, satu tim kecil berisi empat orang, dan traffic yang paling sibuknya pun tidak sampai seribuan request per hari. Kebutuhan microservices? Nol. Tapi semangatnya… seratus hahaha.

Saya tidak menyalahkan beliau. Saya pun pernah begitu. Dan kalau jujur, kadang masih. Godaan memilih teknologi yang keren memang nyata, dan tidak ada salahnya, selama kita sadar itu godaan, bukan keputusan teknis.

Tulisan ini tentang tegangan antara dua suara yang sering bertengkar di kepala saya ketika harus memilih tech stack: suara ego yang ingin terlihat canggih, dan suara bisnis yang hanya peduli apakah sistemnya jalan dan menghasilkan nilai.

Ketika Ego Berbicara #

Ciri-ciri keputusan teknis yang didorong ego itu sebenarnya cukup mudah dikenali, kalau kita mau jujur:

“Teknologi ini lagi trending.” Buka Twitter/X, scroll sebentar, langsung ada tiga thread tentang framework baru yang katanya mengubah segalanya. Satu bulan kemudian, ada lagi framework baru yang mengubah yang tadi. Dan siklus itu terus berputar. Fear of Missing Out di dunia teknologi itu nyata sekali, dan berbahaya kalau tidak dikendalikan.

“Nanti susah di-hire kalau pakai yang lama.” Ini argumen yang kedengarannya masuk akal, tapi seringkali dipakai untuk membenarkan keputusan yang sebenarnya bukan soal sistem, melainkan soal karier pribadi. Yang mana tidak salah! Tapi harus jujur bahwa motivasinya memang itu, bukan kebutuhan sistem.

“Teman di komunitas semuanya sudah pakai ini.” Peer pressure itu tidak berhenti di masa SMA. Di dunia developer, bentuknya adalah rasa tidak enak kalau belum pakai Kubernetes, belum coba Rust, atau belum containerize semuanya, padahal sistem-nya monolith kecil yang baik-baik saja hehe~

“Kode yang bagus itu fun untuk ditulis.” Nah, yang ini paling berbahaya karena terselubung dalam jubah profesionalisme. Kita memilih arsitektur yang kompleks bukan karena dibutuhkan, tapi karena… exciting untuk diimplementasikan. Dan akhirnya yang menanggung beban adalah orang yang meneruskan codebase tersebut¹.

Bisnis Tidak Peduli Stack-mu #

Ini kenyataan yang sedikit pahit tapi perlu dikatakan: bisnis tidak peduli kamu pakai PHP atau Go, REST atau GraphQL, Postgres atau MySQL, selama sistemnya berjalan, cepat, murah untuk dioperasikan, dan mudah dikembangkan ketika ada kebutuhan baru.

Yang benar-benar dipedulikan bisnis:

Pertanyaan Engineer	Pertanyaan Bisnis
Apakah teknologi ini state-of-the-art?	Apakah bisa selesai tepat waktu?
Apakah arsitekturnya elegant?	Apakah tim bisa maintain ini?
Apakah ini bisa scale sampai jutaan user?	Berapa biaya server tiap bulannya?
Apakah ini pakai bahasa yang populer?	Kalau ada yang keluar tim, berapa lama onboarding developer baru?

Perhatikan betapa kedua kolom itu bicara hal yang sama sekali berbeda. Dan seringkali kita terlalu fokus di kolom kiri, sementara yang membayar gaji kita berpikir dari kolom kanan.

Bukan berarti kita harus abaikan aspek teknis. Pilihan teknis yang buruk hari ini bisa jadi hutang teknis yang mahal besok, dan itu juga kekhawatiran bisnis. Maksudnya, kedua sisi perlu dipertimbangkan, bukan cuma satu.

Cara Memilih yang Tidak Menyakitkan #

Setelah beberapa kali salah pilih (dan menanggung akibatnya hehe), saya punya empat pertanyaan yang sekarang selalu saya ajukan sebelum memutuskan stack atau arsitektur baru:

1. Apakah tim saya bisa maintain ini dalam 6 bulan? #

Bukan “bisakah saya implement ini?”, tapi “bisakah tim saya hidup bersama ini dalam jangka panjang?” Kalau saya yang pergi besok, apakah orang lain bisa melanjutkan tanpa breakdown dua minggu pertama?

Teknologi yang kita pilih harus bisa dipahami oleh orang yang paling junior di tim². Kalau tidak, kita sedang membangun knowledge silo, dan itu berbahaya.

2. Apakah ini memecahkan masalah nyata yang sudah ada, atau masalah yang mungkin ada nanti? #

Premature optimization itu musuh productivity. Membangun sistem event-driven yang kompleks untuk aplikasi yang belum tentu mencapai jutaan user adalah keputusan yang sangat mahal, baik dari sisi waktu maupun kompleksitas.

Aturan yang saya pegang: selesaikan masalah yang ada sekarang, dengan solusi yang cukup baik untuk kebutuhan yang terukur. Kalau nanti butuh scale, refactor dengan bukti, bukan dengan asumsi.

3. Berapa biaya nyatanya? #

Bukan cuma biaya cloud, tapi biaya waktu. Berapa lama untuk setup? Berapa lama untuk onboarding? Berapa lama debugging ketika ada masalah? Berapa lama kalau ada developer baru harus paham sistem ini?

Teknologi yang canggih tapi butuh seminggu untuk setup lokal itu mahal, bahkan sebelum satu baris kode bisnis ditulis.

4. Apakah ini meningkatkan time-to-market atau memperlambatnya? #

Kecepatan delivery itu sangat penting bagi bisnis. Fitur yang telat enam bulan bisa berarti opportunity yang hilang, user yang pergi ke kompetitor, atau investor yang kehilangan kepercayaan.

Kalau pilihan teknologi kita mempercepat delivery, bagus. Kalau justru memperlambat, pertimbangkan ulang, meskipun teknologinya secara teknis lebih “benar”.

Pelajaran dari Lapangan #

Boleh saya self-reflect sebentar? Saya pernah menulis tentang migrasi sistem backend dari PHP ke Go yang saya kerjakan, 370+ endpoint, 33 entity, hampir 200 ribu baris kode.

Dan pertanyaan yang jujur saya ajukan ke diri sendiri saat itu adalah: apakah ini keputusan bisnis, atau ego saya yang ingin kerja dengan Go?

Jawabannya… keduanya, tapi dengan proporsi yang terjaga hehe~

Sisi ego-nya: ya, saya penasaran dengan Go. Saya ingin hands-on experience yang lebih dalam. Saya suka cara Go menangani concurrency. Itu nyata dan saya tidak akan mengingkarinya.

Tapi sisi bisnis-nya juga nyata:

• Sistem lama punya masalah arsitektur yang serius, bukan sekadar PHP-nya, tapi ketiadaan pemisahan layer yang membuat setiap perubahan berisiko tinggi
• Deploy yang tidak bisa diprediksi sudah beberapa kali menyebabkan insiden di production
• Testing coverage yang rendah membuat tim takut untuk refactor, padahal refactor dibutuhkan
• Satu binary Go menghilangkan masalah dependency hell di server yang selama ini makan waktu tim ops

Jadi, Go bukan dipilih semata karena keren, tapi karena di konteks spesifik tersebut, trade-off-nya masuk akal: biaya migrasi³ yang besar upfront, tapi dengan long-term benefit yang terukur.

Itu yang membedakan keputusan teknis berbasis bisnis dengan keputusan berbasis ego: ada analisis trade-off yang jelas dan berani dipertanggungjawabkan.

Ego Itu Tidak Selalu Buruk #

Satu hal yang ingin saya luruskan sebelum menutup tulisan ini: ego sebagai developer tidak selalu negatif.

Ingin mempelajari teknologi baru itu bagus, itu yang membuat kita berkembang. Ingin menulis kode yang clean dan elegant itu bagus, itu yang membuat sistem lebih mudah dirawat. Ingin push untuk solusi yang lebih baik itu bagus, itu yang menggerakkan inovasi.

Yang bermasalah adalah ketika ego itu mengaburkan judgment kita, ketika kita memilih teknologi untuk terlihat pintar, bukan untuk memecahkan masalah. Ketika kita membangun sistem yang kompleks bukan karena dibutuhkan, tapi karena fun untuk dibangun. Ketika kita mempertahankan pilihan yang salah karena tidak mau mengakui kekeliruan.

Aware terhadap perbedaan itu, menurut saya, adalah salah satu kematangan penting seorang software engineer.

Sekian. Semoga bermanfaat dan terima kasih sudah tersasar ke sini hehe~