Tiga Model Utama
Project-based: vendor bertanggung jawab atas hasil akhir (scope, timeline, tim). Cocok untuk kebutuhan yang terdefinisi penuh - company profile, migrasi sistem, pembangunan aplikasi dengan spesifikasi matang. Anda membeli outcome.
Dedicated team: vendor menyediakan tim lintas-fungsi (PM, engineer, QA) yang bekerja khusus untuk Anda dalam sprint berkelanjutan. Prioritas bisa berubah setiap sprint karena Anda membeli kapasitas produktif, bukan scope tetap. Ini model alami untuk produk digital yang berkembang lewat umpan balik pasar.
Staff augmentation: individu spesialis menyatu dengan tim internal Anda, dikelola manajer Anda, mengikuti proses Anda. Anda membeli keahlian tambahan tanpa membuka rekrutmen berbulan-bulan.
Perbandingan Biaya, Kecepatan, dan Kontrol
| Aspek | Project-Based | Dedicated Team | Staff Augmentation |
|---|---|---|---|
| Kecocokan requirement | Jelas & stabil | Berevolusi | Sudah punya roadmap sendiri |
| Basis biaya | Harga paket per milestone | Rate bulanan per tim | Rate bulanan per orang |
| Kontrol prioritas harian | Rendah (via PM vendor) | Tinggi (product owner Anda) | Penuh (manajer langsung) |
| Kecepatan mulai | Sedang (discovery dulu) | Cepat (tim siap) | Paling cepat |
| Risiko scope creep | Di vendor (fix price) | Dikelola via backlog | N/A |
| Pencabutan | Akhir proyek + handover | Notifikasi 1–2 bulan | Notifikasi 1 bulan |
| Ukuran tipikal di Indonesia | Rp50jt–Rp1M+ /proyek | Rp60–250jt/bulan/tim | Rp15–60jt/bulan/orang |
Angka di baris terakhir adalah rentang pasar 2025–2026 untuk vendor menengah dengan track record; harga jauh di bawahnya biasanya berarti trade-off di kualitas engineer atau manajemen proyek.
Decision Tree Memilih Model
Jawab empat pertanyaan ini berurutan:
- Apakah requirement bisa ditulis lengkap hari ini tanpa berubah? Ya → project-based layak dipertimbangkan. Tidak → lanjut.
- Apakah Anda punya tim teknologi internal yang mengerti produk? Ya → staff augmentation untuk menambah kapasitas. Tidak → lanjut.
- Apakah produk butuh iterasi rutin dengan feedback pasar? Ya → dedicated team. Tidak → kumpulkan requirement lebih matang dulu, baru project-based.
- Apakah anggaran capital (sekali) lebih cocok daripada operasional (bulanan) bagi laporan keuangan Anda? Ini sering menjadi penentu final antara project-based dan dedicated - libatkan finance sejak awal.
Kesalahan paling mahal bukan memilih vendor yang salah, melainkan memakai model kontrak yang salah untuk tahap kedewasaan produk Anda.
Lima Klausul Kontrak yang Menentukan
Apa pun modelnya, lima hal ini yang membedakan kerja sama yang sehat dari sengketa: (1) definisi done - acceptance criteria tertulis, bukan “sesuai kesepakatan”; (2) kepemilikan IP dan kode - repositori di akun Anda sejak hari pertama; (3) skema DP dan milestone - standar pasar 30–40% DP, sisanya mengikuti penyerapan; (4) garansi bug-fix pasca rilis - 30–90 hari adalah wajar; (5) klausul keluar - handover dokumentasi, akses infrastruktur, dan knowledge transfer yang wajib dipenuhi vendor bila kerja sama berakhir. Vendor percaya diri tidak akan keberatan dengan klausul keluar yang rapi.
Biaya Tersembunyi di Tiap Model
Harga per jam atau per proyek adalah ujung gunung es. Model project-based menyembunyikan biaya perubahan pikiran: requirement yang berubah di tengah berubah menjadi change request berbayar - wajar secara kontrak, namun sering mengejutkan. Dedicated team menyembunyikan biaya keterlibatan manajemen: tanpa product owner internal yang aktif 30–50% waktu, tim akan mengerjakan asumsi yang salah dengan sangat efisien. Staff augmentation menyembunyikan biaya pengetahuan yang menguap - orang yang keluar membawa konteks, sehingga turnover dua-tiga kali setahun membuat tim Anda selalu memulai dari nol. Tanyakan vendor bagaimana mereka mengelola ketiga risiko ini; jawabannya lebih mencerahkan daripada rate card.
Dua Jalur Nyata, Dua Hasil Berbeda
Dua klien kami dengan kebutuhan serupa (platform order management) memilih jalur berbeda - dan keduanya benar sesuai konteksnya. Yang pertama, marketplace B2C dengan pasar yang masih dicari, mengambil dedicated team: MVP rilis di bulan ketiga, pivot fitur utama dua kali dalam enam bulan berdasarkan data pengguna, dan tidak ada satu rupiah pun terbuang untuk membangun fitur yang ternyata tidak dipakai. Yang kedua, distributor dengan proses bisnis matang dan regulasi pelaporan kaku, memilih project-based dengan spesifikasi 40 halaman: hasil diserahkan tepat scope, diuji UAT tiga pekan, dan hingga kini hanya butuh maintenance ringan. Justru bila posisi mereka ditukar - spesifikasi cair dikerjakan fix-price, atau proses matang dikerjakan sprint terbuka - kedua proyek sama-sama akan kacau.
Migrasi Antar Model tanpa Drama
Model engagement seharusnya dievaluasi setiap enam-bulan-se tahun, dan transisinya bisa rapi bila tiga hal disiapkan sejak awal: repositori kode dan infrastruktur berada di akun Anda (bukan akun vendor), dokumentasi arsitektur diperbarui sebagai deliverable rutin tiap milestone/sprint, dan klausul handover mencantumkan durasi knowledge transfer minimum (dua sampai empat pekan untuk sistem menengah). Vendor yang baik justru menghargai klien yang merencanakan keluar-masuk model secara dewasa - kerja sama yang bisa berakhir rapi biasanya juga berjalan rapi.
Sepuluh Pertanyaan untuk Vendor Sebelum Tanda Tangan
Jawaban atas pertanyaan-pertanyaan ini lebih prediktif daripada portofolio apa pun: (1) Siapa persennya orang di tim kami, dan boleh kami wawancara engineer-nya - bukan hanya sales? (2) Berapa rasio turnover engineer di proyek-proyek setahun terakhir? (3) Bagaimana proses kalian menangani requirement yang berubah di tengah jalan - beri satu contoh nyata. (4) Di akun siapa kode dan infrastruktur disimpan, dan kapan kami mendapat aksesnya? (5) Apa definisi “selesai” kalian, dan bagaimana kami mengujinya sebelum membayar milestone? (6) Siapa yang on-call setelah rilis, dengan SLA respons berapa jam? (7) Tunjukkan dokumentasi arsitektur yang diserahkan pada handover proyek serupa. (8) Bagaimana kalian menjaga pengetahuan saat engineer resign di tengah proyek? (9) Apa yang terjadi bila timeline meleset karena kesalahan estimasi kalian - siapa menanggung? (10) Kapan kalian pernah menyarankan klien untuk tidak membangun sesuatu?
Vendor yang baik menjawab spesifik dan nyaman dengan angka. Jawaban seperti “tergantung nanti” pada butir 4, 6, dan 9 adalah sinyal merah paling konsisten.
SLA yang Masuk Akal (dan Sering Diminta Berlebihan)
| Aspek | Wajar untuk Sistem Menengah | Tanda Overkill / Red Flag |
|---|---|---|
| Respons insiden critical | ≤ 1 jam jam kerja; ≤ 4 jam luar jam kerja | “15 menit 24/7” tanpa biaya retainer sesuai |
| Pemulihan (MTTR) target | ≤ 4 jam jam kerja | “Nol downtime” - tidak ada yang bisa menjaminnya |
| Ganti rugi downtime | Kredit bulanan layanan | Kompensasi omzet bisnis - vendor tak akan tanda tangan sungguhan |
| Bug-fix garansi | 30–90 hari pasca rilis | “Selamanya” - biasanya tersembunyi di definisi bug |
SLA terbaik adalah yang kedua pihak benar-benar sanggup memenuhi dan mau menandatangani tanpa catatan kaki panjang.
Penutup
Model engagement bukan komitmen seumur hidup - ia harus dievaluasi tiap kali tahap produk berubah. Banyak klien kami memulai project-based untuk MVP, lalu naik ke dedicated team begitu produk mulai menemukan pasar. Bila Anda sedang menimbang model untuk kebutuhan 2026 ini dan ingin pendapat kedua atas estimasi yang sudah Anda terima, kirimkan ringkasannya ke Ayah2Ngoding di hello@ayah2ngoding.com - kami akan memberi masukan jujur, termasuk bila jawabannya adalah “tidak perlu vendor sama sekali.”
Diskusi & Komentar (0)