Perbandingan tersebut sering berhenti pada angka yang paling mudah terlihat. Vendor memberikan quotation Rp2 miliar, sementara beberapa engineer in-house terlihat hanya membutuhkan payroll sekitar Rp1–1,5 miliar per tahun. Dari angka tersebut, tim internal tampak lebih murah. Pada kasus lain, recruitment beberapa engineer senior terlihat mahal sehingga proposal vendor langsung dianggap pilihan yang lebih efisien.

Masalahnya, quotation vendor dan salary developer bukan unit biaya yang setara.

Tim in-house membawa recruitment, onboarding, benefit, management, tooling, utilization, training, retention, engineering leadership, dan long-term organizational capacity. Vendor membawa project fee, governance, transition, contract management, dependency, knowledge transfer, dan kemungkinan change cost. Hybrid delivery membawa kombinasi keduanya sekaligus kebutuhan coordination yang lebih besar.

Karena itu, keputusan seharusnya tidak dimulai dari:

“Mana yang paling murah?”

Tetapi:

“Model mana yang memberikan capability, speed, control, dan ownership yang dibutuhkan dengan total economic cost yang paling rasional?”

GAO Cost Estimating and Assessment Guide menekankan bahwa software cost estimation tidak berhenti pada coding effort. Reliable estimate perlu mempertimbangkan scope, technical baseline, work breakdown structure, assumptions, risk, infrastructure, testing, sustainment, serta biaya sepanjang software lifecycle. Guidance tersebut juga relevan untuk development internal maupun software acquisition. Dengan kata lain, membandingkan delivery model hanya menggunakan developer salary atau vendor quotation hampir selalu menghasilkan comparison yang terlalu sempit.

Artikel Ini Bukan Build vs Buy

Sebelum masuk lebih jauh, perlu dibedakan antara delivery model dan solution model.

Pertanyaan Build vs Buy menjawab:

Apakah perusahaan perlu membangun software sendiri atau membeli product/platform yang sudah tersedia?

Crocodic telah membahas konteks tersebut melalui Build vs Buy vs Outsource: Mana yang Aman untuk Enterprise?.

Artikel ini dimulai satu langkah setelah keputusan tersebut. Asumsinya adalah:

Custom development memang diperlukan.

Pertanyaannya kemudian menjadi:

Siapa yang sebaiknya mengembangkan dan mempertahankan capability tersebut?

Pilihan utamanya adalah In-House Delivery, yaitu sebagian besar product dan engineering capability dibangun menjadi internal organization; Vendor Delivery, yaitu engineering dan delivery capability utama diperoleh dari external technology partner; serta Hybrid Delivery, yaitu product ownership dan beberapa strategic capability dipertahankan internal sementara external partner menyediakan engineering expertise atau capacity tambahan.

Dengan query ownership seperti ini, fokusnya bukan software versus SaaS, tetapi economics dari software delivery capability.

Harga Software Sebenarnya adalah Harga untuk Mendapatkan Capability

Saat perusahaan membayar Rp2 miliar kepada vendor, yang dibeli bukan hanya sejumlah baris code. Perusahaan sebenarnya membayar temporary delivery capability yang dapat terdiri dari business analyst, system analyst, product atau project management, UX, software engineering, QA, DevOps, architecture, security, dan engineering leadership.

Hal yang sama berlaku ketika membentuk tim internal. Payroll engineer hanyalah sebagian dari biaya untuk menciptakan capability tersebut. Perusahaan masih harus menemukan kandidat, melakukan interview, menunggu notice period, onboarding, membentuk engineering practice, menyediakan management, menentukan architecture, membuat QA discipline, menyediakan development infrastructure, dan mempertahankan team setelah project selesai.

Karena itu, perbandingan yang lebih tepat adalah:

Cost of Vendor Capability vs Cost of Internal Capability vs Cost of Hybrid Capability

bukan:

Quotation vs Salary

