12?
Pertanyaan Wajib
Strategy10 Mei 2026·15 menit baca·Alba Tech
Daftar Pertanyaan
  1. Project skala mirip (3 contoh)
  2. Referensi klien langsung
  3. Tim eksekusi sebenarnya
  4. Proses discovery
  5. Estimasi waktu & biaya
  6. Handle perubahan scope
  7. Maintenance pasca-launch
  8. Project yang ditolak
  9. Handle krisis project
  10. In-house vs outsource
  11. Struktur pembayaran
  12. Yang akan disesalkan

Cara Memilih Software House di Jakarta: 12 Pertanyaan yang Harus Anda Tanyakan Sebelum Tanda Tangan Kontrak

Diperbarui Mei 2026 — 15 menit baca

Memilih software house yang salah adalah salah satu kesalahan termahal yang bisa dilakukan bisnis. Bukan hanya soal uang yang hilang — tapi waktu, momentum bisnis, dan kepercayaan internal tim yang sulit dipulihkan setelah project gagal.

Masalahnya: hampir semua vendor terlihat profesional di pitch meeting. Website mereka rapi, deck mereka meyakinkan, sales mereka percaya diri. Bagaimana Anda membedakan vendor yang akan deliver dari vendor yang akan kasih ekspektasi tinggi lalu hilang setelah dapat DP?

Jawabannya: tanyakan 12 pertanyaan ini sebelum tanda tangan kontrak. Pertanyaan-pertanyaan ini bukan sekadar formalitas — ini adalah filter yang akan memisahkan vendor yang benar-benar capable dari yang sekadar bisa jualan.

Kami menulis panduan ini bukan dari sudut pandang teori. Sebagai software house yang sudah jalan 5+ tahun, kami sering jadi vendor pengganti setelah klien punya pengalaman pahit dengan vendor sebelumnya. Pola kegagalannya hampir selalu sama — dan hampir selalu bisa dideteksi di awal kalau klien tahu apa yang harus ditanyakan.

Kalau Anda belum yakin apakah Anda sebenarnya butuh software house atau pilihan lain (freelancer atau konsultan IT), baca dulu panduan kami tentang konsultan IT vs software house vs freelancer. Setelah yakin software house adalah pilihan yang tepat, lanjutkan ke 12 pertanyaan di bawah.


Sebelum Mulai: Mindset yang Tepat

Sebelum masuk ke pertanyaannya, satu hal penting:

Anda bukan sedang membeli produk. Anda sedang merekrut partner.

Software house yang baik akan menggarap project Anda selama berbulan-bulan, kadang bertahun-tahun. Mereka akan tahu detail bisnis Anda, akses sistem Anda, dan jadi tulang punggung operasional digital Anda. Pilihan ini lebih mirip merekrut tim dibanding membeli laptop.

Karena itu, jawaban "yang murah dan cepat" adalah jebakan. Yang Anda cari adalah yang capable dan jujur — bahkan kalau itu berarti mereka akan bilang "project Anda lebih cocok dengan vendor lain" atau "kami tidak ambil project di bawah Rp X juta."

Vendor yang menerima semua project, berapapun harganya, dengan timeline apapun, adalah red flag terbesar. Mereka akan over-promise di awal, lalu under-deliver atau hilang di tengah jalan.

Sekarang ke pertanyaannya.


PERTANYAAN 1: "Tunjukkan 3 project skala mirip dengan project saya."

Apa yang Anda cari

Bukan portfolio acak yang impressive — Anda mencari bukti pengalaman di konteks yang relevan.

Kalau project Anda mobile app retail dengan integrasi POS dan ERP, melihat portfolio mereka bikin company profile bank ternama tidak relevan. Itu skill set berbeda. Anda butuh tahu: apakah mereka pernah handle masalah seperti milik saya?

Tanda jawaban yang jujur

✅ Mereka langsung sebut 3-5 project konkret dengan nama klien (atau anonim kalau di bawah NDA), berikut detail teknologi dan tantangan yang dihadapi.

✅ Mereka berani bilang "kami belum pernah project persis seperti ini, tapi kami punya pengalaman dekat di X dan Y" — kejujuran ini lebih bernilai dari klaim palsu.

✅ Mereka bisa cerita detail teknis yang spesifik — bukan hanya "kami pakai React Native" tapi "kami struggle dengan offline sync di iOS, akhirnya solve dengan WatermelonDB."

