Mengapa Kami Berhenti Menagih Berdasarkan Jam untuk Pengembangan Perangkat Lunak

Jawaban cepat

• Biaya produksi listrik menjadi murah. Namun, biaya kepemilikan tidak.
• Penagihan per jam sekarang menetapkan harga untuk bagian pekerjaan yang paling cepat.
• Biaya tersebut masih dalam tahap peninjauan, pengujian, dan tahun-tahun berikutnya.
• Janji dukungan tanpa pendanaan bukanlah sebuah janji.
• Sekarang kami menetapkan harga berdasarkan tanggung jawab, bukan waktu.

Pada tanggal 3 September, OpenAI merilis GPT-6 Astra. Peluncurannya masih bertahap saat saya menulis ini, jadi sebagian besar orang belum menggunakannya. Kira-kira seperti itulah ritmenya sekarang. Setiap beberapa bulan, batasannya berubah, dan hal yang sulit di bulan Maret menjadi hal biasa di bulan September.

Aku sudah berhenti merasa heran akan hal ini. Yang terus kupikirkan adalah pertanyaan yang lebih kecil, yang semakin sulit setiap kali langit-langit bergeser.

Jika mesin tersebut dapat melakukan lebih banyak pekerjaan pembangunan, lalu untuk apa sebenarnya saya mengenakan biaya?

Mengapa satu jam berhenti mengukur apa pun?

Beberapa bulan lalu saya mengerjakan sebuah tugas yang memakan waktu sekitar satu jam, sambil memikirkan apa yang harus dicantumkan pada faktur.

Satu jam adalah angka yang akurat. Namun, angka itu hampir tidak berarti. Satu jam itu mencakup bagian tercepat, termurah, dan paling tidak berisiko dari apa yang telah kita sepakati. Semua hal yang penting berada di sisi lain: membaca output dengan benar, menguji jalur yang tidak diminta siapa pun, menerapkannya dengan aman, dan tetap dapat dihubungi selama tiga tahun ke depan ketika ada perubahan di dalamnya.

Penagihan per jam berarti mengenakan biaya paling tinggi untuk bagian yang hampir gratis, dan paling rendah untuk bagian yang menanggung semua risiko. Itu juga berarti kami diberi penghargaan karena lambat. Saya tidak bisa membela hal itu kepada klien, dan saya tidak bisa membela hal itu kepada diri saya sendiri.

Mengapa akuntabilitas menjadi hal yang diberi harga?

Kami telah menulis panjang lebar tentang apa yang terjadi setelah aplikasi yang dikembangkan dengan metode Vibe mencapai pengguna sebenarnya , termasuk insiden yang terdokumentasi di mana bagian yang hilang bukanlah alatnya, tetapi orang yang bertanggung jawab atas apa yang telah dirilis. Saya tidak akan mengulangi argumen itu di sini.

Yang tidak dijawab oleh tulisan itu adalah pertanyaan komersial yang mendasarinya. Jika akuntabilitas adalah hal yang langka, maka hal itu harus tercantum di suatu tempat dalam faktur. Jika tidak, itu hanyalah janji yang tidak didanai siapa pun, dan janji yang tidak didanai cenderung melemah secara diam-diam tepat pada saat dibutuhkan.

Tarif per jam tidak dapat menjamin hal itu. Tarif tersebut mencatat berapa lama seseorang menangani suatu masalah, yang pada tahun 2026 tidak banyak menjelaskan seberapa besar risiko yang mereka tanggung atas nama Anda.

Apa sebenarnya yang dibeli klien saat ini?

Kemampuan telah terdistribusi. Setiap perusahaan di Bangalore, Calicut, dan Chicago sekarang menggunakan alat yang kurang lebih sama. Tidak ada yang akan memenangkan tender pada tahun 2026 dengan mengklaim sebagai insinyur yang lebih cepat.

