Konten disusun AI — bisa keliru. Baca disclaimer lengkap
Builder.ai
Ringkasan
Apa yang Terjadi
Builder.ai (sebelumnya Engineer.ai) adalah startup berbasis di London yang didirikan pada 2016 oleh Sachin Dev Duggal dan Saurabh Dhoot. Perusahaan ini menjanjikan platform yang memungkinkan siapa pun membangun aplikasi atau situs web "semudah memesan pizza", didukung oleh asisten AI bernama Natasha yang diklaim mampu membangun 80% produk secara otomatis sebelum engineer manusia menyelesaikan sisanya.
Builder.ai mengumpulkan total pendanaan sekitar US$445 juta dari investor ternama termasuk Qatar Investment Authority (QIA), Microsoft, Insight Partners, ICONIQ Capital, dan Jungle Ventures, mencapai valuasi puncak sekitar US$1,5 miliar pada 2023. Namun, di balik narasi AI yang gemilang, investigasi mengungkap bahwa sebagian besar pekerjaan dilakukan oleh sekitar 500-1.000 engineer manusia — terutama berbasis di India — melalui jaringan outsourcing, sementara kemampuan AI sesungguhnya jauh lebih terbatas dari yang diklaim.
Krisis memuncak pada 2025 ketika audit internal menemukan manipulasi pendapatan besar-besaran: pendapatan 2024 yang dilaporkan US$220 juta ternyata hanya US$55 juta — inflasi 300%. Bloomberg mengungkap skema round-tripping dengan perusahaan India VerSe Innovation, di mana kedua perusahaan saling mengirim faktur senilai hampir US$60 juta untuk layanan yang tidak pernah diberikan. Pendapatan 2023 yang sebelumnya dilaporkan US$180 juta juga dikoreksi menjadi sekitar US$45 juta.
Pada Februari 2025, Duggal digantikan sebagai CEO. Maret 2025, 270 karyawan di-PHK. Pada 20 Mei 2025, setelah kreditor Viola Credit menyita US$37 juta dari rekeningnya, Builder.ai secara resmi mengumumkan kebangkrutan dan mem-PHK seluruh sisa karyawan — sekitar 1.000 orang kehilangan pekerjaan. Pelanggan kehilangan akses ke aplikasi, source code, dan data bisnis mereka tanpa pemberitahuan.
Kasus ini kini menjadi subjek investigasi kriminal oleh FBI dan jaksa AS (grand jury subpoena terhadap mantan CFO pada Oktober 2025), serta probe pencucian uang oleh Direktorat Penegakan Hukum India terhadap Duggal terkait transaksi era pra-Builder.ai. Builder.ai menjadi simbol bahaya AI washing — di mana hype AI dieksploitasi untuk menarik investasi miliaran dolar tanpa fondasi teknologi yang sepadan — dan kegagalan due diligence investor besar yang mengabaikan red flag bertahun-tahun.
Kronologi
Urutan Kejadian
Engineer.ai didirikan oleh Sachin Dev Duggal dan Saurabh Dhoot
Sachin Dev Duggal, entrepreneur asal India-Inggris, mendirikan Engineer.ai di London bersama Saurabh Dhoot. Visinya: platform yang menggunakan AI untuk mengotomasi pengembangan aplikasi, menjadikannya terjangkau dan cepat bagi siapa pun. Duggal sebelumnya memimpin Nivio, startup cloud computing yang gagal dan kini terkait investigasi pencucian uang India.
Platform diluncurkan, meraih US$29,5 juta Series A
Engineer.ai meluncurkan platform pengembangan aplikasi dengan asisten AI bernama Natasha. Pendanaan Series A sebesar US$29,5 juta dipimpin oleh Lakestar dan Jungle Ventures. Perusahaan mengklaim Natasha mampu membangun 80% aplikasi secara otomatis menggunakan pustaka komponen modular.
Wall Street Journal mengungkap klaim AI yang dilebih-lebihkan
The Wall Street Journal menerbitkan investigasi berjudul "AI Startup Boom Raises Questions About Exaggerated Tech Savvy" dengan Engineer.ai sebagai target utama. Karyawan — baik aktif maupun mantan — mengungkap bahwa "tidak ada AI nyata" dan sebagian besar pekerjaan coding dilakukan manual oleh ratusan engineer di India. Ini menjadi red flag publik pertama yang signifikan.
Rebrand ke Builder.ai; gugatan whistleblower Robert Holdheim
Merespons kontroversi WSJ, Duggal melakukan rebranding dari Engineer.ai menjadi Builder.ai — upaya jelas untuk menjauhkan merek dari skandal. Bersamaan itu, mantan eksekutif Robert Holdheim mengajukan gugatan US$5 juta, menuduh ia dipecat setelah menyuarakan kekhawatiran tentang praktik penipuan dan pemasaran menyesatkan kepada investor. Gugatan kemudian diselesaikan.
Meraih US$100 juta Series C dari Insight Partners
Meski sempat diterpa kontroversi 2019, Builder.ai berhasil mengamankan pendanaan Series C sebesar US$100 juta yang dipimpin Insight Partners (New York), dengan partisipasi IFC, Jeffrey Katzenberg/WndrCo, dan Nikesh Arora. Pendanaan ini menunjukkan bahwa investor besar tetap percaya — atau mengabaikan — red flag sebelumnya.
US$250 juta Series D dipimpin QIA; valuasi ~US$1,5 miliar
Qatar Investment Authority (QIA) memimpin putaran pendanaan Series D senilai US$250 juta, dengan partisipasi ICONIQ Capital, Jungle Ventures, dan Insight Partners. Microsoft juga berinvestasi dua minggu sebelumnya dan menjalin kemitraan reseller. Valuasi melonjak 1,8x menjadi sekitar US$1,5 miliar — momen puncak sebelum kejatuhan.
Co-founder terlibat kasus kriminal di India
Kedua co-founder terjerat kasus kriminal terpisah di India. Sachin Dev Duggal disebut sebagai "penerima manfaat utama" dalam kasus pencucian uang terkait Videocon oleh Direktorat Penegakan Hukum, dengan dana dari Videocon dialirkan ke perusahaan Swiss miliknya (nHoldings SA). Saurabh Dhoot terlibat kasus penipuan pinjaman yang juga melibatkan Videocon. Kedua kasus ini terkait transaksi sebelum era Builder.ai.
Pinjaman darurat US$50 juta dari Viola Credit berdasarkan proyeksi yang digelembungkan
Builder.ai mengamankan fasilitas utang US$50 juta dari Viola Credit dengan memproyeksikan pendapatan 2024 sebesar US$220 juta. Angka ini kemudian terbukti digelembungkan 300% — pendapatan aktual hanya sekitar US$55 juta. Perusahaan juga tidak memiliki CFO selama 18 bulan dan hampir separuh tim teknis telah mengundurkan diri sepanjang 2024.
Duggal digantikan sebagai CEO oleh Manpreet Ratia
Di tengah meningkatnya tuduhan misconduct keuangan, Sachin Dev Duggal digantikan sebagai CEO oleh Manpreet Ratia dari Jungle Ventures. Duggal kemudian mengambil gelar "Chief Wizard Officer" sebelum sepenuhnya tersingkir. Penggantian ini merupakan upaya terakhir untuk menyelamatkan perusahaan.
Bloomberg mengungkap skema round-tripping dengan VerSe Innovation
Bloomberg News melaporkan bahwa Builder.ai dan perusahaan media sosial India VerSe Innovation (pemilik Dailyhunt) telah saling mengirim faktur senilai hampir US$60 juta antara 2021-2024 untuk layanan yang tidak pernah diberikan — praktik round-tripping klasik untuk menggelembungkan pendapatan. Pendapatan 2023 yang sebelumnya dilaporkan US$180 juta dikoreksi menjadi ~US$45 juta. VerSe membantah tuduhan tersebut.
Kebangkrutan: Viola Credit menyita US$37 juta, ~1.000 karyawan di-PHK
Setelah kas menyusut ke ~US$7 juta, kreditor Viola Credit menyita US$37 juta dari rekening operasional Builder.ai. CEO interim Manpreet Ratia mengumumkan kepada karyawan bahwa perusahaan kehabisan uang dan mengajukan kebangkrutan. Seluruh sisa karyawan — sekitar 1.000 orang — di-PHK seketika. Pelanggan kehilangan akses ke aplikasi, source code, dan data bisnis mereka tanpa pemberitahuan. Builder.ai juga berhutang US$85 juta ke Amazon dan US$30 juta ke Microsoft untuk tagihan cloud.
Mantan CFO di-subpoena oleh grand jury AS
Andres Elizondo, mantan finance chief Builder.ai (2021-2023), di-subpoena oleh grand jury di Manhattan. Agen FBI menghentikannya di bandara Dallas pada Agustus 2025. Jaksa menuntut informasi terkait dugaan pelanggaran wire fraud, securities fraud, dan konspirasi — menandai eskalasi investigasi kriminal AS terhadap kasus ini.
Aktor & Insentif
Siapa yang Terlibat
Sachin Dev Duggal (Founder & CEO, kemudian 'Chief Wizard Officer')
Peran dalam Kasus
Arsitek utama narasi AI Builder.ai dan wajah publik perusahaan. Menurut tuduhan, mengawasi inflasi pendapatan dan klaim AI yang dilebih-lebihkan. Digantikan sebagai CEO pada Februari 2025. Juga terlibat dalam kasus pencucian uang India terpisah terkait Videocon/Nivio (pra-Builder.ai). Membantah tuduhan misreporting.
Insentif
Membangun perusahaan teknologi global bervaluasi miliaran dolar; mempertahankan narasi AI yang kuat untuk menarik investasi terus-menerus; terkait secara personal dengan klaim bahwa Natasha adalah AI revolusioner.
Saurabh Dhoot (Co-founder)
Peran dalam Kasus
Co-founder Builder.ai yang juga terjerat kasus kriminal terpisah di India — terkait dugaan penipuan pinjaman yang melibatkan pamannya Venugopal Dhoot dan Videocon. Kasus ini terkait transaksi pra-Builder.ai, bukan operasi Builder.ai itu sendiri.
Insentif
Membangun dan mengembangkan startup bersama Duggal; koneksi keluarga dengan konglomerat Videocon memberikan jaringan bisnis.
Qatar Investment Authority / QIA (Lead Investor Series D)
Peran dalam Kasus
Memimpin putaran pendanaan US$250 juta pada Mei 2023 yang mendorong valuasi ke ~US$1,5 miliar. Menyatakan 'sangat bersemangat bermitra dengan pemimpin di sektor ini'. Kini menghadapi potensi kerugian hampir seluruh investasinya setelah kebangkrutan. Menunjukkan risiko FOMO investing bahkan oleh investor institusional paling sophisticated.
Insentif
Diversifikasi portofolio sovereign wealth fund ke teknologi AI; mencari peluang pertumbuhan tinggi di sektor yang sedang booming.
Microsoft (Investor & Partner)
Peran dalam Kasus
Berinvestasi dan menjalin kemitraan dua minggu sebelum Series D. Endorsement Microsoft memberikan kredibilitas besar kepada Builder.ai. Ironis: Microsoft kini menjadi salah satu kreditor terbesar dengan tagihan cloud US$30 juta yang tak terbayar.
Insentif
Memperluas ekosistem partner AI; mengintegrasikan Builder.ai ke program reseller Azure.
Robert Holdheim (Mantan Eksekutif / Whistleblower)
Peran dalam Kasus
Mengajukan gugatan US$5 juta pada 2019 terhadap Engineer.ai, menuduh dipecat setelah mengangkat masalah praktik penipuan dan pemasaran menyesatkan kepada investor. Gugatan ini, bersama investigasi WSJ, merupakan peringatan dini yang diabaikan oleh investor berikutnya. Kasus diselesaikan di luar pengadilan.
Insentif
Melindungi integritas profesional; menuntut keadilan atas pemecatan yang diduga tidak sah setelah menyuarakan kekhawatiran etis.
Insight untuk Founder
Pelajaran dari Kasus Ini
AI Washing: Ketika Hype Menggantikan Substansi
Apa yang Terjadi
Builder.ai mengklaim asisten AI Natasha mampu membangun 80% aplikasi secara otomatis. Realitanya, menurut berbagai investigasi, sebagian besar pekerjaan dilakukan oleh ratusan engineer manusia di India melalui jaringan outsourcing. Analisis nuansa (The Pragmatic Engineer) menunjukkan Builder.ai memang memiliki tim AI kecil (15-30 orang), namun kemampuan AI sebenarnya jauh lebih terbatas dari yang dipasarkan.
Polanya
Perusahaan mengeksploitasi hype AI untuk menarik investasi — 'AI washing' — di mana label AI ditempelkan pada proses yang sebenarnya manual atau semi-manual. Ini bukan unik bagi Builder.ai; banyak startup melakukan hal serupa dalam derajat berbeda, tetapi Builder.ai menjadi kasus paling dramatis karena skala investasi (US$445 juta) dan kesenjangan antara klaim dan realita.
Tanda Bahaya Dini
- Klaim AI revolusioner tanpa publikasi teknis, paper, atau benchmark independen
- Jumlah engineer outsourcing yang tidak proporsional terhadap klaim otomasi
- Investigasi media (WSJ 2019) yang mengungkap klaim berlebihan, diikuti rebranding
- Whistleblower (Holdheim) yang dipecat setelah menyuarakan kekhawatiran
Aksi Pencegahan
- Lakukan technical due diligence independen: minta demonstrasi teknis AI, periksa arsitektur, wawancara engineer
- Waspadai startup yang rebrand setelah skandal tanpa perubahan substansial
- Perhatikan rasio karyawan AI vs. outsourced labor — ketidakseimbangan besar adalah sinyal bahaya
- Ambil serius peringatan dari whistleblower dan media investigatif
Round-Tripping dan Manipulasi Pendapatan: Fraud Klasik di Baju Baru
Apa yang Terjadi
Builder.ai dan VerSe Innovation saling mengirim faktur senilai hampir US$60 juta antara 2021-2024 untuk layanan yang menurut Bloomberg tidak pernah diberikan. Pendapatan 2024 digelembungkan dari US$55 juta menjadi US$220 juta (inflasi 300%). Pendapatan 2023 dikoreksi dari US$180 juta menjadi ~US$45 juta.
Polanya
Round-tripping — dua perusahaan saling menagih jumlah serupa untuk menggelembungkan pendapatan — adalah teknik manipulasi keuangan klasik. Dalam konteks startup yang valuasinya bergantung pada pertumbuhan pendapatan, teknik ini memberikan ilusi hypergrowth yang menarik investor berikutnya.
Tanda Bahaya Dini
- Pertumbuhan pendapatan yang terlalu sempurna dan konsisten
- Konsentrasi pendapatan pada sedikit klien besar (terutama jika kliennya juga startup)
- Tidak ada CFO selama 18 bulan — kekosongan pengawasan keuangan
- Pendapatan yang tidak proporsional terhadap jumlah pelanggan atau penggunaan produk
Aksi Pencegahan
- Verifikasi pendapatan secara independen: cek apakah klien besar benar-benar menggunakan dan membayar layanan
- Pastikan ada CFO/pengawas keuangan independen yang kredibel sepanjang waktu
- Audit dua arah: periksa apakah klien besar juga menjadi vendor (indikator round-tripping)
- Investor harus memiliki hak audit dan menggunakannya secara berkala
Kegagalan Due Diligence: FOMO Investor vs. Red Flag yang Terang Benderang
Apa yang Terjadi
Meski investigasi WSJ (2019) dan gugatan whistleblower sudah mengungkap masalah sejak awal, investor-investor terkemuka — termasuk QIA, Microsoft, Insight Partners, dan ICONIQ Capital — tetap mengucurkan ratusan juta dolar pada 2021 dan 2023. Total US$350+ juta diinvestasikan SETELAH red flag publik pertama.
Polanya
Dalam iklim investasi AI yang euphoria, FOMO (Fear Of Missing Out) mengalahkan due diligence rasional. Investor institusional besar mengasumsikan bahwa investor lain telah melakukan verifikasi, menciptakan efek 'herd' di mana tidak ada yang benar-benar memeriksa secara mendalam. Endorsement Microsoft memberikan efek halo yang menutupi masalah mendasar.
Tanda Bahaya Dini
- Investigasi media besar (WSJ) yang secara eksplisit mempertanyakan klaim inti perusahaan
- Gugatan dari mantan eksekutif senior yang menuduh penipuan
- Rebranding yang bertepatan dengan skandal
- Co-founder terlibat kasus kriminal di India (2024)
- Tidak ada CFO selama 18 bulan; eksodus massal tim teknis
Aksi Pencegahan
- Jangan mengandalkan reputasi investor lain sebagai proxy due diligence
- Tangani investigasi media dan gugatan whistleblower sebagai sinyal serius, bukan noise
- Lakukan reference check ke mantan karyawan, bukan hanya karyawan yang ditunjuk perusahaan
- Perhatikan co-founder background secara menyeluruh, termasuk entitas bisnis sebelumnya
Dampak pada Stakeholder: Pelanggan dan Karyawan yang Menjadi Korban
Apa yang Terjadi
Sekitar 1.000 karyawan kehilangan pekerjaan — banyak tanpa peringatan, dengan beberapa mengetahuinya saat sedang meeting dengan klien. Pelanggan yang telah membangun aplikasi produksi di platform Builder.ai kehilangan akses ke software, source code, dan data bisnis mereka tanpa pemberitahuan. Builder.ai berhutang US$85 juta ke Amazon dan US$30 juta ke Microsoft untuk tagihan cloud.
Polanya
Ketika startup unicorn runtuh, dampaknya melampaui investor. Karyawan yang telah menginvestasikan karir dan waktu mereka, serta pelanggan yang bergantung pada platform, menjadi korban yang sering terlupakan dalam narasi. Ini menyoroti risiko vendor dependency pada startup yang belum profitable.
Tanda Bahaya Dini
- Platform yang meng-host source code dan data pelanggan tanpa opsi escrow
- Startup yang secara bersamaan kehilangan CFO, CTO, dan separuh tim teknis
- Tagihan cloud (AWS/Azure) yang sangat besar relatif terhadap pendapatan aktual
- Karyawan yang menyuarakan kekhawatiran di Glassdoor tentang transparansi finansial
Aksi Pencegahan
- Pelanggan: selalu negosiasikan source code escrow dan data portability dalam kontrak dengan vendor startup
- Karyawan: perhatikan sinyal kesehatan finansial perusahaan (apakah ada CFO? bagaimana transparansi keuangan?)
- Regulator: pertimbangkan aturan perlindungan data pelanggan dalam konteks kebangkrutan platform teknologi
- Investor: pertimbangkan dampak pada stakeholder non-investor dalam keputusan exit
Bedah Teknikal
Kacamata CTO
Builder.ai menjual janji "bangun aplikasi semudah pesan pizza" lewat asisten AI Natasha. Kunci teknisnya bukan model AI ajaib, melainkan arsitektur Building Blocks — pustaka 500+ fitur reusable (Login, Keranjang Belanja, Push Notification) yang dirakit seperti Lego, lalu dikustomisasi oleh tim developer.
- Otomasi vs manusia: Natasha ada sebagai proyek AI nyata (tim AI inti kecil, ~15 orang, puncak ~30, mayoritas di UK — analisis The Pragmatic Engineer), tapi mayoritas pengerjaan aplikasi produksi dilakukan ratusan engineer outsourcing (banyak di India) yang dibantu Builder IDE internal.
- Model AI: dilaporkan mengorkestrasi LLM pihak ketiga (benchmark internal, pilih model terbaik per kasus), bukan model foundation milik sendiri. Sebagian komponen web Natasha pakai Ruby on Rails.
- Hosting: aplikasi, source code, dan data pelanggan berada di infra terkelola Builder (AWS/Azure) — tanpa escrow.
- Penting: akar krisis Builder.ai terutama fraud keuangan & tata kelola (inflasi pendapatan, round-tripping) yang sedang diinvestigasi — bukan semata kegagalan teknis. Duggal & perusahaan membantah tuduhan. Item berlabel inference adalah dugaan beralasan, bukan fakta; hormati praduga tak bersalah.
Akar Masalah Teknis
AI washing / service-as-software: otomasi yang dijanjikan tak pernah menyusul volume yang dijual
Apa yang terjadi
Natasha dipasarkan mampu membangun ~80% aplikasi otomatis, tetapi kapabilitas AI riil (tim inti ~15-30 orang, orkestrasi LLM pihak ketiga) tumbuh jauh lebih lambat daripada beban proyek. Menurut karyawan, Natasha tak bisa mengejar kecepatan Builder mengambil pekerjaan, sehingga ratusan engineer manusia menutup selisihnya — output mereka disajikan sebagai buatan AI.
Polanya
Pola 'service-as-software': membungkus proses padat karya sebagai produk AI/otomasi. Selama otomasi belum benar-benar menggantikan tenaga manusia, setiap pelanggan baru menambah biaya variabel manusia — margin tetap seperti bisnis jasa, bukan software. Gap klaim-vs-realita membesar seiring skala.
Tanda bahaya dini
- Klaim persentase otomasi tinggi tanpa metrik internal yang menunjukkan tren naik
- Jumlah developer outsourcing bertambah seiring pertumbuhan pendapatan (biaya skala linear)
- Engineer menyuarakan bahwa "AI"-nya sebenarnya manual; kepercayaan tim menurun
- Tak ada benchmark/paper independen yang mengonfirmasi kapabilitas inti
Pencegahan
- Ukur & laporkan automation rate riil secara internal (mis. % tugas yang benar-benar tanpa sentuhan manusia) dan pantau trennya
- Jujur soal unit economics: jika tenaga manusia skala dengan pendapatan, akui itu bisnis jasa dan kelola marginnya
- Ikat klaim pemasaran ke kapabilitas yang terukur, bukan aspirasi roadmap
- Perlakukan keresahan engineer soal 'ini bukan AI nyata' sebagai sinyal produk, bukan sekadar soal moral tim
Utang teknis kronis: aplikasi buggy, integrasi gagal, skalabilitas terbatas
Apa yang terjadi
Sepanjang 2024 dilaporkan menumpuk utang teknis kronis: pengguna mengeluhkan aplikasi buggy, kegagalan integrasi, dan batas skalabilitas parah. Tekanan menjual lebih banyak proyek daripada yang bisa dikirim berkualitas mendorong pengambilan jalan pintas yang menumpuk sebagai kerapuhan sistem.
Polanya
Ketika kecepatan penjualan melampaui kapasitas pengiriman berkualitas, tim membakar 'utang' kualitas untuk mengejar tenggat. Tanpa investasi refactoring & test coverage, kerapuhan menumpuk diam-diam sampai kualitas produk anjlok dan retensi pelanggan tergerus.
Tanda bahaya dini
- Laporan bug & kegagalan integrasi yang berulang dari pelanggan
- Keluhan skalabilitas pada beban produksi nyata
- Backlog perbaikan yang terus tumbuh sementara fitur/proyek baru diprioritaskan
- Rasio waktu 'memadamkan api' vs. membangun yang makin timpang
Pencegahan
- Alokasikan kapasitas tetap untuk membayar utang teknis (mis. anggaran refactoring per sprint)
- Pasang gerbang kualitas (test, review, SLO) sebelum menerima lebih banyak proyek
- Ukur kesehatan teknis (tingkat bug, MTTR, coverage) sebagai metrik bisnis, bukan hanya penjualan
- Batasi laju pengambilan proyek pada kapasitas pengiriman berkualitas, bukan target penjualan
Vendor lock-in eksistensial: pelanggan kehilangan aplikasi, source code, dan data tanpa escrow
Apa yang terjadi
Aplikasi, source code, dan data pelanggan sepenuhnya berada di infra terkelola Builder.ai. Saat perusahaan bangkrut, pelanggan kehilangan akses ke semuanya secara seketika dan tanpa pemberitahuan — tidak ada perjanjian escrow atau mekanisme portabilitas yang melepaskan aset ke pelanggan.
Polanya
Bergantung total pada satu vendor SaaS/platform menjadikan kelangsungan hidup vendor sebagai single point of failure bisnismu sendiri. Startup pra-profit yang membakar kas adalah vendor berisiko tinggi; tanpa escrow & portabilitas, kegagalan vendor = kehilangan total bagi pelanggan.
Tanda bahaya dini
- Source code & data hanya ada di infra vendor, tanpa salinan/ekspor yang bisa diakses pelanggan
- Tidak ada klausul source-code escrow atau data portability di kontrak
- Vendor pra-profit dengan burn tinggi tetapi jadi tumpuan sistem produksi
- Tak ada rencana keluar (exit plan) jika vendor tutup
Pencegahan
- Pelanggan: wajibkan source-code escrow (rilis saat pemicu kebangkrutan) + ekspor data berkala mandiri
- Pelanggan: nilai kesehatan finansial vendor sebelum menaruh sistem kritis di atasnya
- Vendor: tawarkan escrow & portabilitas sebagai fitur kepercayaan — bukan penghalang, tapi pembeda
- Simpan salinan artefak build/kode di repositori yang dikontrol pelanggan bila memungkinkan
FinOps: biaya cloud & tenaga manusia melampaui pendapatan riil (tunggakan US$115 juta)
Apa yang terjadi
Builder.ai menunggak US$85 juta ke AWS dan US$30 juta ke Microsoft untuk tagihan cloud — total ~US$115 juta — sementara pendapatan riil (setelah koreksi) hanya sekitar US$55 juta pada 2024. Biaya infrastruktur ditambah ratusan engineer outsourcing menghasilkan struktur biaya yang tak pernah sepadan dengan pemasukan sesungguhnya.
Polanya
Ketika biaya variabel (cloud yang skala dengan penggunaan + tenaga manusia yang skala dengan proyek) tumbuh secepat atau lebih cepat dari pendapatan, pertumbuhan justru mempercepat pembakaran kas. Ilusi pertumbuhan (yang di sini diperkuat pendapatan yang digelembungkan) menutupi ekonomi unit yang negatif.
Tanda bahaya dini
- Tagihan cloud yang besar & tumbuh relatif terhadap pendapatan riil
- Biaya per proyek didominasi tenaga manusia, bukan komputasi yang bisa diamortisasi
- Tidak ada disiplin FinOps: alokasi biaya per pelanggan/proyek tak dilacak ketat
- Margin kotor yang tak membaik meski volume naik
Pencegahan
- Terapkan FinOps: lacak biaya cloud & tenaga per pelanggan/proyek; kejar margin kotor positif
- Uji ulang unit economics secara jujur — apakah pelanggan tambahan menambah atau mengurangi kas?
- Optimasi/negosiasi komitmen cloud; hindari arsitektur yang biayanya skala liar dengan penggunaan
- Jangan biarkan pertumbuhan pendapatan menutupi margin negatif per unit
Eksodus tim teknis: narasi yang tak jujur mengikis kepercayaan & bus factor
Apa yang terjadi
Dilaporkan hampir separuh tim teknis mengundurkan diri sepanjang 2024, frustrasi oleh alur kerja kacau dan janji kapabilitas AI yang tak sesuai realita di lapangan. Kepergian engineer berpengalaman memperbesar bus factor, mempercepat penumpukan utang teknis, dan melemahkan kemampuan merespons krisis.
Polanya
Engineer adalah pihak pertama yang tahu ketika klaim produk tak cocok dengan realita teknis. Ketika kesenjangan itu dibiarkan, engineer terbaik pergi lebih dulu — eksodus mereka adalah indikator dini yang jujur tentang kesehatan teknis & etis perusahaan, sering mendahului keruntuhan publik.
Tanda bahaya dini
- Lonjakan attrition di tim inti, terutama engineer senior/berpengalaman
- Keluhan berulang soal alur kerja kacau & ekspektasi yang tak realistis
- Kepergian/pergantian kepemimpinan (CFO kosong ~18 bulan; CEO diganti Feb 2025)
- Pengetahuan kritis terkonsentrasi pada sedikit orang yang mulai pergi
Pencegahan
- Perlakukan attrition engineer senior sebagai metrik risiko utama, bukan sekadar HR
- Tutup kesenjangan klaim-vs-realita sebelum ia mengikis kepercayaan tim
- Sebar pengetahuan (dokumentasi, pairing) untuk menurunkan bus factor
- Bangun budaya di mana engineer bisa menyuarakan 'ini tak sesuai klaim' dengan aman
Keputusan Teknis & Trade-off
Arsitektur composable 'Building Blocks' (500+ fitur reusable) + kustomisasi manusia
Konteks
Merakit aplikasi dari komponen fitur reusable (Login, pembayaran, dsb) adalah keputusan teknik yang rasional untuk menekan biaya & waktu pengerjaan berulang — persis yang dilakukan banyak platform low-code/no-code yang sehat. Untuk startup tahap awal, ini cara masuk akal mempercepat time-to-market.
Trade-off
Blok reusable menutup ~80% kebutuhan repetitif, tetapi 20% kebutuhan bespoke tiap pelanggan tetap butuh tenaga developer manusia. Trade-off intinya: efisiensi rakitan vs. kenyataan bahwa kustomisasi tak terhindarkan tetap padat karya.
Hasil
Arsitekturnya sendiri wajar; masalahnya ia dipasarkan sebagai otomasi AI penuh. Ketika volume proyek yang dijual tumbuh lebih cepat daripada kapabilitas Natasha, beban jatuh ke ratusan engineer manusia — mengubah 'perusahaan software' menjadi bisnis jasa padat karya berbaju AI.
Membingkai proses manusia + outsourcing sebagai 'AI Natasha' (service-as-software), bukan otomasi sejati
Konteks
Di iklim euforia AI, narasi 'AI membangun 80% aplikasi' menarik pendanaan besar. Ada dasar nyata (tim Natasha CodeGen benar ada), sehingga klaim terasa kredibel dari luar. Menekankan sisi AI adalah pilihan pemasaran yang, saat itu, tampak menguntungkan.
Trade-off
Menukar kejelasan (model bisnis jasa padat karya dengan margin tipis) demi valuasi 'perusahaan AI' bermargin tinggi. Ini menyembunyikan unit economics sebenarnya: biaya tenaga manusia yang skala linear dengan pendapatan, bukan turun seperti software.
Hasil
Kesenjangan klaim-vs-realita menjadi bom waktu reputasi & hukum. Menurut tuduhan (masih diinvestigasi), tekanan mempertahankan narasi turut mendorong manipulasi pendapatan. Duggal membantah misreporting.
Orkestrasi LLM pihak ketiga (benchmark internal, pilih model terbaik) alih-alih model proprietary
Konteks
Bagi startup non-lab AI, memakai model pihak ketiga terbaik yang tersedia dan merutekan berdasar benchmark adalah build-vs-buy yang rasional — hemat R&D, ikut kemajuan model terbaru. Membangun IDE & lapisan orkestrasi di atasnya adalah tempat nilai tambah yang wajar.
Trade-off
Menghemat R&D model ditukar dengan moat teknis tipis: kapabilitas AI inti bisa direplikasi siapa pun dengan akses model yang sama. Sekaligus mewarisi ketergantungan & biaya inference vendor yang naik seiring penggunaan.
Hasil
Lapisan orkestrasi tak cukup membedakan produk maupun menutupi ekonomi jasa di baliknya; ketergantungan cloud/inference berkontribusi pada tunggakan tagihan ratusan juta dolar saat kas mengering.
Host aplikasi, source code, dan data pelanggan di infra terkelola tunggal — tanpa escrow/portabilitas
Konteks
Platform terkelola end-to-end menyederhanakan pengalaman pelanggan non-teknis ('kami urus semua') dan lazim di dunia low-code. Untuk mempercepat adopsi, mengunci seluruh siklus di infra sendiri terasa efisien.
Trade-off
Kemudahan & kontrol ditukar dengan menjadikan Builder.ai sebagai single point of failure eksistensial bagi tiap pelanggan. Tanpa escrow source code atau portabilitas data, nasib bisnis pelanggan terikat penuh pada kelangsungan hidup vendor.
Hasil
Saat vendor bangkrut, risiko itu terwujud sepenuhnya: pelanggan kehilangan aplikasi, kode, dan data seketika tanpa jalan pemulihan. Kegagalan satu vendor menjadi kegagalan seluruh basis pelanggannya.
Insight untuk CTO
'Service-as-software' bukan software. Jika manusia mengerjakan pekerjaan inti dan otomasi tak pernah menyusul volume, kamu menjalankan bisnis jasa padat karya bermargin tipis — apa pun label AI yang dipasang. Arsitektur composable (Building Blocks) itu wajar; yang fatal adalah memasarkannya sebagai otomasi penuh.
🚩 Peringatan dini
Klaim persentase otomasi tinggi tanpa metrik internal yang naik; jumlah developer outsourcing bertambah seiring pendapatan; engineer diam-diam menutup selisih yang seharusnya diisi AI.
🛡️ Pencegahan
Ukur automation rate riil secara internal dan pantau trennya; ikat klaim pemasaran ke kapabilitas terukur; jujur soal unit economics — jika tenaga manusia skala dengan pendapatan, kelola sebagai bisnis jasa, bukan software.
Otomasi harus melampaui permintaan, bukan mengejarnya. Ketika laju penjualan proyek melebihi kapasitas pengiriman berkualitas, utang teknis menumpuk sampai aplikasi buggy, integrasi gagal, dan skalabilitas mentok — kualitas produk yang runtuh mempercepat hilangnya pelanggan.
🚩 Peringatan dini
Laporan bug & kegagalan integrasi berulang; keluhan skalabilitas di beban nyata; backlog perbaikan tumbuh sementara proyek baru terus diterima.
🛡️ Pencegahan
Alokasikan kapasitas tetap untuk membayar utang teknis; pasang gerbang kualitas (test/SLO) sebelum menerima lebih banyak proyek; batasi laju intake pada kapasitas pengiriman berkualitas, bukan target penjualan.
Untuk pembeli: menaruh source code & data produksi di satu vendor pra-profit tanpa escrow adalah single point of failure eksistensial. Untuk vendor platform: escrow & portabilitas data adalah pembeda kepercayaan, bukan penghalang. Kebangkrutan Builder.ai menghapus aplikasi, kode, dan data pelanggan seketika.
🚩 Peringatan dini
Source code/data hanya ada di infra vendor tanpa ekspor mandiri; tak ada klausul escrow/portabilitas; vendor pra-profit ber-burn tinggi jadi tumpuan sistem kritis.
🛡️ Pencegahan
Pelanggan: wajibkan source-code escrow (rilis saat pemicu kebangkrutan) + ekspor data berkala mandiri, dan nilai kesehatan finansial vendor. Vendor: tawarkan escrow & portabilitas sebagai fitur; simpan artefak build di repo yang bisa diakses pelanggan.
Membeli kapabilitas AI dari LLM pihak ketiga itu rasional, tapi sadari ia menyisakan moat tipis dan mewarisi biaya vendor yang skala dengan penggunaan. Nilai tambah harus ada di lapisan yang benar-benar milikmu (data, orkestrasi, distribusi), bukan pada model yang bisa dipakai siapa pun.
🚩 Peringatan dini
Kapabilitas inti bisa direplikasi pesaing dengan akses model yang sama; biaya inference/cloud naik lebih cepat dari margin; diferensiasi bersandar pada narasi, bukan aset proprietary.
🛡️ Pencegahan
Tetapkan 1-2 lapis untuk membangun keunggulan nyata (data unik, orkestrasi, distribusi); terapkan FinOps atas biaya inference/cloud; uji jujur apa yang tak bisa ditiru pesaing dengan vendor yang sama.
Engineer adalah detektor kebohongan produk paling awal. Ketika separuh tim teknis pergi karena 'ini bukan AI seperti yang kita jual', itu bukan sekadar masalah retensi — itu sinyal dini paling jujur bahwa klaim perusahaan dan realita teknisnya sudah berpisah jauh.
🚩 Peringatan dini
Lonjakan attrition engineer senior; keluhan berulang soal ekspektasi tak realistis & alur kerja kacau; kepemimpinan yang bolong (CFO kosong lama, pergantian CEO).
🛡️ Pencegahan
Perlakukan attrition engineer senior sebagai metrik risiko utama; tutup gap klaim-vs-realita sebelum mengikis kepercayaan; turunkan bus factor lewat dokumentasi/pairing; jaga jalur aman bagi engineer untuk menyuarakan ketidaksesuaian.
Verdict CTO
Kalau saya CTO/pemimpin teknologi Builder.ai 2-3 tahun sebelum kolaps, 5 keputusan yang akan saya ambil berbeda:
-
Jujurkan narasi ke realita teknis. Berhenti memasarkan 'AI membangun 80% aplikasi' selama metrik otomasi internal belum membuktikannya. Bingkai produk sebagai platform composable dengan bantuan AI + tim ahli — kredibel, dan tak menanam bom klaim-vs-realita yang akhirnya meledak jadi krisis reputasi & hukum.
-
Kelola sebagai bisnis dengan unit economics jujur. Karena tenaga manusia skala dengan pendapatan, saya akan melacak margin kotor per proyek sejak awal dan berinvestasi keras agar Natasha benar-benar menaikkan automation rate dari waktu ke waktu — bukan sekadar demo. Target: setiap pelanggan baru menambah kas, bukan menguranginya.
-
Batasi laju intake pada kapasitas pengiriman berkualitas. Menjual proyek lebih cepat daripada yang bisa dikirim baik adalah sumber utang teknis (aplikasi buggy, integrasi gagal, skalabilitas mentok). Saya akan memasang gerbang kualitas dan anggaran refactoring tetap sebelum menerima lebih banyak pekerjaan.
-
Beri pelanggan escrow & portabilitas sejak hari pertama. Source-code escrow yang rilis saat pemicu kebangkrutan plus ekspor data mandiri akan mengubah risiko eksistensial pelanggan menjadi pembeda kepercayaan. Ini melindungi ribuan bisnis yang akhirnya kehilangan segalanya saat perusahaan tutup.
-
Disiplin FinOps atas cloud & inference. Tunggakan ~US$115 juta ke AWS & Microsoft menandakan biaya infrastruktur yang lepas kendali relatif terhadap pendapatan riil. Saya akan melacak biaya per pelanggan/proyek, menegosiasi komitmen cloud, dan menolak arsitektur yang biayanya skala liar tanpa margin yang menyertainya.
Sumber
- Builder.ai promised AI-built apps. Who really did the work? — Rest of World (tier 1)
- What was Builder.ai and why did it shut down? — Rest of World (tier 1)
- Builder.ai did not 'fake AI with 700 engineers' — The Pragmatic Engineer (Gergely Orosz) (tier 2)
- The Pulse #137: Builder.ai did not 'fake AI with 700 engineers' — The Pragmatic Engineer (Newsletter) (tier 2)
- Builder.ai coded itself into a corner – now it's bankrupt — The Register (tier 1)
- 700 Engineers – Not AI – Developed Code at $1.5B Disruptor Filing Bankruptcy — eWEEK (tier 2)
- Builder.ai collapses after revelation that its 'AI' was hundreds of engineers — TechSpot (tier 2)
- Builder.ai collapse: Why you need AI escrow in 2026 — CodeKeeper (tier 3)
- Codegen with Natasha: Reinventing Software Development With AI — Builder.ai (Company Blog) (tier 3)
- Builder.ai Collapsed After Finding Sales 'Inflated By 300 Percent' — Silicon UK (tier 2)
- This Bankrupt AI Startup Was More Artificial Than Intelligent — DevOps.com (tier 2)
Sentimen Publik
Bagaimana Publik Memandang
Sentimen mengukur persepsi publik, bukan fakta hukum. Baca metodologi untuk batasan dan bias yang diakui.
Liputan media arus utama (Bloomberg, Rest of World, The Register, TechCrunch, Sifted) secara dominan membingkai Builder.ai sebagai kasus AI washing dan penipuan keuangan terbesar di era AI boom. Narasi '700 engineer India menyamar jadi AI' menjadi headline viral meski realitanya lebih bernuansa. Beberapa analis (Pragmatic Engineer) memberikan perspektif lebih seimbang, tetapi nada mayoritas sangat kritis.
Pelanggan kehilangan akses ke aplikasi, source code, dan data bisnis tanpa pemberitahuan saat kebangkrutan. Sekitar 1.000 karyawan di-PHK — banyak tanpa peringatan, beberapa mengetahuinya saat sedang meeting klien. Review Glassdoor menunjukkan frustrasi mendalam atas ketidaktransparanan keuangan. Sentimen sangat negatif dari mereka yang terdampak langsung.
Komunitas founder/tech terbagi: satu kubu melihat Builder.ai sebagai penipuan terencana dan simbol bahaya AI washing yang harus jadi pelajaran; kubu lain (dipimpin oleh analisis Pragmatic Engineer) berargumen bahwa masalah utamanya adalah fraud keuangan, bukan 'AI palsu', dan bahwa narasi populer menyederhanakan realitas. Kedua perspektif sepakat bahwa kegagalan due diligence investor sangat mengkhawatirkan.
FBI dan jaksa AS mengeluarkan subpoena dan menginvestigasi dugaan wire fraud, securities fraud, dan konspirasi. Direktorat Penegakan Hukum India mengejar kasus pencucian uang terhadap Duggal (terkait Videocon). Grand jury Manhattan memeriksa mantan CFO. Posisi penegak hukum jelas menunjukkan dugaan pelanggaran hukum serius, meski belum ada vonis.
Diskusi di media sosial (Twitter/X, Reddit, Hacker News, LinkedIn) didominasi oleh kemarahan dan sinisme. Kasus ini menjadi meme 'AI washing' definitif — headline '700 Indian engineers pretending to be AI' viral secara global. Banyak komentar mengaitkannya dengan bubble AI yang lebih luas dan mempertanyakan apakah startup AI lain melakukan hal serupa.