Tanda red flag

❌ Portfolio yang ditunjukkan semuanya generic landing page atau company profile, padahal Anda butuh sistem operasional kompleks.

❌ Mereka pamer logo brand besar tanpa bisa menjelaskan apa yang sebenarnya mereka kerjakan untuk brand itu.

❌ "Confidential, tidak bisa dibagikan" untuk semua project. Vendor yang serius bisa share setidaknya tipe project dan tantangan teknis tanpa melanggar NDA.

❌ Klaim seperti "kami sudah handle 500+ project" tapi tidak bisa sebut 5 yang relevan dengan kebutuhan Anda.


PERTANYAAN 2: "Saya boleh ngobrol langsung dengan 2 klien Anda sebelumnya?"

Apa yang Anda cari

Vendor yang capable akan bangga menyambungkan Anda ke klien existing — karena mereka tahu klien akan bicara baik. Vendor yang akan gagal akan menghindari ini dengan berbagai alasan.

Pertanyaan untuk klien referensi:

  • "Apakah project selesai sesuai timeline awal?"
  • "Apa yang mereka lakukan ketika ada masalah atau perubahan scope?"
  • "Bagaimana kualitas komunikasi mereka selama project?"
  • "Apakah Anda akan pakai mereka lagi untuk project berikutnya?"
  • "Apa kelemahan mereka yang harus saya antisipasi?"

Pertanyaan terakhir paling penting. Setiap vendor punya kelemahan. Klien yang jujur akan kasih tahu, dan Anda bisa menilai apakah kelemahan itu masalah untuk konteks Anda.

Tanda jawaban yang jujur

✅ Mereka langsung kasih 2-3 nama klien dan kontaknya, dengan catatan "tolong jangan ganggu di luar jam kerja ya."

✅ Mereka kasih klien yang punya project kompleks (bukan hanya yang paling sederhana), termasuk klien yang pernah ada friksi tapi resolve dengan baik.

Tanda red flag

❌ "Klien kami tidak suka diganggu" atau "kami menjaga kerahasiaan klien" untuk semua referensi. Klien yang puas biasanya senang berbagi pengalaman.

❌ Hanya kasih 1 referensi yang kebetulan adalah teman dekat owner.

❌ Testimonial di website yang tidak ada nama lengkap, tidak ada foto, tidak ada link LinkedIn yang bisa diverifikasi.


PERTANYAAN 3: "Siapa nama orang yang akan benar-benar mengerjakan project saya?"

Apa yang Anda cari

Yang Anda hadapi di pitch meeting adalah sales atau founder. Yang akan mengerjakan project Anda adalah PM, designer, dan developer. Sering kali ini orang yang sangat berbeda — dan kualitasnya bisa sangat berbeda.

Salah satu jebakan klasik: founder atau senior engineer pitch dengan meyakinkan, project dimulai, lalu yang ngoding ternyata junior fresh graduate yang baru join 2 bulan.

Tanda jawaban yang jujur

✅ Mereka kenalkan nama PM yang akan handle project — idealnya di pitch meeting itu sendiri.

✅ Mereka transparan: "Senior engineer X akan jadi technical lead, didukung 2 developer dengan pengalaman 3+ tahun."

✅ Mereka mention nama designer, dan kalau diminta, bisa share portfolio individual designer-nya.

✅ Setelah kontrak ditandatangani, mereka kasih kickoff meeting dengan tim eksekusi, bukan hanya sales.

Tanda red flag

❌ "Kami tim besar, jangan khawatir, semua expert" — vague answer tanpa nama spesifik.

❌ "Kami akan assign tim setelah kontrak ditandatangani" — Anda tidak akan bertemu tim sampai sudah committed.

❌ Founder pitch sebagai "saya yang akan handle project Anda" tapi sebenarnya dia handle 10 project bersamaan dan delegate ke junior tanpa supervisi proper.


PERTANYAAN 4: "Apa proses discovery Anda sebelum mulai coding?"

Apa yang Anda cari

Vendor yang langsung loncat ke coding tanpa proper discovery adalah resep untuk project gagal. Mereka akan bangun apa yang mereka kira Anda butuhkan, lalu setelah delivery, ternyata banyak gap dengan apa yang sebenarnya Anda butuhkan.