Crocodic Software Delivery Economics Framework

Dalam working framework Crocodic, pemilihan delivery model dapat dianalisis melalui chain:

Required Business Capability → Delivery Urgency → Skill Requirement → Internal Capability → Demand Duration → Utilization → Governance Requirement → Knowledge Ownership → Lifecycle Responsibility → Total Delivery Cost → Vendor / In-House / Hybrid

Framework dimulai dari Required Business Capability. Software apa yang perlu diwujudkan dan seberapa strategic capability tersebut terhadap perusahaan?

Kemudian lihat Delivery Urgency. Apakah perusahaan mempunyai waktu satu tahun membangun team atau capability perlu tersedia dalam beberapa bulan?

Setelah itu tentukan Skill Requirement. Apakah project hanya membutuhkan standard web development atau membutuhkan enterprise architecture, integration, data engineering, security, DevOps, AI, atau domain-specific knowledge?

Barulah kondisi Internal Capability dievaluasi. Berikutnya adalah Demand Duration dan Utilization. Apakah skill tersebut dibutuhkan terus-menerus selama bertahun-tahun atau hanya intens pada fase tertentu?

Setelah itu perusahaan perlu menentukan Governance Requirement, Knowledge Ownership, dan siapa yang memegang Lifecycle Responsibility setelah go-live.

Output akhirnya bukan angka biaya tunggal.

Output-nya adalah keputusan tentang delivery operating model.

In-House Development: Anda Tidak Hanya Merekrut Developer

Model in-house paling menarik ketika software merupakan long-term strategic capability dan perusahaan memang membutuhkan engineering capacity secara berkelanjutan.

Keuntungan terbesar in-house biasanya bukan “developer lebih murah”. Keuntungannya adalah capability menjadi bagian dari organisasi. Engineer memahami business domain dalam jangka panjang. Knowledge berkembang di dalam perusahaan. Prioritas dapat berubah tanpa harus selalu mengubah kontrak. Product dan engineering team dapat bekerja lebih dekat dengan operation.

McKinsey dalam riset mengenai effective product teams menekankan bahwa effective product team tidak hanya bergantung pada keberadaan developer, tetapi pada kombinasi strategy, structure, people, process, dan technology.

Inilah bagian yang sering hilang dari calculation.

Merekrut lima developer tidak otomatis berarti perusahaan mempunyai software delivery team.

Hidden Cost In-House: Recruitment, Management, dan Utilization

Sebuah delivery team dapat membutuhkan Product Manager, System Analyst, Tech Lead, Software Engineer, QA Engineer, DevOps, bahkan specialist lain tergantung complexity project. Secara spreadsheet, salary dapat dihitung dengan mudah. Namun pertanyaan berikutnya adalah: berapa lama sampai seluruh capability tersebut benar-benar tersedia dan dapat bekerja sebagai satu team?

Recruitment membutuhkan sourcing, screening, technical interview, negotiation, notice period, onboarding, dan adaptation terhadap domain bisnis. Jika satu role kritis belum tersedia—misalnya Tech Lead—role lain belum tentu dapat bekerja dengan productivity optimal.

Selain itu, software engineers tidak berjalan sebagai autonomous collection of individuals. Seseorang perlu mengelola architecture, technical standard, prioritization, quality, release, security, infrastructure, incident handling, dan engineering practice.

NIST Secure Software Development Framework juga menunjukkan bahwa secure software development membutuhkan role dan responsibility sepanjang software-development lifecycle, bukan hanya programmer.

Kemudian terdapat utilization problem. In-house team merupakan fixed capacity. Project mungkin membutuhkan delapan orang selama satu tahun, tetapi setelah go-live hanya membutuhkan tiga atau empat orang untuk maintenance dan enhancement.

Karena itu:

Annual Internal Team Cost ÷ Productive Utilization = Effective Delivery Cost

Formula tersebut bukan accounting standard, tetapi membantu memperlihatkan mengapa payroll murah belum tentu berarti delivery murah.