Yang tidak tersampaikan adalah janji. Seseorang harus mengatakan: ini milik kami, kami akan terus menjalankannya, dan inilah yang akan melanjutkannya. Itu bukan klaim teknis. Itu adalah komitmen, dan komitmen membutuhkan biaya dengan cara yang tidak lagi dibutuhkan oleh ketukan keyboard.

Saya juga memperhatikan adanya perbedaan dalam percakapan. Beberapa orang yang saya ajak bicara sangat senang dengan betapa cepatnya segala sesuatu menjadi lebih baik. Yang lain, biasanya mereka yang telah menjalankan perangkat lunak selama beberapa tahun, mengajukan pertanyaan yang lebih tenang. Siapa yang meninjau ini? Apa yang terjadi jika terjadi kerusakan? Siapa yang tersisa ketika orang yang mengusulkannya pindah?

Kedua reaksi tersebut masuk akal. Perbedaannya hanya terletak pada rentang waktu yang digunakan.

Apa sebenarnya yang kita ubah?

Kami beralih dari penagihan berdasarkan jam kerja ke penetapan harga berdasarkan tugas dan tanggung jawab yang melekat padanya.

Perubahan itu tidak nyaman. Menjelaskan bahwa tugas satu jam memiliki harga yang tidak terkait dengan jam tersebut membutuhkan percakapan yang lebih panjang daripada mengirimkan faktur. Beberapa percakapan tersebut berjalan buruk sebelum akhirnya berjalan baik. Beberapa klien menginginkan model lama dan saya mengerti alasannya.

Yang membuat hal itu bisa dibenarkan adalah spesifikasinya mengenai apa yang tercakup dalam harga tersebut. Bukan upaya yang dilakukan. Melainkan cakupan. Siapa yang meninjau kode sebelum digabungkan, siapa yang ditunjuk dalam proyek, apa yang terjadi pada Sabtu malam, berapa lama kita tetap bertanggung jawab setelah pengiriman.

Tidak yakin berapa biaya perangkat lunak Anda setelah tahun pertama?

Kirimkan saya repositori dan tanggal peluncurannya. Saya akan memberi tahu Anda apa yang menurut saya dibutuhkan, dan apakah kami orang yang tepat untuk mengerjakannya. Jika tidak, saya akan mengatakannya.

Bagaimana cara menentukan harga sesuatu yang tidak dapat dijadwalkan?

Inilah kesulitan praktisnya, dan inilah mengapa penetapan harga per jam juga gagal dari sisi dukungan pelanggan.

Pekerjaan yang menjaga kelangsungan perangkat lunak tidak datang sesuai kalender. Pekerjaan itu datang ketika sebuah platform memutuskan, ketika regulator memutuskan, atau ketika seseorang menemukan kerentanan dalam pustaka yang Anda adopsi dua tahun lalu. Anda tidak dapat memperkirakannya sebelumnya karena tidak ada satu pun dari hal itu yang dapat Anda jadwalkan.

Berikut daftar singkat hal-hal yang tidak pernah direncanakan siapa pun:

• Pergeseran dependensi dan SDK, termasuk penghentian fitur yang tidak dipilih siapa pun.
• Perubahan persyaratan platform dari Google Play Console dan App Store.
• Pergerakan regulasi, yang di India berarti aturan tokenisasi RBI dan Undang-Undang DPDP yang akan datang dengan tenggat waktu yang telah ditetapkan.
• Tinjauan keamanan terhadap kode yang dihasilkan secara khusus, karena model dioptimalkan untuk bekerja daripada untuk memvalidasi input.
• Penalaran tertulis, sehingga insinyur berikutnya mewarisi konteks alih-alih arkeologi.
• Seseorang yang namanya disebutkan yang mengangkat

Anda tidak dapat menetapkan harga berdasarkan jam kerja untuk daftar tersebut. Yang dapat Anda tetapkan harganya adalah cakupan: komitmen bahwa ketika salah satu dari kejadian itu terjadi, seseorang sudah bertanggung jawab dan sudah dibayar untuk menanganinya.