Software house profesional punya proses discovery jelas:

  • Workshop awal dengan stakeholder Anda
  • Wireframe atau prototype sebelum coding
  • Sign-off requirement document sebelum development dimulai
  • Iteration cycle untuk validasi sebelum commit ke production

Tanda jawaban yang jujur

✅ "Kami biasanya dedikasikan 1-3 minggu untuk discovery sebelum coding mulai. Outputnya: requirement document, wireframe, dan rencana sprint."

✅ Mereka tunjukkan template requirement document atau contoh wireframe dari project sebelumnya.

✅ Mereka jelaskan kapan dan bagaimana Anda akan diminta sign-off di setiap tahap.

✅ Mereka jelaskan apa yang terjadi kalau ada perubahan requirement di tengah jalan (change request process yang fair).

Tanda red flag

❌ "Kami langsung mulai coding aja, nanti adjust sambil jalan" — formula untuk project gagal.

❌ Tidak ada deliverable sebelum coding dimulai. Anda hanya dapat janji.

❌ Discovery diburu-buru jadi 1-2 hari karena "klien biasanya tidak suka tunggu lama" — kualitas sengaja dikorbankan untuk kelihatan cepat.

❌ Tidak ada proses change request — semua perubahan dianggap "biasa, kami akomodasi" — tapi nanti tagihan jadi membengkak tanpa transparansi.


PERTANYAAN 5: "Bagaimana cara Anda menghitung estimasi waktu dan biaya?"

Apa yang Anda cari

Estimasi yang baik berbasis breakdown task konkret, bukan tebakan kasar. Vendor profesional bisa menjelaskan: "Mobile app ini kami estimasi 3.5 bulan, breakdown-nya: 2 minggu discovery, 4 minggu development phase 1 (auth + onboarding), 4 minggu phase 2 (core features), 3 minggu phase 3 (integrations + polish), 2 minggu testing & deployment."

Vendor yang jelek akan kasih estimasi: "3 bulan, Rp 80 juta" tanpa bisa menjelaskan breakdown.

Tanda jawaban yang jujur

✅ Mereka break down project jadi milestone yang bisa diverifikasi.

✅ Mereka sebut faktor risiko yang bisa membuat estimasi meleset (dependency ke pihak ketiga, decision point yang menunggu input klien, dll).

✅ Mereka tunjukkan track record akurasi estimasi dari project sebelumnya — kalau biasanya overrun 20%, mereka jujur bilang itu.

✅ Estimasi mereka punya range, bukan angka tunggal yang terlalu presisi. "3-3.5 bulan" lebih jujur dari "tepat 90 hari kerja."

Tanda red flag

❌ Estimasi yang terlalu cepat dan terlalu murah dibanding kompetitor lain. Biasanya berarti scope dipotong diam-diam, atau vendor akan request budget tambahan di tengah jalan.

❌ Estimasi tunggal tanpa breakdown — "Rp 100 juta, 4 bulan, deal."

❌ Tidak mau commit ke timeline — semua "tergantung." Kalau semua tergantung, Anda tidak punya akuntabilitas.

❌ Klaim bisa selesai dalam timeline yang tidak realistis (mobile app dengan 30 fitur dalam 6 minggu, misalnya).


PERTANYAAN 6: "Bagaimana Anda handle perubahan scope di tengah project?"

Apa yang Anda cari

Realitanya: scope akan berubah selama project. User feedback akan datang, requirement bisnis berubah, ada hal yang baru kelihatan setelah prototype jadi. Pertanyaannya bukan "apakah scope akan berubah" tapi "bagaimana vendor handle perubahan ketika itu terjadi."

Tanda jawaban yang jujur

✅ Ada change request process yang jelas dan terdokumentasi.

✅ Perubahan kecil di-absorb tanpa biaya tambahan (vendor profesional tahu sedikit fleksibilitas penting untuk hubungan jangka panjang).

✅ Perubahan besar dievaluasi dengan transparan: "Ini akan tambah 2 minggu kerja dan Rp 20 juta, ini breakdown tasknya."

✅ Klien dilibatkan dalam decision tradeoff: "Kalau ini diprioritaskan, fitur X harus tunda — mau pilih yang mana?"

Tanda red flag