Vendor Delivery: Membeli Speed dan Aggregated Capability

Technology partner yang sudah mempunyai delivery organization tidak perlu membentuk seluruh capability dari nol setiap kali project dimulai. Engineering team, QA process, delivery management, architecture capability, dan specialist skills dapat sudah tersedia.

Karena itu, vendor sering mempunyai advantage pada Time-to-Capability.

Perusahaan tidak perlu merekrut seluruh role terlebih dahulu sebelum project mulai. Specialist seperti DevOps, security, data engineer, atau enterprise architect juga dapat dialokasikan hanya pada fase ketika diperlukan.

Namun harga vendor memuat cost yang tidak terlihat dalam salary comparison: delivery management, architecture, QA, engineering leadership, tooling, utilization risk, recruitment, retention, dan organizational overhead.

Karena itu:

Low Quotation ≠ Low Total Delivery Cost

dan sebaliknya:

Vendor Fee yang lebih tinggi daripada payroll ≠ otomatis lebih mahal secara ekonomi.

Hybrid Delivery: Memisahkan Strategic Ownership dari Variable Capacity

Hybrid delivery sering relevan ketika perusahaan ingin mempertahankan control tetapi tidak ingin membangun seluruh engineering organization sendiri.

Internal organization dapat mempertahankan Product Ownership, Business Process Ownership, Enterprise Architecture, Data Ownership, atau Security Governance, sementara vendor menyediakan Software Engineering, QA, DevOps, Integration Engineering, atau specialist skills.

Model ini memungkinkan perusahaan mempertahankan strategic context di internal sekaligus memperoleh variable engineering capacity.

Namun hybrid juga membawa coordination tax. Boundary responsibility perlu jelas:

Who Owns Business Outcome?

Who Owns Product Decision?

Who Owns Architecture?

Who Owns Code Quality?

Who Owns Security?

Who Owns Production?

Who Owns Knowledge after Contract Ends?

Hybrid yang matang mempunyai shared delivery, clear accountability.

Hybrid yang buruk mempunyai shared accountability, unclear ownership.

Gunakan Total Delivery Cost, Bukan Salary vs Quotation

Untuk membuat comparison lebih rasional, Crocodic menggunakan working framework:

Total Delivery Cost = Direct Delivery Cost + Capability Acquisition Cost + Management Cost + Tooling & Infrastructure + Utilization Cost + Governance Cost + Transition Cost + Lifecycle Cost

Untuk In-House, komponen dapat berupa salary, benefits, recruitment, onboarding, management, tooling, utilization, retention, support, dan maintenance.

Untuk Vendor, komponen dapat berupa project fee, internal governance, scope/change cost, transition, knowledge transfer, dependency management, dan maintenance.

Untuk Hybrid, perusahaan perlu menghitung internal core team, external engineering capacity, coordination, governance, shared tooling, knowledge transfer, dan lifecycle ownership.

Framework ini membuat management membandingkan ketiga model pada basis yang lebih setara.

Contoh Perhitungan Biaya Nyata: Project Software Enterprise 12 Bulan

Agar comparison tidak berhenti pada konsep, berikut contoh realistis untuk perusahaan Indonesia yang membutuhkan custom operational system dengan target delivery sekitar satu tahun.

Sebagai market anchor, Indeed Indonesia per 19 Oktober 2026 mencatat rata-rata gaji pokok Software Engineer sekitar Rp11,1 juta per bulan, sementara Senior Software Engineer berada sekitar Rp21,6 juta per bulan. Sementara itu, Jobstreet Indonesia memberikan gambaran 2026 bahwa Software Developer/Mobile Developer level junior–menengah berada sekitar Rp9–15 juta, sedangkan Cloud & DevOps Engineer sekitar Rp12–18 juta per bulan. Angka tersebut sangat bergantung pada lokasi, seniority, industri, dan employer, sehingga simulasi di bawah menggunakan angka pembulatan untuk budgeting—bukan salary standard.