Model penetapan harga mana yang paling tepat saat ini?

Saya sering ditanya hal ini oleh para pendiri yang bukan hanya mencoba menghemat uang, tetapi juga mencoba memahami apa yang mereka beli. Pertanyaan ini layak mendapatkan jawaban yang lugas, termasuk di mana model bisnis kami kurang cocok.

Pilih Model	Di mana itu masih berfungsi	Di mana hal itu akan terjadi pada tahun 2026
Perjam	Tahap penemuan, pekerjaan konsultasi, ruang lingkup yang masih belum jelas.	Segala sesuatu yang dibantu AI. Kecepatan mengurangi tagihan sementara risiko tetap konstan.
Harga tetap per proyek	Lingkup terbatas, pengiriman sekali saja, tidak ada perubahan yang diharapkan.	Kepemilikan berakhir pada saat serah terima, jadi tidak ada yang mendanai bulan keempat belas.
Tugas ditambah periode kepemilikan yang dinyatakan	Hasil yang terdefinisi dengan jelas di mana seseorang tetap bertanggung jawab setelahnya.	Membutuhkan percakapan jujur ​​mengenai ruang lingkup pekerjaan yang mungkin tidak diinginkan klien pada hari pertama.
Biaya jasa berkelanjutan	Sistem yang sedang berjalan, sektor yang diatur, apa pun yang terintegrasi dengan perangkat lunak lain.	Terlihat mahal sampai minggu berikutnya ternyata tidak mahal.

Kami menggunakan opsi ketiga dan keempat. Bukan karena opsi-opsi itu cerdas, tetapi karena hanya dua opsi itulah yang memiliki tujuan yang sama, yaitu insentif kami dan insentif klien. Dengan sistem pembayaran per jam, kami menghasilkan lebih banyak dengan bekerja lebih lambat. Dengan sistem harga tetap, kami menghasilkan lebih banyak dengan menghilang saat serah terima. Keduanya bukanlah hubungan yang ingin saya jalani selama tiga tahun.

Jebakan harga tetap perlu disebutkan, karena ini adalah jebakan yang paling sering menjebak pembeli. Harga tetap terasa aman. Harga tersebut membatasi angka yang tertera di halaman. Namun, yang biasanya tidak disebutkan adalah apa yang terjadi di bulan kedelapan, yang berarti jawabannya baru datang kemudian sebagai negosiasi terpisah, pada saat Anda tidak memiliki daya tawar dan sistem yang rusak.

Kesalahan yang kami lakukan di tahun pertama

Saya lebih memilih menuliskannya daripada membiarkan seseorang mengetahuinya dalam rapat.

Versi pertama penetapan harga kami terlalu samar. Kami menetapkan harga untuk tugas tersebut dan mengatakan dukungan sudah termasuk, tanpa menyatakan berapa lama atau apa yang termasuk dalam "termasuk" tersebut. Itu bukanlah model yang tepat. Itu hanyalah harapan, dan harapan itu runtuh saat pertama kali saya dan klien berbeda pendapat tentang apakah sesuatu dianggap sebagai perbaikan atau fitur baru. Kami berdua benar, karena tidak ada yang tertulis dalam dokumen tersebut.

Kesalahan kedua adalah menjelaskan perubahan tersebut dengan buruk. Saya mengedepankan alasan internal kami daripada apa yang sebenarnya diterima klien. Tidak ada yang percaya pada logika internal Anda. Mereka membeli komitmen respons yang terdefinisi, seorang insinyur yang ditunjuk, dan batasan yang jelas mengenai apa yang dicakup.

Yang ketiga adalah meremehkan betapa tidak nyamannya percakapan itu. Beberapa klien mendengar "kami mengenakan biaya lebih untuk pekerjaan yang lebih sedikit," yang merupakan interpretasi yang wajar dari faktur yang dijelaskan dengan buruk. Itu kesalahan saya, bukan kesalahan mereka.