❌ "Tenang Pak, semua perubahan kami akomodasi, free." Ini terdengar enak tapi biasanya berarti: (a) mereka akan kasih tagihan diam-diam nanti, atau (b) kualitas akan dikorbankan, atau (c) timeline akan molor tanpa pemberitahuan.

❌ Setiap perubahan kecil jadi change request berbayar Rp 5 juta. Vendor seperti ini akan bikin Anda takut request perubahan, akhirnya delivery tidak match dengan kebutuhan.

❌ Mereka tidak punya proses tertulis untuk perubahan — semuanya diatur secara informal lewat WhatsApp. Resep untuk dispute nanti.


PERTANYAAN 7: "Apa yang akan terjadi 6 bulan setelah project selesai?"

Apa yang Anda cari

Project tidak benar-benar selesai di hari go-live. Sistem perlu maintenance, bug akan muncul, fitur kecil akan dibutuhkan, dan kadang ada krisis (server down, data corruption, security issue) yang butuh response cepat.

Vendor yang baik akan stay sebagai partner setelah launch. Vendor yang jelek akan hilang setelah final payment.

Tanda jawaban yang jujur

✅ Ada paket maintenance dengan SLA jelas (response time, uptime guarantee, scope yang dicover).

✅ Mereka jelaskan apa yang termasuk maintenance gratis (bug fix kritis dalam masa garansi) dan apa yang berbayar (fitur baru, perubahan signifikan).

✅ Ada handover document, source code repository yang Anda akses, dokumentasi teknis untuk tim internal Anda atau vendor pengganti nantinya.

✅ Mereka kasih opsi: bisa lanjut maintenance dengan mereka, atau Anda bisa pindah ke vendor lain — tidak ada lock-in artificial.

Tanda red flag

❌ "Maintenance tidak termasuk, harga akan dikalkulasi nanti setelah project selesai" — Anda terkunci dengan vendor yang punya leverage karena tahu sistemnya.

❌ Source code tidak dikasih ke klien. Beberapa vendor masih melakukan ini — itu praktik buruk yang bikin Anda hostage.

❌ Tidak ada dokumentasi teknis. Kalau besok mereka tutup, sistem Anda jadi black box.

❌ Source code dikasih tapi tidak ada handover document — klien tidak tahu cara deploy, environment variable apa yang dipakai, dependencies apa yang harus di-install.


PERTANYAAN 8: "Project apa yang Anda tolak ambil?"

Apa yang Anda cari

Vendor yang menerima semua project apapun bentuknya adalah red flag terbesar. Vendor profesional tahu kompetensi mereka dan punya filter — mereka tolak project di luar core competence, project dengan budget tidak masuk akal, atau klien yang menunjukkan tanda-tanda akan bermasalah.

Tanda jawaban yang jujur

✅ "Kami tidak ambil project di bawah Rp X juta karena overhead kami tidak ekonomis di sana."

✅ "Kami fokus di [tipe project], jadi project [tipe lain] kami tolak atau referral ke vendor lain yang lebih cocok."

✅ "Kami pernah tolak project yang timelinenya tidak realistis — lebih baik klien marah karena ditolak daripada kami terima dan delivery jelek."

✅ "Kami tidak ambil klien yang dari awal komunikasinya tidak menghargai tim kami."

Tanda red flag

❌ "Kami terima semua project, dari kecil sampai besar, tidak ada yang kami tolak."

❌ "Tidak ada batas budget minimum, semua bisa dinegosiasikan."

❌ Kelihatan terlalu agresif untuk closing meeting pertama — pressure tactic seperti "promo bulan ini saja" atau "kalau tanda tangan minggu ini ada diskon 20%."

❌ Setuju dengan timeline yang Anda kasih tanpa challenge sama sekali, padahal Anda sendiri tahu timeline-nya agresif.


PERTANYAAN 9: "Bagaimana cara Anda handle kalau project melenceng dari plan?"

Apa yang Anda cari

Setiap project akan punya momen krisis. Server crash di hari demo. Developer kunci sakit di tengah sprint. Integrasi pihak ketiga yang ternyata bermasalah. Bagaimana vendor merespons momen-momen ini menentukan apakah project akhirnya sukses atau gagal.

Tanda jawaban yang jujur

✅ Mereka cerita contoh konkret krisis di project sebelumnya dan bagaimana mereka handle. Bukan teori, tapi war story nyata.

