Fixed Price, Time and Material, atau Retainer? Memilih Model Harga Proyek Software

Ketika bisnis meminta penawaran pengembangan software, jawaban yang diterima sering terlihat tidak bisa dibandingkan. Satu vendor menawarkan harga tetap untuk seluruh proyek. Vendor lain menagih per jam kerja. Vendor ketiga mengusulkan biaya bulanan tetap untuk sebuah tim. Perbedaan ini bukan sekadar soal angka, tetapi soal siapa yang menanggung risiko ketika kebutuhan berubah, pekerjaan lebih sulit dari perkiraan, atau jadwal molor.

Memahami model harga membantu Anda memilih yang cocok dengan kondisi proyek, bukan sekadar yang tampak paling murah di proposal. Artikel ini membandingkan tiga model yang paling umum, yaitu harga tetap (fixed price), waktu dan bahan (time and material), serta retainer, beserta model campuran, risiko tiap model, dan pertanyaan yang perlu diajukan sebelum menandatangani kontrak.

Ringkasan

• Harga tetap cocok jika lingkup jelas dan stabil; risikonya bergeser ke vendor, dan perubahan biasanya dikenakan biaya tambahan
• Time and material cocok jika kebutuhan masih berkembang; fleksibel, tetapi anggaran akhir kurang pasti tanpa pengawasan
• Retainer cocok untuk kebutuhan berkelanjutan seperti pemeliharaan dan pengembangan bertahap
• Model campuran, misalnya fase penemuan berbayar per waktu lalu pembangunan berharga tetap, sering menjadi yang paling masuk akal
• Model apa pun tetap membutuhkan lingkup tertulis, jadwal serah terima, kriteria penerimaan, dan mekanisme perubahan yang jelas

Mengapa model harga lebih penting daripada angkanya

Dua penawaran dengan angka yang sama dapat berujung pada hasil yang sangat berbeda. Harga tetap yang murah dengan lingkup samar sering berakhir dengan perdebatan tentang apa yang termasuk, kualitas yang dikorbankan, atau biaya perubahan yang membengkak. Tarif per jam yang tampak wajar bisa berakhir mahal jika tidak ada pengendalian lingkup dan pelaporan progres. Karena itu, pertanyaan pertama bukan "berapa", melainkan "siapa yang menanggung risiko apa".

Banyak kegagalan proyek yang dibahas dalam artikel kenapa proyek software gagal berakar pada ketidakcocokan antara sifat proyek dan model komersialnya, misalnya meminta harga tetap untuk kebutuhan yang belum jelas.

Model 1: Harga tetap (fixed price)

Vendor dan klien menyepakati lingkup, jadwal, dan harga total di awal. Klien membayar sesuai termin yang disepakati, biasanya berdasarkan tonggak seperti uang muka, penyelesaian desain, dan serah terima.

Kelebihan

• Anggaran mudah diprediksi dan disetujui di internal perusahaan
• Risiko biaya berlebih akibat pekerjaan yang lebih sulit dari perkiraan ditanggung vendor
• Mudah dibandingkan antarpenawaran jika lingkupnya sama

Kekurangan dan risiko

• Lingkup harus sangat jelas sejak awal, padahal kebutuhan bisnis sering baru dipahami setelah melihat prototipe
• Setiap perubahan menjadi negosiasi dan biasanya dikenakan biaya, sehingga klien enggan mengubah arah meskipun perlu
• Vendor memiliki dorongan untuk memangkas kualitas, pengujian, atau dokumentasi demi menjaga margin
• Penawaran harga tetap sering sudah memasukkan cadangan risiko, sehingga tidak selalu lebih murah

Harga tetap paling cocok untuk proyek dengan lingkup terdefinisi baik, seperti website company profile, integrasi tertentu, atau migrasi dengan spesifikasi jelas. Kualitas dokumen kebutuhan sangat menentukan, sehingga baca juga cara menyusun dokumen kebutuhan software.

Model 2: Time and material

Klien membayar berdasarkan waktu yang benar-benar dipakai, biasanya tarif per jam atau per hari untuk setiap peran, ditambah biaya tertentu jika ada. Vendor memberikan estimasi, tetapi estimasi itu bukan batas yang mengikat kecuali disepakati demikian.

Kelebihan