Skenario Project

Perusahaan membutuhkan:

• 1 Product Manager
• 1 Tech Lead / Solution Architect
• 3 Software Engineers
• 1 QA Engineer
• 1 DevOps Engineer

Untuk memudahkan comparison, business scope dianggap sama pada ketiga delivery model.

Model A — Full In-House

Asumsi monthly compensation:

Total payroll selama 12 bulan:

Rp104 juta × 12 = Rp1,248 miliar

Tetapi payroll belum merupakan Total Delivery Cost.

Tambahkan planning assumption:

Angka Rp1,847 miliar tetap belum memasukkan kemungkinan turnover, replacement cost, office overhead, ataupun additional specialist seperti security engineer dan business analyst. Sebaliknya, jika perusahaan sudah memiliki equipment, HR function, tooling, atau beberapa role existing, actual incremental cost dapat lebih rendah.

Inilah alasan angka ini harus dibaca sebagai economic model, bukan salary calculator.

Model B — Full Vendor Delivery

Sekarang asumsikan perusahaan mendapatkan quotation fixed project delivery sebesar:

Rp1,8 miliar untuk 12 bulan

Fee tersebut dalam simulasi sudah mencakup project management, engineering, QA, DevOps, development tools, delivery management, dan specialist access sesuai kebutuhan.

Perusahaan tetap membutuhkan internal governance.

Jika hanya membandingkan direct cost:

In-House: Rp1,847 miliar

Vendor: Rp2,060 miliar

Vendor terlihat sekitar Rp213 juta lebih mahal.

Jika analisis berhenti di sini, kesimpulannya sederhana: hire internal.

Tetapi ada variable berikutnya yang dapat mengubah keputusan: waktu.

Model C — Hybrid Delivery

Untuk hybrid, misalnya perusahaan mempertahankan dua strategic roles di internal:

• Product Manager
• Tech Lead / Architecture Owner

Sementara external partner menyediakan tiga Software Engineers, QA, DevOps, dan delivery support.

Internal cost:

Product Manager Rp18 juta + Tech Lead Rp25 juta = Rp43 juta/bulan

Annual salary:

Rp43 juta × 12 = Rp516 juta

Tambahkan THR/annual compensation sekitar Rp43 juta.

External engineering pod diasumsikan:

Rp110 juta/bulan × 12 = Rp1,320 miliar

Kemudian:

Comparison langsungnya menjadi:

Jika hanya melihat cash delivery cost, in-house menang dalam contoh ini.

Namun management belum selesai menghitung.

Tambahkan Cost of Delay: Hasilnya Bisa Berubah

Sekarang anggap software tersebut ditujukan untuk memperbaiki operational process yang saat ini menciptakan measurable leakage sekitar:

Rp150 juta per bulan

Leakage dapat berasal dari additional manual cost, revenue leakage, delayed billing, excessive reconciliation, atau capacity constraint yang sudah mempunyai baseline.

Kemudian estimasi Time-to-Go-Live berbeda:

Vendor: capability sudah tersedia, target go-live bulan ke-8.

Hybrid: internal owner perlu disiapkan dan external team diintegrasikan, go-live bulan ke-9.

In-House: recruitment dan team formation membutuhkan sekitar tiga bulan sebelum full delivery capacity tersedia, sehingga go-live bulan ke-11.

Perhitungan Cost of Delay:

Vendor

8 bulan × Rp150 juta = Rp1,2 miliar

Total economic exposure:

Rp2,060 miliar + Rp1,2 miliar = Rp3,260 miliar

Hybrid

9 bulan × Rp150 juta = Rp1,350 miliar

Total economic exposure:

Rp2,009 miliar + Rp1,350 miliar = Rp3,359 miliar

In-House

11 bulan × Rp150 juta = Rp1,650 miliar

Total economic exposure:

Rp1,847 miliar + Rp1,650 miliar = Rp3,497 miliar

Hasilnya berubah:

Angka tersebut adalah simulasi, bukan benchmark Crocodic atau standar harga vendor di Indonesia. Namun ia memperlihatkan satu hal penting:

Pilihan dengan direct cost paling murah belum tentu mempunyai economic cost paling rendah.

Pada contoh ini, in-house menghemat sekitar Rp213 juta terhadap vendor pada delivery cost, tetapi go-live yang diasumsikan tiga bulan lebih lambat menghasilkan tambahan Cost of Delay Rp450 juta. Akibatnya, secara economic exposure vendor justru terlihat lebih favorable.

Sebaliknya, jika software tidak urgent dan Value at Stake hanya Rp10 juta per bulan, hasilnya dapat berubah lagi. In-house mungkin menjadi pilihan yang lebih ekonomis, terutama jika team tersebut akan terus digunakan untuk roadmap tiga sampai lima tahun.

Inilah alasan keputusan tidak dapat dibuat hanya dari rate card.

Tambahkan Horizon Tiga Tahun, dan Hasilnya Dapat Berubah Lagi

Contoh sebelumnya hanya melihat first-year delivery.

Namun jika perusahaan mempunyai continuous roadmap tiga tahun, in-house team yang sudah terbentuk dapat terus menghasilkan capability baru tanpa perlu melakukan procurement project besar untuk setiap enhancement.

Pada kondisi tersebut, Year-1 recruitment cost dan team-formation delay menjadi upfront investment untuk membangun permanent capability.

Sebaliknya, jika setelah go-live hanya terdapat minor maintenance selama tiga tahun, fixed internal team berukuran tujuh orang dapat menjadi terlalu besar.

Karena itu, delivery model harus memperhitungkan Demand Duration.

Secara sederhana:

High Persistent Demand → In-House economics semakin menarik

High Temporary Demand → Vendor economics semakin menarik

Persistent Strategic Ownership + Variable Engineering Demand → Hybrid semakin menarik

Dengan kata lain, keputusan bukan hanya tentang project yang sedang dibangun.

Ia juga tentang apa yang terjadi pada engineering capacity setelah project selesai.

Time-to-Capability Bisa Lebih Penting daripada Annual Cost

Contoh tadi menunjukkan mengapa Time-to-Capability sebaiknya masuk ke financial discussion.

Satu model dapat mempunyai annual delivery cost lebih rendah tetapi business value lebih buruk jika company membutuhkan waktu terlalu lama untuk membentuk capability.

Karena itu, management sebaiknya menghitung dua angka:

Cost to Acquire Capability

dan

Cost of Waiting for Capability

Keduanya membentuk economic decision yang lebih lengkap.

Ini juga mencegah perusahaan mengambil keputusan yang terlihat murah pada procurement tetapi mahal dari perspective business impact.

In-House Lebih Menarik ketika Demand Bersifat Persistent

Internal engineering capability semakin ekonomis ketika demand terhadap capability tersebut bersifat terus-menerus.

Misalnya perusahaan menjalankan digital platform yang menjadi core revenue engine. Product harus terus berkembang. Banyak experiment perlu dilakukan. Customer behavior berubah cepat. Technology merupakan strategic differentiator.

Pada kondisi tersebut, engineering bukan lagi project.

Ia menjadi operating capability.

McKinsey menunjukkan bahwa effective product team membutuhkan alignment yang kuat antara strategy, structure, people, process, dan technology.

Karena itu, pertanyaan penting adalah:

“Apakah kita membutuhkan project atau permanent product capability?”

Vendor Lebih Menarik ketika Capability Need Bersifat Burst

Vendor dapat lebih ekonomis ketika skill requirement tinggi tetapi demand-nya tidak berlangsung terus-menerus.

Contohnya legacy modernization, ERP integration, cloud migration, AI implementation, large system rebuild, security remediation, atau major digital-transformation project.