Yang menyelesaikan masalah adalah menuliskan batasan-batasannya. Pekerjaan mana yang tercakup, pekerjaan mana yang dikutip secara terpisah, berapa lama kami bertanggung jawab, dan siapa yang harus dihubungi. Setelah itu tertulis di atas kertas, sebagian besar keberatan berhenti, karena argumennya sebenarnya bukan tentang harga.

Mengapa kami berhenti mengejar pengembangan aplikasi?

Inilah hasil pemikiran saya, meskipun butuh waktu lebih lama untuk sampai ke sini daripada waktu yang dibutuhkan untuk menulisnya.

Jika siapa pun dapat membuat aplikasi, maka membangun aplikasi bukanlah bisnis yang layak dipertahankan. Yang layak dipertahankan adalah perangkat lunak yang benar-benar dijalankan oleh perusahaan. Sistem yang saling terhubung, mentransfer data antar departemen, lolos audit, dan terus berfungsi selama bertahun-tahun bahkan ketika tidak ada yang mengawasinya.

Hal itu mengubah cara kita berpikir tentang pekerjaan kita sendiri. Bukan lagi tentang meluncurkan aplikasi lain, tetapi lebih tentang perangkat lunak sebagai bagian dari cara bisnis beroperasi : alur kerja, integrasi, dasbor, infrastruktur operasional yang tidak glamor namun menanggung beban berat.

Secara internal, kami mendeskripsikan arah ini sebagai ekosistem perangkat lunak operasional berbasis AI untuk pasar negara berkembang. Frasa itu muncul setelah keputusan diambil, bukan sebelumnya. Yang pertama muncul adalah menyadari bahwa pekerjaan kami yang paling berharga bukanlah kode yang kami tulis paling cepat.

Apa yang sebaiknya Anda tanyakan kepada mitra pengembangan?

Terlepas apakah Anda bekerja dengan kami atau tidak, pertanyaan-pertanyaan ini layak diajukan kepada siapa pun tahun ini.

1. Seberapa banyak dari ini yang akan dihasilkan oleh AI, dan siapa yang meninjaunya sebelum digabungkan?
2. Bisakah tim Anda menjelaskan hasilnya tanpa membuka alat tersebut?
3. Siapakah pemilik teknis resmi proyek saya?
4. Siapa yang merespons jika terjadi kerusakan di luar jam kerja, dan seberapa cepat?
5. Di mana repositori tersebut akan berada jika kita berhenti bekerja sama?
6. Bagaimana Anda menangani rahasia, dan siapa yang memiliki akses?
7. Bagaimana frekuensi pembaruan (patch) dependensi Anda?
8. Apakah Anda pernah lulus tinjauan keamanan klien sebelumnya?

Pasangan yang menjawab kedelapan pertanyaan itu tanpa merasa canggung memberi tahu Anda sesuatu yang tidak bisa disampaikan oleh lamaran pernikahan mana pun.

Kesalahan umum yang dilakukan pembeli pada tahun 2026

Lima pola, dan berapa biaya sebenarnya untuk masing-masing pola tersebut.

Kesalahan	Mengapa hal itu harus Anda bayar
Membandingkan tarif per jam	Tingkat terendah saat ini sering kali menandakan kode yang paling banyak dihasilkan dan paling sedikit ditinjau. Anda mengoptimalkan angka yang salah.
Dengan asumsi dihasilkan berarti ditinjau	Dua aktivitas berbeda, dilakukan oleh orang yang berbeda. Hanya satu di antaranya yang cepat.
Menerima antrean tiket sebagai bentuk akuntabilitas.	Antrian mendistribusikan ketiadaan kepemilikan alih-alih menyediakannya.
Memperlakukan dukungan sebagai fase setelah pekerjaan sebenarnya.	Dukungan pelanggan adalah tahap di mana perangkat lunak menghasilkan uang atau berhenti beroperasi tanpa kabar.
Menyerahkan proses serah terima di akhir.	Tanyakan tentang kepemilikan repositori dan transfer kredensial pada saat penandatanganan, bukan pada saat pelepasan.

