Membayar SaaS atau bangun sistem sendiri adalah pertanyaan yang sudah dijawab oleh ratusan CTO dan CFO di perusahaan enterprise Indonesia. Tidak serentak, tapi satu per satu, biasanya setelah dua hingga empat tahun berlangganan dan satu momen ketika invoice renewal terasa terlalu besar untuk tidak dipertanyakan. Polanya konsisten: semakin lama perusahaan menunda kalkulasi ini, semakin besar selisih yang akhirnya ditemukan antara total yang sudah dibayarkan dan biaya membangun sistem setara.
Artikel ini menyajikan proyeksi biaya dua model dalam rentang tujuh tahun. Bukan untuk menjawab apakah satu model selalu lebih baik, tapi untuk menunjukkan bagaimana dua kurva biaya ini bergerak secara fundamental berbeda seiring waktu, dan apa yang dipertaruhkan oleh perusahaan yang memilih untuk tidak menghitungnya sampai tuntas.
Dua Asumsi yang Perlu Dilepas Sebelum Kalkulasi Ini Bisa Jujur
Perbandingan ini sering gagal menghasilkan kesimpulan yang berguna. Bukan karena datanya kurang, tapi karena dua asumsi yang masing-masing membiaskan kalkulasi ke arah yang berlawanan.
Asumsi pertama: “Uang yang sudah dibayar adalah sunk cost yang tidak relevan.”
Secara teori akuntansi, ini benar, sunk cost (pengeluaran yang tidak dapat diperoleh kembali) seharusnya tidak mempengaruhi keputusan ke depan. Dalam praktik di organisasi, ini hampir tidak pernah berlaku. Perusahaan yang sudah membayar Rp 4 miliar dalam tiga tahun berlangganan secara psikologis terdorong untuk melanjutkan. Bukan karena analisis ke depannya mendukung, tapi karena berhenti terasa seperti mengakui bahwa Rp 4 miliar sebelumnya salah diinvestasikan. Hasilnya: keputusan yang seharusnya berbasis proyeksi biaya ke depan malah terdistorsi oleh biaya masa lalu yang tidak relevan untuk kalkulasi saat ini.
Yang perlu diinternalisasi sebelum kalkulasi dimulai: total yang sudah dibayar tidak mengubah angka yang akan dibayarkan ke depan. Jika model yang lebih hemat tersedia mulai hari ini, setiap bulan yang berlalu dengan model yang lebih mahal adalah biaya nyata , bukan justifikasi untuk melanjutkannya.
Asumsi kedua: “Bangun sistem sendiri berarti harus punya tim developer internal.”
Ini adalah misconception yang paling banyak menghalangi evaluasi yang serius. “Bangun sistem sendiri” dalam konteks ini tidak berarti merekrut 10–15 developer, membangun tim IT produk dari nol, dan menanggung seluruh risiko pengembangan secara internal. Yang dimaksud adalah: mengkomisikan sistem kepada mitra software house yang memiliki rekam jejak untuk jenis sistem tersebut, menerima sistem yang sudah selesai, dan memiliki penuh hak atas sistem dan datanya, tanpa ketergantungan pada keputusan pricing dan roadmap vendor asing.
Perbedaan ini penting karena biaya dan risikonya sangat berbeda dari asumsi awal yang kebanyakan perusahaan pegang.
Bagaimana Dua Kurva Biaya Ini Bergerak Berbeda dalam Tujuh Tahun
Banyak perusahaan membandingkan SaaS dan sistem custom hanya sampai tahun pertama. Padahal perbedaan terbesar justru muncul setelahnya.
Ambil contoh perusahaan dengan 200 pengguna aktif yang menggunakan platform SaaS berdenominasi dolar seharga USD 55 per pengguna per bulan. Dengan kurs yang dalam beberapa waktu terakhir berada di kisaran Rp 17.000–Rp18.000 per dolar, biaya tahun pertama sudah mencapai lebih dari Rp 2,3 miliar. Bandingkan dengan sistem custom yang memiliki fungsi setara. Investasi awal sekitar Rp2 miliar ditambah biaya pemeliharaan tahun pertama sebesar Rp 250–300 juta membuat total pengeluaran tahun pertama berada di kisaran Rp 2,25–2,3 miliar.
Di tahun pertama, keduanya terlihat hampir sama. Di sinilah banyak perusahaan berhenti menghitung dan menganggap kedua opsi memiliki biaya yang setara. Padahal, mulai tahun kedua, kedua kurva biaya bergerak ke arah yang sangat berbeda.
Biaya SaaS cenderung terus meningkat karena dua faktor yang bekerja bersamaan: kenaikan harga vendor dan fluktuasi kurs dolar. Setiap penyesuaian harga atau pelemahan rupiah langsung meningkatkan biaya operasional. Dengan asumsi kenaikan biaya efektif 10–15% per tahun, pengeluaran SaaS yang awalnya sekitar Rp 2,3 miliar dapat mendekati Rp3 miliar per tahun pada tahun ketiga. Secara kumulatif, total biaya dalam tiga tahun bisa mencapai Rp7–8 miliar.
Sebaliknya, sistem custom memiliki pola biaya yang jauh lebih stabil. Investasi terbesar terjadi di awal, sementara biaya pemeliharaan tahunan umumnya hanya berkisar Rp250–300 juta dan tidak terpengaruh langsung oleh kurs dolar. Akumulasi biaya dalam tiga tahun biasanya masih berada di kisaran Rp2,8–3 miliar. Artinya, titik impas umumnya tercapai antara tahun kedua dan ketiga.
Namun yang lebih penting adalah apa yang terjadi setelah titik tersebut. Pada tahun kelima, total biaya SaaS dapat mencapai Rp 13–16 miliar, sementara sistem custom biasanya masih berada di kisaran Rp 3,5–4 miliar. Selisihnya sudah lebih dari Rp 9–12 miliar. Memasuki tahun ketujuh, akumulasi biaya SaaS dapat mendekati atau melampaui Rp 20 miliar, sedangkan sistem custom umumnya masih berada di kisaran Rp 4–5 miliar. Dengan kata lain, selisih biaya yang tercipta dapat mencapai belasan hingga hampir dua puluh miliar rupiah untuk sistem yang melayani proses bisnis dan jumlah pengguna yang sama.
Ini bukan soal SaaS lebih mahal atau sistem custom lebih murah. Ini tentang memahami bagaimana dua model biaya bekerja. SaaS mengikuti kurva biaya yang terus bertumbuh dari tahun ke tahun, sementara sistem custom cenderung menjadi aset dengan biaya yang lebih stabil setelah investasi awal selesai dilakukan. Karena itu, keputusan yang terlihat setara di tahun pertama sering kali menghasilkan konsekuensi finansial yang sangat berbeda ketika dilihat dalam horizon lima hingga tujuh tahun.
Yang “Terus Bayar SaaS” Sebenarnya Pertaruhkan Selain Biaya
Perbandingan biaya sudah cukup kuat, tapi ada dimensi risiko dari pilihan “terus bayar” yang jarang masuk ke dalam kalkulasi karena tidak memiliki angka yang mudah dikuantifikasi, sampai ia terjadi.
- Risiko akuisisi vendor
Industri software enterprise global memiliki tren konsolidasi yang sangat aktif. Vendor yang hari ini terasa stabil bisa diakuisisi oleh perusahaan yang lebih besar, yang kemudian menggabungkan platform, menghentikan dukungan untuk versi yang sedang digunakan, atau mengubah struktur harga secara signifikan pasca-akuisisi. Ketika ini terjadi, perusahaan tidak punya pilihan untuk melanjutkan apa adanya, mereka harus migrasi, baik ke platform baru milik acquirer dengan terms yang lebih tidak menguntungkan, atau ke sistem lain dengan biaya dan waktu yang tidak direncanakan sama sekali. - Risiko product sunset
Vendor SaaS memiliki kewenangan penuh untuk menghentikan produk atau fitur tertentu berdasarkan pertimbangan roadmap global mereka , yang tidak selalu sejalan dengan kebutuhan klien Indonesia. Ketika fitur yang menjadi andalan operasional perusahaan dihentikan atau dipindahkan ke tier yang lebih mahal, perusahaan tidak memiliki leverage untuk mempertahankannya. Pilihan yang tersedia hanya dua: bayar lebih, atau migrasi dalam kondisi terpaksa dengan timeline yang bukan di tangan perusahaan. - Pendalaman lock-in yang tidak linear
Setiap tahun berlangganan, data yang tersimpan di sistem vendor semakin dalam dan semakin kompleks. Tahun pertama, biaya keluar dari sistem masih relatif terkendali. Tahun keempat, ada empat tahun data transaksi, konfigurasi yang sudah disesuaikan, dan integrasi yang sudah dibangun di atas sistem vendor , masing-masing menambah switching cost yang tidak pernah tercatat sebagai baris di invoice tapi sangat nyata saat evaluasi keluar dilakukan.
Pilihan arsitektur sistem yang tepat, apakah monolitik atau microservices, mempengaruhi seberapa mudah sistem yang dibangun sendiri bisa dikembangkan dan disesuaikan tanpa tergantung pada keputusan pihak luar. Ini adalah kontrol yang tidak pernah dimiliki perusahaan selama sistem masih milik vendor SaaS.
Tanda-Tanda Perusahaan Sudah Melewati Titik Optimal Berlangganan
Ada titik ketika software subscription tidak lagi menjadi pilihan paling efisien. Biaya terus bertambah, sementara manfaat yang diperoleh tidak meningkat dalam proporsi yang sama. Beberapa tanda yang paling mudah dikenali adalah:
- Biaya renewal naik setiap tahun, tetapi fitur baru yang ditambahkan vendor jarang atau bahkan tidak digunakan oleh tim.
- Tim IT semakin sering menghabiskan waktu untuk mengelola integrasi, penyesuaian sistem, dan perubahan API dari vendor daripada mengembangkan inisiatif yang memberikan nilai bisnis baru.
- Kebutuhan kustomisasi penting terus tertunda karena keterbatasan platform, sehingga proses operasional tetap bergantung pada workaround yang tidak efisien.
- Laporan atau analisis tertentu masih harus dibuat secara manual melalui ekspor data ke spreadsheet atau aplikasi lain karena sistem tidak mampu memenuhi kebutuhan yang lebih spesifik.
- Setiap penambahan pengguna, cabang, atau volume transaksi langsung meningkatkan biaya subscription, sehingga pertumbuhan bisnis justru diikuti kenaikan biaya yang semakin besar.
Jika kondisi-kondisi ini mulai terjadi secara bersamaan, biasanya perusahaan telah melewati titik optimal penggunaan software berbasis subscription. Pada fase ini, biaya yang terus dibayarkan tidak lagi sepenuhnya mencerminkan nilai yang diterima, sehingga membangun sistem yang dimiliki sendiri mulai menjadi alternatif yang layak dipertimbangkan.
Memulai Evaluasi Tanpa Harus Memutuskan Semuanya Sekaligus
Salah satu hambatan terbesar yang membuat kalkulasi ini tidak pernah selesai dilakukan adalah paralysis by analysis, perasaan bahwa evaluasi ini harus menghasilkan keputusan final yang mencakup semua sistem sekaligus, dengan angka yang sempurna, sebelum langkah apapun bisa diambil.
Evaluasi yang efektif tidak dimulai dari sana.
- Mulai dari satu sistem, bukan seluruh portofolio.
Identifikasi satu sistem SaaS yang biayanya paling besar, tingkat kustomisasinya paling banyak dikompromikan, dan prosesnya paling stabil untuk dispesifikasikan. Hitung proyeksi biaya dua model untuk sistem itu saja selama lima tahun ke depan. Jika hasilnya cukup kuat, gunakan angka itu sebagai kasus pertama untuk mendapatkan persetujuan anggaran, bukan sebagai komitmen untuk migrasi seluruh portofolio. - Pisahkan keputusan “apakah” dari keputusan “bagaimana.”
Terlalu banyak evaluasi yang macet karena pertanyaan “apakah kita sebaiknya beralih” tidak pernah terjawab karena langsung terseret ke diskusi tentang “bagaimana cara migrasinya.” Dua pertanyaan ini perlu dijawab secara berurutan, bukan bersamaan. - Lakukan due diligence vendor sebelum angka keputusan final ditetapkan. Sebelum angka investasi custom masuk ke dalam kalkulasi sebagai variabel tetap, validasi angka tersebut dengan minimal dua atau tiga mitra yang memiliki referensi implementasi sistem yang sebanding, bukan hanya proposal yang terlihat menarik. Apa yang perlu disiapkan sebelum melibatkan vendor IT, dari kesiapan spesifikasi kebutuhan hingga governance proyek , menentukan seberapa akurat angka yang dihasilkan dari proses due diligence tersebut.
FAQ: Pertanyaan yang Paling Sering Muncul di Titik Keputusan Ini
Ada tiga kondisi yang sering menjadi katalis keputusan: periode renewal kontrak SaaS yang akan datang, ketika perusahaan memiliki leverage untuk tidak memperpanjang tanpa penalti; ketika ada proyek transformasi IT yang lebih besar yang bisa mencakup migrasi ini sebagai bagian dari scope yang lebih luas; dan ketika ada perubahan regulasi yang memaksa evaluasi ulang, seperti implementasi UU PDP yang mempertanyakan di mana data pelanggan dan karyawan disimpan. Di luar tiga kondisi ini, satu-satunya alasan yang tidak baik untuk menunda adalah “belum ada waktu yang tepat”, karena setiap bulan penundaan adalah bulan di mana kurva biaya terus melebar.
Tidak perlu diperhitungkan, dan inilah yang paling sulit diterima secara psikologis tapi paling penting secara finansial. Biaya yang sudah dibayar tidak bisa dikembalikan terlepas dari keputusan yang diambil hari ini. Yang relevan untuk kalkulasi adalah: berapa yang akan dibayarkan mulai bulan depan jika melanjutkan SaaS, dibandingkan berapa total yang akan dikeluarkan jika beralih sekarang. Kalkulasi ini sepenuhnya prospektif. Memasukkan sunk cost ke dalam persamaan hanya akan menghasilkan angka yang tidak memiliki makna keputusan.
Tidak harus. “Bangun sistem sendiri” yang dimaksud dalam konteks ini adalah: perusahaan mengkomisikan sistem kepada mitra software house eksternal, menerima sistem yang sudah selesai dibangun dan diuji, dan memiliki hak penuh atas source code, data, dan infrastruktur sistem tersebut. Tim internal yang dibutuhkan hanya cukup untuk mengelola proyek selama pembangunan dan mengoperasikan serta mengembangkan sistem setelah selesai , bukan membangun sendiri dari nol.
Risiko ini tidak memiliki angka yang pasti tapi memiliki preseden yang cukup banyak untuk diambil pelajaran. Ketika vendor SaaS diakuisisi atau menghentikan produk, perusahaan yang terdampak tidak punya pilihan selain migrasi dalam kondisi terpaksa, dengan timeline yang tidak dikontrol sendiri dan sering kali ke platform yang terms-nya lebih tidak menguntungkan. Biaya migrasi paksa ini, jika dimasukkan sebagai probabilistic cost ke dalam proyeksi jangka panjang, akan menggeser break-even point (titik impas) antara SaaS dan custom secara signifikan lebih awal.
Spesifikasi kebutuhan yang akurat, bukan yang ideal, tapi yang mencerminkan bagaimana proses bisnis benar-benar berjalan hari ini. Ini adalah dokumen yang menjadi dasar seluruh estimasi biaya, timeline, dan lingkup sistem yang akan dibangun. Spesifikasi yang baik dalam bentuk Software Requirement Specification (SRS) menghasilkan estimasi yang bisa dipercaya dan sistem yang sesuai ekspektasi. Investasikan waktu untuk mendokumentasikan proses aktual secara detail sebelum melibatkan vendor atau mitra manapun, langkah ini tidak membutuhkan biaya tapi menentukan akurasi seluruh kalkulasi yang mengikutinya.
Kesimpulan
Pertanyaan “terus bayar atau bangun sendiri” memiliki jawaban yang berbeda tergantung pada angka spesifik setiap perusahaan, tapi arahnya. Untuk perusahaan yang sudah melewati tahun kedua dengan volume pengguna yang signifikan, hampir selalu menunjuk ke satu kesimpulan yang sama. Yang menghambat keputusan bukan ketidakjelasan angkanya, tapi kombinasi dari sunk cost yang terasa sayang ditinggalkan. Asumsi yang salah tentang apa yang dimaksud “membangun sendiri,” dan keengganan untuk memulai evaluasi yang terasa lebih kompleks dari yang sebenarnya.
Setiap bulan yang berlalu dengan model yang salah bukan hanya biaya bulan itu. Ia adalah bulan di mana kurva dua model semakin berjauhan, dan titik di mana keputusan akhirnya diambil akan selalu terasa lebih terlambat dari yang seharusnya.
BADR Interactive telah mendampingi perusahaan enterprise Indonesia, termasuk Pertamina, Astra, BPOM, dan Kementerian Keuangan, dalam proses transisi dari sistem subscription ke sistem yang dimiliki penuh, termasuk kalkulasi bisnis yang membantu tim internal meyakinkan komite anggaran dengan angka yang bisa diverifikasi. Jika Anda sedang di titik yang sama dan ingin memulai dengan kalkulasi yang jujur untuk kondisi spesifik perusahaan Anda, mulai diskusi dengan tim BADR di badr.co.id, termasuk evaluasi apakah kondisi Anda sudah tepat untuk beralih atau belum.