Perusahaan mungkin membutuhkan banyak engineer selama satu tahun, lalu setelah go-live hanya membutuhkan small maintenance team.

Membangun large internal team untuk kebutuhan sementara dapat menciptakan utilization problem setelah project selesai.

Vendor mengubah sebagian fixed organizational capacity menjadi:

Variable Delivery Capacity

Dalam kondisi tersebut, premium yang dibayar kepada vendor dapat menjadi harga untuk mendapatkan flexibility.

Hybrid Lebih Menarik ketika Ownership Harus Internal tetapi Capacity Perlu Fleksibel

Banyak enterprise berada di tengah.

Software terlalu strategic untuk diserahkan sepenuhnya. Tetapi engineering demand terlalu variable untuk seluruhnya dipenuhi internal.

Internal team dapat menjaga Business Context, Product Roadmap, Architecture Principle, Data Ownership, Security Policy, dan Long-Term Technology Direction. External team kemudian menyediakan variable engineering capacity.

Saat project besar, capacity dapat ditambah. Saat intensity turun, capacity dapat diperkecil tanpa perusahaan membawa fixed payroll yang sama.

Di sini vendor bukan pengganti internal technology organization.

Vendor berfungsi sebagai capacity multiplier.

Knowledge Ownership Harus Dipisahkan dari Employment Ownership

Salah satu argument paling umum untuk in-house adalah:

“Kalau pakai vendor, knowledge akan berada di vendor.”

Risiko tersebut nyata.

Tetapi solution-nya bukan otomatis menghindari vendor.

Perusahaan perlu menentukan knowledge architecture.

Siapa memiliki source code? Siapa mempunyai repository access? Apakah architecture decision terdokumentasi? Apakah API documentation tersedia? Apakah deployment dapat dijalankan internal? Apakah database schema dan integration map terdokumentasi? Apakah security configuration diketahui perusahaan?

Code yang dimiliki perusahaan tetapi tidak dapat dipahami internal tetap menghasilkan dependency.

Sebaliknya, vendor-developed software dengan strong documentation, shared repository, architecture governance, dan continuous knowledge transfer dapat mempunyai portability lebih baik.

Karena itu:

Knowledge Ownership ≠ Who Writes the Code

Lebih tepat:

Knowledge Ownership = Access + Documentation + Understanding + Operational Capability

Siapa Bertanggung Jawab setelah Go-Live?

Delivery-model decision tidak boleh berhenti pada go-live.

Vendor selesai project. Internal project team berubah. Key engineers dapat pindah. Tetapi application tetap digunakan.

Siapa menangani bug?

Siapa memperbarui dependency?

Siapa melakukan security patch?

Siapa memonitor production?

Siapa mengubah system ketika business process berubah?

Siapa menangani incident?

GAO Cost Estimating and Assessment Guide memasukkan sustainment dan lifecycle cost dalam software estimation. Karena itu, delivery economics perlu diperpanjang menjadi:

Build → Run → Maintain → Secure → Change → Modernize

Artikel Crocodic Biaya Maintenance Aplikasi Perusahaan: Apa yang Terjadi Setelah Go-Live? dapat menjadi continuation natural untuk menghitung layer tersebut ketika URL final artikel sudah diterbitkan.

Decision Matrix: Vendor, In-House, atau Hybrid?

Tabel ini bukan scoring model universal. Hasilnya bergantung pada urgency, roadmap, skill market, maturity internal, criticality, dan lifecycle plan.

Crocodic Delivery Model Assessment

Sebelum memilih vendor, melakukan mass hiring, atau membentuk hybrid team, enterprise dapat melakukan Software Delivery Model Assessment.

Assessment dimulai dari:

Business Capability → Roadmap → Delivery Urgency → Required Skills → Existing Internal Capability → Demand Duration → Utilization → Governance → Lifecycle → Total Delivery Economics

Assessment menilai:

Capability Requirement — role dan skill apa yang benar-benar dibutuhkan.