• Fleksibel terhadap perubahan, sehingga cocok dengan metode iteratif yang dibahas pada artikel [Agile atau Waterfall](/blog/agile-atau-waterfall-metode-proyek-software-untuk-bisnis)
• Klien membayar untuk pekerjaan yang dilakukan, bukan untuk cadangan risiko
• Proyek dapat dimulai lebih cepat tanpa menunggu spesifikasi lengkap
• Prioritas dapat diubah di tengah jalan sesuai pembelajaran dari pengguna

Kekurangan dan risiko

• Total biaya akhir tidak pasti dan dapat membengkak jika lingkup tidak dikendalikan
• Klien menanggung risiko pekerjaan yang lebih lama dari perkiraan
• Memerlukan transparansi: laporan jam kerja, progres, dan hasil yang dapat diperiksa
• Perlu orang di sisi klien yang aktif mengelola prioritas dan menerima hasil

Agar risikonya terkendali, tetapkan batas anggaran per periode, tinjau hasil secara berkala pada demo rutin, dan minta laporan yang menghubungkan jam kerja dengan fitur yang selesai. Pendekatan memulai kecil dalam artikel MVP aplikasi bisnis sangat serasi dengan model ini.

Model 3: Retainer

Klien membayar biaya tetap berkala, misalnya bulanan, untuk memperoleh kapasitas tertentu dari vendor: sejumlah jam, satu tim khusus, atau paket layanan dengan waktu respons yang dijamin. Retainer cocok untuk kebutuhan berkelanjutan seperti pemeliharaan, perbaikan bug, pembaruan keamanan, dan pengembangan fitur kecil secara bertahap.

Kelebihan

• Biaya bulanan mudah dianggarkan dan hubungan jangka panjang membangun pemahaman vendor atas sistem Anda
• Waktu respons lebih cepat untuk masalah mendesak karena kapasitas sudah dicadangkan
• Cocok untuk perawatan, seperti dibahas dalam artikel [pemeliharaan aplikasi setelah peluncuran](/blog/pemeliharaan-aplikasi-setelah-peluncuran)

Kekurangan dan risiko

• Jam atau kapasitas yang tidak terpakai bisa hangus, sehingga Anda membayar untuk sesuatu yang tidak digunakan
• Tanpa daftar prioritas, kapasitas sering terserap pekerjaan kecil yang kurang berdampak
• Perlu kejelasan apa yang termasuk dalam retainer dan apa yang dihitung terpisah

Model campuran yang sering paling masuk akal

Banyak proyek yang berhasil menggabungkan model. Pola yang umum adalah fase penemuan dan desain dikerjakan dengan time and material untuk waktu singkat, menghasilkan lingkup, prototipe, dan estimasi yang lebih tajam. Setelah itu, bagian yang sudah jelas dibangun dengan harga tetap per fase, sementara bagian yang masih berkembang tetap dikerjakan secara time and material dengan batas anggaran. Setelah peluncuran, pemeliharaan dilanjutkan dengan retainer.

1. 01Fase penemuan dan prototipe berdurasi pendek dengan hasil tertulis berupa lingkup, prioritas, dan estimasi
2. 02Pembangunan modul inti dengan harga tetap per fase, dibayar per tonggak
3. 03Fitur tambahan dengan time and material dan batas anggaran per bulan
4. 04Pemeliharaan dan peningkatan berkelanjutan dengan retainer

Pendekatan bertahap ini mengurangi taruhan di awal dan memberi kedua pihak kesempatan menilai kecocokan sebelum komitmen besar. Pertimbangan tambahan untuk proyek lintas wilayah ada pada artikel outsourcing pengembangan software ke Indonesia.

Cara memilih model yang tepat

• Seberapa jelas lingkup? Jika jelas dan stabil, harga tetap masuk akal; jika masih berkembang, pilih time and material atau pendekatan bertahap
• Seberapa besar toleransi terhadap perubahan anggaran? Anggaran kaku mendukung harga tetap atau time and material dengan batas
• Seberapa aktif tim Anda dapat terlibat? Time and material menuntut keterlibatan klien yang konsisten
• Apakah kebutuhannya sekali jadi atau berkelanjutan? Kebutuhan berkelanjutan cocok dengan retainer
• Seberapa besar kepercayaan pada vendor? Hubungan baru mendapat manfaat dari fase kecil sebagai uji coba