Jadi, apa jawaban jujurnya?

Jika mesin mampu memproduksi lebih banyak, kepemilikan menjadi lebih penting, bukan sebaliknya. Kemampuan tanpa akuntabilitas hanyalah cara yang lebih cepat untuk menciptakan sesuatu yang tidak dapat dipertanggungjawabkan oleh siapa pun.

Saya lebih memilih menjadi firma yang dihubungi seseorang pukul sebelas malam daripada firma dengan perlengkapan kerja paling canggih. Peralatan kerja sekarang sama di mana-mana. Yang berbeda adalah orang yang mengangkat telepon, dan itulah bagian yang layak dibayar.

FAQ (Pertanyaan Umum)

Siapa yang bertanggung jawab secara hukum atas bug dalam kode yang dihasilkan AI?

Tanggung jawab berada pada pihak yang dikontrak untuk mengirimkan dan memelihara perangkat lunak, bukan pada alat yang memproduksinya. Vendor AI umumnya mengecualikan output yang dihasilkan dari ganti rugi. Periksa perjanjian pengembangan Anda untuk mengetahui siapa yang menanggung tanggung jawab atas cacat dan berapa lama setelah pengiriman.

Apakah perangkat lunak masih perlu dihargai per jam?

Penetapan harga per jam masuk akal ketika waktu dan hasil kerja saling terkait erat. Dengan bantuan AI, pembuatan konten menjadi cepat, sedangkan peninjauan, pengujian, dan dukungan jangka panjang tidaklah cepat. Penetapan harga per jam sekarang mengenakan biaya tertinggi untuk bagian pekerjaan yang paling murah dan biaya terendah untuk risikonya.

Apakah pengembangan dengan harga tetap lebih baik daripada pengembangan per jam?

Harga tetap menyelesaikan masalah yang salah. Harga tetap membatasi biaya hingga pengiriman, tetapi kemudian kepemilikan tidak didanai sejak hari pertama setelahnya. Pertanyaan yang bermanfaat bukanlah apakah harga tetap dihitung per jam, tetapi apakah perjanjian tersebut menyatakan siapa yang bertanggung jawab setelah serah terima dan untuk berapa lama.

Apakah penggunaan AI membuat pengembangan perangkat lunak lebih murah bagi klien?

Terkadang, untuk biaya pembangunan. Jarang untuk total biaya kepemilikan. Penghematan tampak pada saat pembangkitan dan hilang selama peninjauan, pekerjaan keamanan, dan pemeliharaan. Tanyakan kepada vendor apa saja yang termasuk dalam harga mereka setelah pengiriman, bukan hanya apa yang termasuk sebelum pengiriman.

Bagaimana cara saya mengevaluasi perusahaan pengembang yang menggunakan AI?

Tanyakan berapa banyak kode program Anda yang akan dihasilkan, siapa yang meninjaunya sebelum digabungkan, dan apakah para insinyur mereka dapat menjelaskan hasilnya tanpa menggunakan alat tersebut. Kemudian tanyakan siapa saja yang namanya tercantum dalam proyek Anda dan apa komitmen respons yang diberikan jika terjadi kesalahan.

Mengapa aplikasi bisa rusak padahal tidak ada yang mengubah kodenya?

Lingkungan di bawahnya terus berubah. Rilis sistem operasi, penghentian dukungan SDK, sertifikat yang kedaluwarsa, perubahan harga API, dan migrasi gerbang pembayaran semuanya merusak perangkat lunak yang sedang berjalan. Kode tetap diam sementara segala sesuatu di sekitarnya bergerak.