Delivery Urgency — kapan capability harus tersedia.

Demand Profile — apakah demand continuous, temporary, atau fluctuating.

Internal Readiness — apakah Product Owner, architecture, engineering management, QA, security, dan operation sudah tersedia.

Utilization Economics — apakah team internal masih akan mempunyai cukup pekerjaan setelah major project selesai.

Governance & Ownership — capability apa yang harus berada di internal.

Lifecycle Responsibility — siapa yang akan run, maintain, secure, dan change system setelah go-live.

Output-nya berupa:

Required Capability → Internal Gap → Time-to-Capability → Cost Structure → Cost of Delay → Ownership Requirement → Recommended Delivery Model

dengan kemungkinan keputusan:

In-House → Vendor → Hybrid

atau model berbeda untuk workstream berbeda.

Jika perusahaan sudah mengetahui software perlu dibangun tetapi belum yakin apakah lebih ekonomis merekrut developer sendiri, menggunakan vendor, atau menggabungkan keduanya, diskusikan Software Delivery Model Assessment dengan Crocodic.

Tujuannya bukan memilih model dengan harga awal terendah.

Tujuannya adalah menentukan delivery model yang menghasilkan business capability pada waktu yang dibutuhkan tanpa menciptakan cost structure dan dependency yang tidak sehat setelah go-live.

Crocodic Perspective: Jangan Membeli Mandays, Bangun Delivery Capability yang Tepat

Dalam perspective Crocodic, diskusi mengenai vendor versus internal sering terlalu cepat turun menjadi perbandingan rate.

Developer internal RpX per bulan.

Vendor RpY per manday.

Perbandingan tersebut kehilangan pertanyaan yang lebih penting:

Capability apa yang dibutuhkan untuk menghasilkan business outcome?

Working framework Crocodic:

Business Outcome → Required Capability → Delivery Capability → Capacity Model → Ownership Model → Time-to-Value → Lifecycle Responsibility → Total Economic Cost

Karena itu:

In-house bukan otomatis murah.

Vendor bukan otomatis mahal.

Hybrid bukan otomatis best of both worlds.

Model terbaik adalah model yang menghasilkan right capability, at the right time, with the right ownership and sustainable lifecycle cost.

Kesimpulan

Pertanyaan “vendor atau in-house?” terdengar seperti keputusan procurement.

Sebenarnya ia adalah keputusan operating model.

In-house membuat perusahaan memiliki engineering capacity secara permanen. Vendor memungkinkan perusahaan mengakses established capability tanpa membangun seluruh organization dari nol. Hybrid memungkinkan strategic ownership tetap internal sementara delivery capacity dapat berubah mengikuti kebutuhan.

Karena itu, biaya membuat software sebaiknya tidak dibandingkan melalui:

Vendor Quotation vs Developer Salary

Gunakan perspective yang lebih lengkap:

Direct Delivery Cost + Capability Acquisition + Management + Tooling + Utilization + Governance + Transition + Lifecycle Cost + Cost of Delay

Contoh perhitungan menunjukkan bagaimana in-house dapat memiliki direct cost paling rendah, tetapi kehilangan keunggulan tersebut ketika recruitment delay dan business value yang terus bocor selama menunggu ikut dihitung.

Pada kondisi lain, terutama ketika perusahaan mempunyai continuous product roadmap selama beberapa tahun, internal engineering team justru dapat menghasilkan economics yang jauh lebih kuat.

Itulah sebabnya tidak ada delivery model yang secara universal paling murah.

Pertanyaan akhirnya adalah:

“Berapa total biaya untuk memperoleh, mengelola, dan mempertahankan delivery capability ini—dan berapa business value yang hilang selama kita menunggu capability tersebut tersedia?”

Jawaban terhadap dua pertanyaan tersebut yang seharusnya menentukan apakah perusahaan membutuhkan vendor, in-house team, atau hybrid delivery.