✅ Ada escalation process — kalau PM tidak bisa solve, ada tech lead, ada owner yang ikut turun tangan.

✅ Komunikasi krisis transparan — klien diberi tahu segera, bukan disembunyikan sampai ketahuan.

✅ Mereka ambil tanggung jawab pada kesalahan mereka sendiri — termasuk willingness untuk overrun budget kecil tanpa charge klien kalau penyebabnya dari sisi vendor.

Tanda red flag

❌ "Project kami selalu lancar, tidak pernah ada masalah." Bohong. Setiap vendor pernah punya project bermasalah. Yang tidak mengakui ini hanya menyembunyikan.

❌ Selalu menyalahkan klien atau pihak ketiga ketika ada masalah. Tidak pernah ada akuntabilitas dari sisi vendor.

❌ Komunikasi krisis lambat. Server klien down, baru update 6 jam kemudian.

❌ Solusi krisis selalu "tambah biaya dari klien" — bahkan untuk masalah yang root cause-nya dari sisi vendor.


PERTANYAAN 10: "Apakah Anda outsource ke pihak ketiga atau tim Anda in-house?"

Apa yang Anda cari

Banyak "software house" sebenarnya adalah broker — mereka jual project, lalu outsource ke freelancer atau tim luar negeri. Tidak otomatis salah, tapi Anda perlu tahu apa yang sebenarnya Anda beli.

Vendor in-house punya keuntungan: kontrol kualitas lebih ketat, komunikasi lebih cepat, ownership lebih jelas. Vendor yang outsource bisa lebih murah, tapi risiko kualitas dan komunikasi lebih tinggi.

Tanda jawaban yang jujur

✅ "Tim kami 100% in-house" — dan mereka bisa tunjukkan kantor, struktur organisasi, dan kenalkan tim secara langsung.

✅ "Kami in-house untuk core development, tapi kadang bring in specialist freelancer untuk niche skill (misalnya animator 3D atau security researcher) — kami transparan kalau itu terjadi."

✅ Mereka jelaskan dengan jujur model bisnis mereka — tidak menyembunyikan struktur tim.

Tanda red flag

❌ Klaim in-house tapi tidak ada kantor fisik yang bisa Anda kunjungi, dan saat video call selalu pakai background blur.

❌ Tim "in-house" tapi ketika Anda minta meeting fisik selalu ada alasan untuk online saja.

❌ Tidak transparan tentang siapa yang sebenarnya akan menulis kode Anda — apakah karyawan tetap, kontraktor, atau outsource ke negara lain.

❌ Ada "tim Bali" atau "tim Yogyakarta" yang sebenarnya adalah subkontraktor lepas yang juga handle 10 project lain dari vendor lain bersamaan.


PERTANYAAN 11: "Bagaimana struktur pembayaran yang Anda usulkan?"

Apa yang Anda cari

Struktur pembayaran yang fair melindungi kedua pihak. Vendor butuh cash flow untuk membayar tim. Klien butuh leverage untuk memastikan delivery sesuai komitmen.

Struktur yang sehat biasanya: 30-50% di awal (untuk start project dan secure resource), pembayaran milestone-based di tengah, 10-20% di akhir setelah final acceptance.

Tanda jawaban yang jujur

✅ Pembayaran tied to deliverable konkret yang bisa diverifikasi — bukan sekadar "30% bulan kedua."

✅ Ada masa garansi 1-3 bulan setelah go-live di mana bug fix gratis.

✅ Klien punya hak menahan pembayaran final kalau ada deliverable yang belum sesuai sign-off.

✅ Invoice dan tax compliance proper (PT yang punya NPWP, faktur pajak benar).

Tanda red flag

❌ Minta 70% atau lebih di awal — vendor seperti ini mengandalkan DP besar untuk bayar tim, dan kehilangan motivasi setelah dapat DP.

❌ Tidak ada milestone — pembayaran berdasarkan tanggal kalender saja, terlepas dari progress.

❌ Tidak ada masa garansi setelah go-live. Bug yang muncul langsung jadi billable hour.

❌ Vendor non-PT atau PT yang tidak bisa kasih invoice resmi. Ini compliance issue dan red flag bisnis.

❌ Pembayaran via rekening pribadi, bukan rekening perusahaan.


