Mengapa UKM Indonesia Harus Peduli pada Maintenance Software, Bukan Hanya Build

Sebagian besar diskusi tentang software kustom fokus pada build. Pitch vendor, timeline, harga. Build-nya menarik. Build ship dalam beberapa bulan dan ada launch.

Hal yang tidak ada yang benar-benar mau bicara: 70% dari biaya seumur hidup software kustom adalah maintenance, bukan build. UKM yang tidak merencanakan untuknya konsisten berakhir dengan software yang diam-diam membusuk — masih jalan, tapi semakin rapuh, mahal untuk diubah, dan akhirnya diganti dengan rasa sakit yang lumayan.

Layak dipahami apa maintenance sebenarnya dan berapa biayanya sebelum Anda komitmen membangun apa pun yang kustom.

Apa “maintenance” sebenarnya berarti

Maintenance bukan hanya bug fix. Itu kategori yang mencakup:

• Update keamanan. Library dan platform yang Anda bangun di atasnya dapat patch keamanan bulanan. Melewatinya menciptakan kerentanan. Menerapkannya kadang merusak hal.
• Kompatibilitas dengan layanan yang software Anda tergantung. Saat API Tokopedia berubah, integrasi Anda rusak kalau tidak ada yang mengawasi. Saat Stripe deprecate endpoint, checkout Anda berhenti bekerja.
• Bug fix untuk masalah yang muncul di production. Hal yang Anda tidak tangkap di testing karena hanya terjadi dengan data pelanggan nyata di skala nyata.
• Penambahan fitur kecil. Hampir setiap “kami sudah ship” akhirnya jadi “bisakah juga lakukan X?” Versi yang lebih kecil dari kebutuhan itu harus murah dan predictable.
• Update dokumentasi. Saat tim yang membangunnya berubah (dan selalu), orang yang sekarang maintenance perlu memahami apa yang dibangun.
• Tuning performance. Saat data tumbuh, query yang cepat di 10.000 baris lambat di 1.000.000.

Lewati salah satu ini terlalu lama dan softwarenya menurun. Pertama kali sesuatu rusak, Anda membayar tarif darurat untuk memperbaiki.

Biaya berkelanjutan yang realistis

Untuk software kustom UKM Indonesia di 2026:

• Maintenance ringan (~5% biaya build per tahun): patch keamanan, bug fix kecil sesekali, pekerjaan fitur minimal. Software dasarnya beku. OK untuk sistem stabil yang tidak perlu evolve.
• Maintenance aktif (10–15% biaya build per tahun): patch, fitur kecil reguler, bug fix, update dependency, pekerjaan performance minor sesekali. Tepat untuk sebagian besar sistem UKM.
• Maintenance berat / continuous improvement (20–30% biaya build per tahun): pekerjaan fitur baru reguler, peningkatan arsitektur, tuning performance, iterasi UX berkelanjutan. Tepat saat software inti bisnis dan posisi kompetitif tergantung pada evolusi berkelanjutan.

Proyek yang biaya Rp 150 juta untuk dibangun biasanya butuh Rp 15–22 juta per tahun maintenance aktif. Lewati dan Anda menghemat Rp 15 juta per tahun selama dua tahun, lalu membayar Rp 80 juta untuk menggali keluar dari technical debt yang menumpuk di tahun tiga.

Apa yang salah saat UKM melewatinya

Pola yang konsisten kami lihat:

Tahun 1: tidak ada yang terlihat

Software jalan baik. Tidak ada yang menyentuh. Pemilik mengucapkan selamat ke diri sendiri atas penghematannya.

Tahun 2: gangguan kecil

Beberapa integrasi berhenti bekerja. Performance jadi lambat di halaman tertentu. Tim mengakali. Pemilik berpikir: “kita akan kerjakan akhirnya.”

Tahun 3: masalah nyata

Sesuatu rusak di momen buruk. Integrasi pembayaran gagal saat flash sale. Celah log audit menyebabkan masalah compliance. Vendor asli tidak bisa dihubungi atau sudah pindah. Tarif darurat berlaku, panik masuk.

Tahun 4: keputusan penggantian

Sistem sudah menumpuk technical debt yang cukup sehingga memperbaiki lebih mahal daripada membangun ulang. UKM berakhir membayar software yang sama dua kali dalam lima tahun.

Pola ini begitu umum sehingga kami mulai membangun kontrak maintenance ke setiap proposal build awal — bukan karena kami mencoba upsell, tapi karena hasil alternatifnya predictably buruk.

Cara memikirkan maintenance selama build

Tiga hal untuk dikunci sebelum menandatangani kontrak build:

1. Retainer maintenance dengan scope jelas

Definisikan apa yang termasuk bulanan: patch keamanan, update dependency, X jam pekerjaan fitur, SLA respon untuk darurat. Definisikan apa yang dikecualikan: perubahan arsitektur besar, modul produk baru.

Retainer bulanan UKM biasa: Rp 5–18 juta mencakup 8–25 jam pekerjaan per bulan plus ketersediaan on-call untuk masalah kritikal.

2. Dokumentasi sebagai deliverable

Build belum selesai sampai dokumentasi selesai. Minimal: overview arsitektur, instruksi deployment, environment variable, dependency layanan pihak ketiga, runbook untuk masalah umum.

Ini terdengar membosankan. Itu perbedaan antara bisa berganti vendor maintenance dalam seminggu vs tiga bulan.

3. Kepemilikan dan akses kode

Anda harus memiliki kode, bukan vendor. Source code di repository yang Anda kontrol. Akses production lewat akun yang Anda miliki. Domain, hosting, dan layanan atas nama Anda.

Vendor yang push back ini menciptakan leverage masa depan atas Anda. Pergi.

Kapan investasi lebih di maintenance

Tiga trigger yang harus menaikkan investasi maintenance Anda:

• Software mulai menangani lebih banyak pendapatan atau operasi. Kalau sistem memproses Rp 1 miliar/tahun order saat launch dan Rp 10 miliar/tahun sekarang, biaya outage 10x. Maintenance harus scale up sebelum sesuatu rusak.
• Tim yang membangunnya sudah turn over penuh. Orang baru maintenance kode lama butuh lebih banyak waktu memahaminya. Budget sesuai.
• Tech stack menua. Stack 4 tahun mulai butuh pekerjaan refresh nyata. Rencanakan.

Framing jujur

Membangun software kustom seperti membeli gedung. Biaya konstruksinya signifikan, tapi kalau Anda tidak budget untuk atap, pipa ledeng, refresh periodik — gedungnya menurun dan akhirnya harus diganti. Struktur yang bertahan dekade adalah yang pemiliknya budget untuk upkeep dari hari pertama.

Kalau Anda mendekati proyek software kustom dan ingin merencanakan siklus hidup penuh secara realistis, satu jam percakapan biasanya menjernihkan gambaran maintenance seperti apa untuk kasus spesifik Anda. Kami melakukannya tanpa biaya.