Hal yang perlu tertulis di kontrak, apa pun modelnya

Model harga hanya satu bagian dari kontrak. Poin yang sama pentingnya dibahas pada artikel poin penting kontrak pengembangan software. Pastikan setidaknya hal berikut tertulis:

• Lingkup pekerjaan dan apa yang tidak termasuk
• Kriteria penerimaan yang dapat diuji, serta proses [uji penerimaan pengguna](/blog/uat-pengujian-sebelum-aplikasi-diluncurkan)
• Jadwal, tonggak, dan konsekuensi keterlambatan dari kedua belah pihak
• Mekanisme perubahan lingkup: siapa mengajukan, bagaimana estimasi dibuat, siapa menyetujui
• Kepemilikan kode, desain, dan data, serta akses ke repositori dan lingkungan
• Masa garansi perbaikan bug setelah serah terima dan biaya pemeliharaan sesudahnya
• Ketentuan kerahasiaan, keamanan data, dan pengakhiran kontrak

Tanda bahaya dalam penawaran

• Harga jauh lebih rendah daripada penawaran lain tanpa penjelasan lingkup
• Lingkup ditulis dengan istilah umum seperti "sistem lengkap" tanpa daftar fitur
• Tidak ada penjelasan tentang pengujian, keamanan, dan dokumentasi
• Tarif per jam tanpa estimasi, batas, atau pelaporan
• Kode atau akses ditahan sampai pelunasan tanpa perjanjian penitipan yang jelas
• Vendor menolak membahas perubahan lingkup sebelum kontrak ditandatangani

Jika proyek sudah berjalan dan terasa macet, artikel menyelamatkan proyek software yang macet membahas cara menilai ulang kontrak dan pilihan yang tersedia. Untuk gambaran biaya yang lebih menyeluruh, termasuk biaya di luar pengembangan, baca menghitung biaya sebenarnya proyek software dan checklist memilih software house.

Contoh sederhana: sebuah perusahaan distribusi ingin membangun portal pemesanan untuk pelanggan B2B. Kebutuhan inti, seperti katalog, keranjang, dan riwayat pesanan, sudah jelas sehingga cocok dikerjakan dengan harga tetap. Fitur lanjutan seperti rekomendasi produk dan integrasi pengiriman masih berkembang, jadi lebih aman dengan time and material berbatas anggaran. Setelah peluncuran, perbaikan kecil dan pembaruan keamanan masuk ke retainer bulanan. Tiga model berbeda untuk satu produk, masing-masing dipilih sesuai tingkat kepastian pekerjaannya.

Pertanyaan yang sering diajukan

Mana yang paling murah di antara ketiga model? Tidak ada yang otomatis paling murah. Harga tetap mungkin memuat cadangan risiko, time and material bisa membengkak tanpa kendali, dan retainer mahal jika kapasitasnya tidak terpakai. Bandingkan total biaya kepemilikan, bukan hanya angka penawaran.

Bisakah berpindah model di tengah proyek? Bisa, asalkan disepakati tertulis. Contohnya memulai dengan time and material untuk penemuan, lalu beralih ke harga tetap saat lingkup sudah jelas.

Bagaimana menghindari pembengkakan biaya pada time and material? Tetapkan batas anggaran per periode, minta demo rutin, prioritaskan daftar fitur, dan tinjau laporan jam kerja bersama vendor.

Apakah garansi sebaiknya tertulis di kontrak? Ya. Tentukan lamanya, jenis masalah yang ditanggung, dan waktu respons, agar tidak ada perdebatan setelah serah terima.

Berapa lama kontrak retainer yang wajar? Mulailah dengan periode pendek disertai tinjauan berkala, lalu perpanjang jika hasilnya memuaskan.

Kesimpulan

Tidak ada model harga yang selalu terbaik. Harga tetap memberi kepastian saat lingkup jelas, time and material memberi fleksibilitas saat kebutuhan berkembang, dan retainer menjaga sistem tetap sehat setelah peluncuran. Banyak proyek paling baik dijalankan dengan gabungan ketiganya secara bertahap. Pilih model berdasarkan kejelasan lingkup, toleransi anggaran, dan tingkat keterlibatan tim Anda, lalu pastikan kontraknya menetapkan lingkup, kriteria penerimaan, dan mekanisme perubahan dengan jelas.