PERTANYAAN 12: "Apa yang akan saya regret 1 tahun setelah project selesai?"

Apa yang Anda cari

Pertanyaan ini paling tajam. Anda meminta vendor jujur tentang kelemahan mereka atau pendekatan mereka — dan jawaban yang jujur adalah sinyal kuat tentang karakter vendor.

Vendor yang baik akan kasih jawaban yang spesifik dan reflektif:

  • "Klien kami biasanya regret tidak invest lebih banyak di analytics dari awal — kami akan saran spend ekstra di sana."
  • "Beberapa klien regret bahwa kami terlalu strict dengan scope di awal — fleksibilitas extra mungkin lebih membantu untuk konteks Anda."
  • "Honestly, kalau Anda berkembang sangat cepat dalam 1 tahun, sistem yang kami bangun mungkin perlu refactor di tahun ke-2."

Tanda jawaban yang jujur

✅ Mereka kasih jawaban spesifik tentang trade-off yang mereka buat.

✅ Mereka acknowledge kelemahan pendekatan mereka untuk konteks tertentu.

✅ Mereka kasih saran preventif untuk hal-hal yang sering jadi penyesalan klien.

Tanda red flag

❌ "Tidak ada yang akan Anda regret, klien kami selalu puas." Klise dan tidak bisa dipercaya.

❌ Mereka tidak punya jawaban — artinya mereka tidak pernah refleksi serius tentang feedback klien.

❌ Mereka deflect ke "tergantung klien" — tidak mau ambil tanggung jawab atas hasil.


Bonus: Pertanyaan yang Tidak Perlu Anda Tanyakan

Beberapa pertanyaan sering ditanyakan calon klien tapi sebenarnya tidak banyak nilai informasinya:

"Berapa tahun Anda sudah berdiri?" — Software house 2 tahun dengan tim senior bisa lebih capable dari yang 10 tahun dengan tim turnover tinggi. Umur perusahaan bukan proksi yang baik untuk kualitas.

"Berapa jumlah karyawan Anda?" — Tim 50 orang yang banyak junior bisa lebih lemah dari tim 10 orang yang semuanya senior dengan track record. Yang penting kualitas, bukan kuantitas.

"Apakah Anda pakai teknologi terbaru?" — Teknologi terbaru kadang justru pilihan buruk untuk business application yang butuh stabilitas. Yang penting: teknologi yang tepat untuk konteks Anda, bukan yang paling baru.

"Berapa rate per jam developer Anda?" — Total cost-nya yang penting, bukan rate. Vendor dengan rate Rp 500K/jam bisa lebih murah total dari Rp 200K/jam kalau efisiensi developmentnya jauh lebih tinggi.

"Apakah Anda bisa kasih garansi 100% project akan sukses?" — Tidak ada vendor jujur yang akan kasih garansi seperti ini. Yang penting: bagaimana mereka handle ketika ada masalah.


Cara Praktis Memakai 12 Pertanyaan Ini

Tahap 1 — Long-list (5-10 vendor): dari Google, referensi, atau LinkedIn. Filter cepat berdasarkan portfolio dan industri yang relevan.

Tahap 2 — Short-list (3-5 vendor): ajukan pertanyaan 1, 2, 3, dan 8 via email atau call awal. Vendor yang tidak bisa jawab dengan baik di tahap ini sudah bisa di-eliminasi.

Tahap 3 — Pitch meeting (2-3 vendor): ajukan semua 12 pertanyaan dalam meeting in-person atau video call yang proper. Catat jawabannya. Bandingkan tone, transparansi, dan substansi.

Tahap 4 — Reference check (2 vendor finalis): ajukan pertanyaan ke klien existing mereka. Salah satu vendor yang kelihatan kuat di pitch sering tidak dapat reference yang baik — itu sinyal final.

Tahap 5 — Pilihan akhir: pilih vendor yang paling jujur, bukan yang paling impressive. Vendor yang menunjukkan kelemahan dengan transparan biasanya lebih reliable jangka panjang dari yang menjual mimpi.


Yang Sering Terlupakan: Cek Compliance Bisnis

Selain 12 pertanyaan teknis di atas, jangan lupa basic business compliance:

✓ Apakah mereka PT terdaftar dengan NPWP aktif? ✓ Bisa kasih invoice dengan PPN sesuai aturan? ✓ Punya kontrak template yang proper (bukan asal copy dari internet)? ✓ Punya policy NDA yang bisa Anda review? ✓ Insurance / coverage untuk risiko proyek (cyber liability, professional indemnity)?

Vendor yang serius akan punya semua ini. Vendor yang tidak ada salah satunya adalah vendor yang akan menyusahkan Anda di compliance audit nanti.


Bagaimana Alba Tech Menjawab 12 Pertanyaan Ini

Untuk transparansi, berikut bagaimana kami akan menjawab pertanyaan-pertanyaan ini sendiri:

Project skala mirip: kami sebut spesifik — Allianz Asia Pacific Summit (web app enterprise), Sunshine HRIS (full HRIS dengan mobile companion), MOVES CRM+POS (integrasi ERP existing Melandas), Topsearch corporate website (international audience). Lihat detail di portfolio kami.

Klien referensi: kami kasih kontak langsung 2-3 klien existing — silakan ajukan pertanyaan apapun, termasuk pertanyaan tentang kelemahan kami.

Tim eksekusi: Anda akan ketemu PM, designer lead, dan tech lead di kickoff meeting. Tidak ada "tim akan di-assign nanti."

Discovery: kami dedikasikan 1-3 minggu untuk discovery, output: requirement document, wireframe atau prototype, sprint plan. Sign-off sebelum coding mulai.

Estimasi: kami break down per sprint dengan range, bukan angka tunggal palsu-presisi. Track record kami: 80% project selesai dalam 10% dari estimasi awal.

Perubahan scope: ada change request process tertulis. Perubahan kecil di-absorb. Perubahan besar dievaluasi transparan dengan trade-off jelas.

6 bulan setelah selesai: ada paket maintenance bulanan dengan SLA. Source code Anda akses penuh. Dokumentasi teknis lengkap. Tidak ada lock-in artificial.

Project yang kami tolak: project di bawah Rp 30 juta (overhead kami tidak ekonomis), pure advisory tanpa eksekusi (bukan model kami), klien yang menunjukkan tanda tidak menghargai tim sejak awal.

Krisis project: kami punya war story konkret yang bisa kami share. Pernah server klien down, kami response dalam 30 menit jam 2 pagi karena ada SLA. Pernah developer kunci resign mid-project, kami transparan dan adjust timeline tanpa charge ekstra.

Outsource: 100% in-house, tim 25+ orang di Jakarta. Kantor operasional di Alam Sutera, Tangerang. Anda boleh visit kapan saja.

Pembayaran: umumnya 30% start, milestone-based di tengah, 20% setelah final acceptance dan masa garansi 1 bulan.

Yang akan Anda regret: klien kami sering regret tidak invest lebih banyak di analytics dan reporting dari awal. Kami akan saran allocate budget ekstra di sana sejak discovery.


Penutup

Memilih software house yang tepat tidak butuh kemampuan teknis mendalam. Yang dibutuhkan adalah kesabaran untuk bertanya dengan benar dan ketelitian untuk mendengar jawabannya.

Vendor yang menjawab 12 pertanyaan ini dengan jujur, spesifik, dan transparan — bahkan ketika jawaban itu tidak flattering untuk mereka sendiri — kemungkinan besar akan jadi partner yang baik.

Vendor yang menghindar, generik, atau over-promise di salah satu pertanyaan — keluarkan dari long-list. Tidak peduli seberapa impressive portfolio atau seberapa rendah harga mereka.

Investasi 5-10 jam di evaluasi vendor di awal akan menyelamatkan Anda dari kerugian ratusan juta rupiah dan bulan-bulan momentum bisnis yang hilang nantinya.


Tertarik Diskusi Project?

Kalau Anda sedang dalam proses memilih software house dan mau second opinion — atau mau evaluate apakah Alba Tech cocok untuk project Anda — kami siap diskusi 30 menit gratis.

Kami akan jawab 12 pertanyaan di atas dengan jujur, dan kalau project Anda lebih cocok dengan vendor lain, kami akan bilang langsung.

Hubungi kami via WhatsApp →

Siap membangun produk digital Anda?

Konsultasi gratis. Kami bantu identifikasi solusi yang tepat untuk bisnis Anda.

Hubungi Kami via WhatsApp →