Kode startup saya yang gagal setelah 3 tahun kini dibuka

 (dylanhuang.com)
3 poin oleh GN⁺ 2024-12-18 | 1 komentar | Bagikan ke WhatsApp
  • Konfig dimulai sebagai startup alat pengembang yang memudahkan integrasi API, tetapi ditutup tiga tahun kemudian dan merilis codebase berisi kode produk serta artefak operasional
  • Produk intinya adalah SDK Generator yang membuat library klien dari spesifikasi OpenAPI, lalu berkembang hingga mencakup dokumentasi dan lingkungan pengujian API interaktif
  • Ada respons dari sebagian pelanggan startup, tetapi karena sulitnya menutup kontrak dan harga yang rendah, bisnis ini sulit dibesarkan menjadi bisnis dengan pertumbuhan super cepat
  • Setelah itu mereka beralih ke produk AI vertical B2B SaaS, tetapi lewat berbagai wawancara dan proses penjualan pun mereka tidak menemukan respons pasar (traction) yang cukup meyakinkan untuk menjadi bisnis besar
  • Repositori publik dibuka apa adanya dalam kondisi saat penutupan, tanpa perapian atau revisi, dan mencakup kode produk, eksperimen pivot, skrip penjualan, konfigurasi deployment, serta situs web pemasaran

Alat pengembang API yang dibuat Konfig

  • Konfig adalah startup alat pengembang API yang dimulai pada akhir 2022 dan berfokus pada penyederhanaan cara pengembang menangani API
  • Tujuannya adalah meningkatkan pembuatan SDK, dokumentasi, dan alat pendukung pengujian
  • Produk utamanya adalah SDK Generator
    • Menerima spesifikasi OpenAPI sebagai input lalu menghasilkan library klien untuk berbagai bahasa pemrograman
    • Setelah itu berkembang menjadi alat dokumentasi API dan lingkungan pengujian API interaktif

Batas pertumbuhan dan pivot ke AI

  • Ada traction dari sebagian pelanggan startup, tetapi tidak berlanjut menjadi bisnis dengan pertumbuhan super cepat
  • Sulit menandatangani kontrak dengan calon pelanggan, dan meskipun ROI bisa dibuktikan, kisaran harganya terlalu rendah
  • Setelah kemajuan generative AI, mereka melihat peluang untuk menyelesaikan masalah yang sebelumnya sulit dipecahkan dan melakukan pivot ke produk AI vertical B2B SaaS
  • Mereka menjalankan wawancara pengguna dan penjualan untuk berbagai ide, tetapi tidak menemukan traction yang cukup untuk memberikan keyakinan bahwa arahnya bisa menjadi bisnis besar

Repositori yang dibuka apa adanya saat penutupan

  • Repositori publiknya adalah konfig-dev/konfig
  • Repositori dibuka persis seperti kondisinya saat perusahaan ditutup
    • Tanpa perapian
    • Tanpa pemolesan
    • Tanpa revisi
    • Codebase ini menunjukkan kondisi nyata kode startup yang tidak difilter

Produk utama yang dibuat selama 3 tahun

Kode operasional dan eksperimen yang ikut dipublikasikan

Refleksi yang ditinggalkan pendirinya

  • Dylan Huang meninggalkan pekerjaannya pada Maret 2022 untuk fokus penuh pada startup, dan tetap mencoba meski tahu ada kemungkinan gagal
  • Ia menerima kegagalan ini sebagai pengalaman yang mengajarkan lebih banyak daripada keberhasilan
  • Langkah berikutnya adalah menjajaki peluang baru, mencari posisi yang cocok di pasar kerja, dan terus belajar serta berkembang
  • Ia juga membuka kemungkinan untuk suatu hari kembali menantang diri dengan membangun sesuatu secara langsung

Bacaan terkait

1 komentar

 
GN⁺ 2024-12-18
Komentar Hacker News

  • Saya jadi bertanya-tanya, kalau targetnya bisnis kecil alih-alih “bisnis raksasa” yang “tumbuh sangat cepat”, berapa banyak produk niche bagus yang masih akan bertahan sekarang

    • Mudah memang mengatakannya, tapi saat benar-benar dijalankan, itu sangat sulit karena harus bertahan praktis tanpa gaji selama 3–5 tahun sambil berharap hasil yang mirip dengan bisnis yang didanai investor
      Agar startup berisi 2–3 orang di negara maju bisa bertahan, mereka harus menjual lisensi 10 dolar per bulan dalam jumlah yang luar biasa banyak, dan biaya peluang juga harus diperhitungkan
    • Jika mengambil investasi untuk menutup biaya yang dibutuhkan setiap bulan, dari sudut pandang investor harus ada potensi pertumbuhan sangat cepat agar perhitungan portofolionya masuk akal
      Kalau sejak awal menargetkan bisnis kecil yang berkelanjutan lalu berhasil, investasi bisa dihindari, tetapi jika baru pivot ke arah yang benar-benar baru di pertengahan hingga akhir perjalanan perusahaan, kemungkinan besar sebagian besar cadangan kas sudah terbakar
    • Dengan hasil seperti itu, lebih masuk akal bekerja di perusahaan besar dan mendapat kompensasi serupa tanpa risiko
    • Saya juga penasaran soal bagian ini. Saya salah satu dari 3 co-founder perusahaan bootstrap yang melakukan konsultasi di wilayah dengan biaya hidup rendah. Selama beberapa tahun kami sudah membayar gaji 50 ribu dolar per tahun kepada para founder, dan meski kami tidak bisa dibilang sangat beruntung atau punya penilaian bisnis yang luar biasa tajam, bisnisnya berjalan cukup baik
      Pendapatan tahun ini 400 ribu dolar, laba 150 ribu dolar, pertumbuhan 40%, dan prospek penjualan juga jauh lebih baik dibanding awal tahun. Kami memperkirakan pertumbuhan kuat lagi tahun depan, dan masih jauh dari saturasi pasar, jadi ruang untuk tumbuh beberapa tahun ke depan masih besar
      Jika gaji digabung dengan 1/3 laba, tahun ini nilainya 100 ribu dolar, dan dengan pertumbuhan 40% perusahaan berlipat dua setiap 2 tahun. Kalau berjalan lancar, gaji dan laba saja sudah cukup menarik, ditambah lagi ada peluang exit yang bisa membuat para founder mendapat beberapa juta dolar
    • Di sini terasa ada maksud tersirat, “Tuh kan, sudah kubilang sulit!”
      Mencoba membangun perusahaan seperti Google dan mencoba membangun perusahaan seperti Basecamp, keduanya sah-sah saja; itu hanya jenis perusahaan yang berbeda
      Justru mudah meremehkan risiko membangun “bisnis berisiko rendah”, dan semua bisnis itu sulit. Salut untuk Konfig

  • Sebagai pelanggan Konfig, saya benar-benar menyayangkan ini. Kami mungkin adalah pelanggan pertama mereka, dan sepertinya juga sempat disebut di commit awal
    Dylan dan Anh-Tuan menyelesaikan beberapa masalah nyata kami dengan sangat baik. Mereka menyediakan SDK yang dihasilkan serta dokumentasi/tutorial hosted yang enak dilihat di satu tempat, dan memungkinkan pengguna memanggil API kami agar bisa langsung bereksperimen dengan data nyata
    Sebelum Konfig, kami menulis SDK pembungkus API secara manual dan tidak konsisten, dan dokumentasi di-host dengan ReadMe, tetapi karena persyaratan penandatanganan request pada API kami, dokumentasi itu tidak berjalan baik secara interaktif
    Berkat Konfig yang merilisnya sebagai open source, sekarang kami meng-host dokumentasi sendiri: https://docs.snaptrade.com/
    Saya sangat menghormati tim ini, dan berharap mereka bisa menemukan cara untuk terus berjalan
    Jika Anda menjalankan produk seperti Konfig yang disukai pelanggan tetapi pendapatannya tidak tumbuh sebesar yang dibutuhkan, menaikkan harga lebih tinggi juga layak dipertimbangkan. Kami akan bersedia membayar 2–3 kali lipat dari yang Konfig tagihkan, dan akan membayar lebih seiring pertumbuhan kami, tetapi mereka tidak pernah memintanya, dan juga tidak membuat skema penagihan berbasis penggunaan seperti biaya bulanan per SDK atau biaya bulanan per demo

    • Saya mengenal Konfig lewat produk Anda. Dokumentasinya sangat bagus sampai saya harus mencari tahu apa yang dipakai di baliknya, dan memang jauh lebih baik daripada Swagger atau Redoc
    • Saya penasaran apakah Anda pernah mencoba langsung https://github.com/OpenAPITools/openapi-generator
    • Jika menginginkan alternatif dokumentasi API yang ringan, saya merekomendasikan Scalar. Sederhana dan mudah digunakan, tetapi jauh lebih baik daripada dokumentasi Swagger

  • Budaya startup Amerika benar-benar aneh. Tidak semuanya harus melakukan ekspansi supercepat, dan tidak semuanya harus menjadi raksasa
    Bisnis seharusnya lebih berfokus pada keberlanjutan, bukan pivot tiga kali selama 2–3 tahun lalu tutup

    • Di satu sisi benar, tetapi di sisi lain, fokus obsesif pada “ekspansi raksasa atau gagal” kemungkinan besar justru yang mendorong ekosistem startup Amerika ke posisinya sekarang, dan alasan mengapa ia jauh lebih maju daripada bagian dunia lainnya
      Jika Anda mengatakan kepada banyak pendiri startup Eropa bahwa “dalam 5 tahun perusahaan akan stagnan di 15–20 karyawan, memiliki arus kas yang stabil, dan membayar Anda 200 ribu–250 ribu dolar per tahun,” mereka akan menganggapnya sukses besar. Di Amerika, terutama jika sudah menerima pendanaan ventura, itu bisa dianggap gagal
      Saya pernah mendengar investor ventura Silicon Valley berkata terang-terangan, “kalau Anda menganggap menjual perusahaan seharga 50 juta dolar sebagai kesuksesan, pola pikir Anda salah dan saya tidak ingin bekerja sama dengan Anda”
      Jika Anda puas dengan kesuksesan kecil dan pertumbuhan stabil tanpa mengambil tantangan besar dan risiko besar, Anda tidak akan pernah mendapatkan hadiah besar. Itu mungkin lebih sehat bagi individu, tetapi bisa buruk bagi perekonomian secara keseluruhan
    • Bisnis kecil yang menguntungkan, yaitu perusahaan yang mungkin tampak membosankan dengan tim kecil dan tujuan jangka panjang, sepertinya jarang muncul di halaman depan HN karena mereka tidak menetapkan target yang tidak realistis besar
      Menarik bahwa budaya ini menerima pola pikir seperti “bergerak cepat dan hancurkan sesuatu”, tetapi tampaknya terutama hanya berlaku di industri teknologi. Begitu juga pebisnis yang gagal beberapa kali disebut “serial entrepreneur”; sulit menyebut menjual perusahaan yang tidak berkelanjutan sebagai kesuksesan
      Lucu kalau membayangkan bagaimana rasanya jika seseorang yang gagal di beberapa cabang olahraga menyebut dirinya “atlet serial”
    • Masalahnya, begitu menerima pendanaan ventura, Anda terdorong ke arah ekspansi raksasa
      Jika tidak menerima pendanaan ventura, jalan menuju kondisi mandiri yang layak jauh lebih sulit dan lebih lama, kecuali Anda bisa mendanai sendiri lewat cara seperti konsultasi. Modelnya di sini adalah 37 Signals, tetapi mereka sangat pengecualian karena mereka perusahaan yang membuat Rails
      Dan meski Anda mencapai titik itu, pesaing yang didanai ventura bisa masuk dengan jaringan dan modal yang lebih baik lalu menginjak-injak Anda
    • Saya berada di Eropa dan bekerja di perusahaan yang mengalami kesulitan yang persis sama
      Siklus penjualan B2B ke perusahaan besar luar biasa panjang, sementara kisaran harga yang bisa dijual ke UKM tidak cukup tinggi
      Meski kami memberikan nilai dan menghemat waktu pelanggan, menjelaskan nilai itu selalu sulit
      Rumput tetangga memang selalu tampak lebih hijau, tetapi jika dalam bisnis B2B Anda harus mengulang penderitaan yang sama selama bertahun-tahun hanya untuk menjaga lampu tetap menyala, berbicara dengan pelanggan berbeda tentang hal yang mirip setiap bulan, dan menjelaskan hal yang sama 10 kali setahun tentang mengapa ini bernilai, saya mengerti mengapa orang tidak ingin terjebak di sana. Burnout juga bisa datang cepat
      Jadi saya juga paham keinginan untuk menemukan ide bisnis yang nilainya jelas dan membuat orang berteriak “ambil uang saya”
    • Ada beberapa faktor mengapa perusahaan-perusahaan Barat lebih menyukai ekspansi vertikal daripada horizontal
      Yang pertama adalah imbal hasil investasi. Jika Anda menarik uang orang lain, mereka tentu mengharapkan keuntungan, dan investor yang cerdas mendiversifikasi portofolio sehingga tahu banyak investasi akan gagal. Karena itu, untuk menutup kerugian, mereka menekan semua investasinya agar tumbuh sebesar mungkin, sehingga segelintir perusahaan berkinerja sangat tinggi menutupi kegagalan
      Pertumbuhan vertikal seperti ini terlihat bukan hanya di startup, tetapi juga di perusahaan besar. Menurut saya, formalisme, regulasi berlebihan, dan birokrasi berperan besar di sini. Jika Anda harus melewati banyak prosedur seperti perizinan, pajak, dan pengaturan akun penggajian, lalu harus melewati lebih banyak lagi prosedur untuk go public, memperluas cakupan aktivitas perusahaan yang sudah mapan bisa jauh lebih murah dan lebih rendah risikonya daripada memisahkan dan membuat perusahaan baru

  • Sepertinya dulu kami pesaing. Saya pendiri ReadMe.com, dan kami menyediakan dokumentasi API, SDK, dan sebagainya
    Saya tidak benar-benar tahu secara spesifik mengapa kami berhasil, tetapi saya juga mengalami banyak start yang salah dan terus mengiterasi ide inti sedikit demi sedikit sampai mencapai titik ketika orang-orang tampak benar-benar antusias
    Karena tahu pasar ini sulit, saya mencurahkan banyak waktu dan usaha untuk hal-hal non-engineering juga, dan terutama ketika kami tampil lebih jujur, Hacker News selalu bersikap ramah kepada kami
    Saya akan mencoba menghubungi secara pribadi karena ingin mendengar lebih banyak
    Secara keseluruhan, selamat atas semua upaya yang telah dicurahkan. Memulai perusahaan dan percaya pada diri sendiri adalah hal yang luar biasa sulit, dan Anda boleh merasa bangga

    • Alasan ReadMe lebih sukses daripada Konfig mungkin karena mulai 8 tahun lebih awal. Konfig adalah ide yang bagus dan eksekusinya juga baik, tetapi mungkin hanya waktunya yang tidak tepat
    • Mumpung sedang dibahas, efek transisi CSS di layar login ReadMe tetap menjadi salah satu elemen branding paling kuat yang saya ingat. Siapa pun yang memikirkannya, itu benar-benar hebat

  • Saya rasa kita akan sering melihat hasil seperti ini dalam waktu dekat. Hal serupa tampaknya akan berulang ketika gelembung AI pecah

    • Saya mungkin akan lebih menghargai upaya itu jika ditulis seperti ini
      “Kami melihat peluang untuk memanfaatkan AI generatif dalam produk SaaS B2B vertikal guna memecahkan masalah yang sebelumnya belum bisa diselesaikan, lalu mencobanya. Kami membuat dan menawarkan beberapa ide, tetapi respons pengguna tidak cukup positif untuk meyakinkan kami bahwa itu arah yang tepat untuk membangun bisnis besar.”
      Dalam bentuk aslinya, kesan pertama yang muncul adalah “orang yang menulis ini begitu tertanam dalam budaya tren sesaat dan sempit hingga secara naluriah terasa menjengkelkan, dan bahkan segera setelah gagal total pun secara psikologis belum bisa keluar dari sana”
    • Membuka kode sebagai open source lalu menyerah adalah pivot AI paling ultimat. Karena model-model baru akan mempelajari apa yang Anda lakukan dan suatu hari melakukannya lebih baik

  • Ini bukan cerita pertama tentang produk yang kurang pas lalu mencari arah pivot, menjadikan AI sebagai jawabannya, dan gagal
    Saya sudah pernah mengatakannya, tetapi layak diulangi. Jika kita memahami apa yang AI kuasai dan tidak kuasai, kita akan mulai memperlakukan AI sebagai alat, bukan tujuan, dan proses melahirkan ide produk pun akan lebih stabil

    • Kita sudah tahu. AI pandai mengarang sesuatu yang terdengar meyakinkan, tetapi lemah dalam menghasilkan keluaran yang tahan terhadap fakta atau verifikasi
    • Produknya sendiri cukup baik. Saya pernah berada di startup yang dengan senang hati membayar dan mendapatkan banyak nilai dari produk yang membuat SDK dari spesifikasi OpenAPI itu
      Jadi menurut saya masalahnya di sini bukan product-market fit
    • Maksudnya AI tidak bisa menyelamatkan ide produk yang buruk dengan mengotomatiskan sesuatu? Seperti, melakukan sesuatu yang tidak diinginkan siapa pun dengan lebih efisien itu bukan bisnis
    • Konsep API seharusnya menghilang, dan biarkan saja AI-AI saling berbicara dalam bahasa alami

  • Saya tidak begitu yakin harus melihat ini bagaimana. Di satu sisi, saya mengapresiasi introspeksinya, keberaniannya menghadapi kebenaran yang tidak nyaman, dan fakta bahwa mereka membuat rangkaian alat yang cukup luas
    Namun kalau melihat bagian dalamnya, ini adalah alat yang membungkus alat. Alat klasifikasi API tampaknya menyerahkan sebagian besar pekerjaan berat ke OpenAI
    “Anda adalah pengklasifikasi kelas dunia. Cocokkan API-API ini ke salah satu dari grup berikut.”
    Sisa berkasnya adalah kode penghubung, dengan batas model-view-controller yang agak kabur. Saya juga melihat adanya pengujian, dan berpikir itu memang penting untuk wrapping alat yang kemungkinan banyak berubah di luar kendali mereka, tetapi pada praktiknya hanya sebatas memastikan dependensi ada dan kompilasi tidak gagal, seperti pengujian fungsional contextLoads() bawaan IntelliJ
    Visinya ada dan juga selaras dengan hukum Pareto, tetapi saat mereka memvalidasi hipotesis bahwa pasar tidak tertarik memelihara milik mereka sendiri, rasanya secara internal mereka bahkan belum menyelesaikan masalah pemeliharaan mereka sendiri
    Kalau mereka bisa terlebih dahulu menyelesaikan alasan itu untuk diri sendiri, mereka mungkin bisa menyelesaikannya juga untuk orang lain. Namun untuk itu mereka perlu punya produk yang benar-benar dipakai agar bisa merasakan rasa sakitnya dan berempati dengan pengguna akhir—ini terlihat seperti sebuah dilema

  • Startup yang gagal bukanlah sesuatu yang memalukan. Kebanyakan dari kita bahkan tidak punya keberanian untuk mencoba
    Sulit mengharapkan orang sangat tertarik pada kodenya. Nilai kode sebuah perusahaan tanpa bisnis dan orang-orangnya, kecuali ada senjata rahasia teknis yang istimewa, cukup negatif
    Kalaupun ada bagian yang secara teknis hebat, orang kemungkinan hanya akan mencoba memahami bagaimana satu bagian itu bekerja, bukan memakai kodenya sendiri

    • Saya pendiri Konfig. Saya 100% setuju. Saya tidak akan merekomendasikan siapa pun untuk mendekripsi dan men-deploy Konfig sendiri
      Namun satu pelanggan berhasil men-deploy sendiri platform dokumentasi kami sambil mencari cara menangani dampak penutupan Konfig
    • Hal yang saya pelajari dengan susah payah setelah beberapa kali membuat startup yang makin lama makin tidak gagal adalah ini
      Jika tidak punya rencana bisnis yang bisa cepat menghasilkan pendapatan atau pendanaan investasi yang sangat besar, jangan membangun startup teknologi. Biasanya sulit mendapatkan investasi kalau tidak punya setidaknya firasat minimal tentang ke mana bisnis akan berjalan, dan para teknisi umumnya tidak cukup memahami sisi bisnis
      Kebanyakan perusahaan bukan startup, melainkan sekadar perusahaan. Perusahaan yang punya pendapatan dan membayar tagihan. Startup adalah perusahaan yang hidup dari waktu dan uang pinjaman tanpa pendapatan, dan terutama jika uang itu uang sendiri, dibutuhkan rencana
      Sebagian besar perusahaan yang menerima venture capital gagal. Tugas venture capital adalah membuat perusahaan yang akan gagal agar gagal dengan cepat, dan mempertahankan bisnis mereka lewat segelintir perusahaan yang tidak gagal dan sukses secara eksplosif. “Akselerasi” atau “penggalangan investasi” bukan berarti Anda berada di jalur sukses, melainkan Anda telah ditempatkan pada posisi di mana Anda harus mengalahkan probabilitas dan waktu yang tersisa tidak banyak
      Jika Anda perusahaan sukses yang punya pendapatan, Anda tidak membutuhkan venture capital. Kalau begitu, Anda perlu bertanya mengapa berbicara dengan mereka. Jika sulit menghasilkan pendapatan, venture capital tidak akan memperbaikinya
      Banyak venture capital malas dan baru tertarik setelah Anda sudah sukses. Karena itu muncul dinamika aneh: perusahaan yang mendapat investasi di tahap awal gagal, sementara perusahaan yang tidak mendapat investasi justru sukses
      Perusahaan saya saat ini sudah 4 tahun berjalan sepenuhnya bootstrap. Kami bergulat dengan pendapatan, menyelipkan pekerjaan di waktu yang memungkinkan, dan saya terutama hidup dari konsultasi sampingan. Perusahaan mencatat tahun tersuksesnya selama 3 tahun berturut-turut, dan kami sudah hampir sampai pada titik di mana saya bisa berhenti menjadi konsultan dan fokus pada bisnis, tetapi ini perjalanan yang panjang
      Untuk open source, saya membuka hal-hal yang bukan kode khusus bisnis atau kekayaan intelektual inti. Salah satu alasan besarnya adalah saya tidak ingin membuat ulang pekerjaan remeh yang sama saat memulai perusahaan berikutnya. Saya sudah merasakan bagaimana hal-hal semacam itu memperlambat
      Banyak orang di startup terobsesi pada kekayaan intelektual, tetapi secara realistis sebagian besar perangkat lunak tidak seberharga itu. Meski begitu, untuk membuatnya tetap butuh waktu, uang, dan energi
      Jadi saya membuka banyak alat dan framework yang pengguna utamanya adalah saya sendiri. Tujuannya agar bisa terus saya pakai di proyek berikutnya

  • Dump kode itu sendiri bisa menarik, tetapi sepertinya tidak ada lisensinya. Akan jauh lebih berguna jika diberi lisensi open source yang benar

    • Sekitar satu jam setelah komentar itu, berkas MIT LICENSE ditambahkan

  • Pasar alat developer benar-benar sulit
    Hampir setiap keputusan arsitektur menjadi “alat open source apa yang bisa dipakai untuk menyelesaikan masalah ini?”
    Tidak ada yang ingin membayar, dan itu tidak apa-apa

    • Memang begitu, tetapi kebanyakan developer hampir tidak menyadari masalah di luar masalah yang mereka alami sendiri, dan masalah-masalah itu biasanya adalah masalah alat developer
      Karena itu, meski ada kebutuhan sangat besar di bidang lain, banyak perusahaan justru membuat startup alat developer
      Jika ada cara bagi developer berpengalaman yang ingin memulai sesuatu untuk menemukan orang-orang yang punya masalah, keahlian domain, dan kemauan mendirikan perusahaan—selain lewat kebetulan dan networking—sepertinya banyak nilai bisa terbuka
    • Menjual alat kepada developer itu sulit. Anda harus bersaing dengan sangat banyak alat open source yang terus beradaptasi dan berubah, dan ide bagus cepat diserap serta ditiru
      Karena itu sebagian besar alat komersial punya umur manfaat yang terbatas, dan umumnya hanya berada di kategori nice-to-have
      Selain itu, banyak developer adalah karyawan dan tidak punya anggaran pribadi untuk alat. Pasarnya pada dasarnya menyempit ke developer freelance atau manajer yang mempekerjakan developer
      Manajer tim meneliti pengeluaran semacam ini dengan ketat dan biasanya anggarannya juga tidak besar. Di sebagian besar perusahaan, tidak ada yang namanya anggaran alat pribadi untuk developer
      Freelancer pun umumnya memakai alat yang digunakan perusahaan yang membayar mereka, dan itu kebanyakan alat gratis. Alat berbayar membuat penggunaan freelancer lebih rumit karena harus memikirkan lisensi kontraktor juga. Karena itu, demi menjaga semuanya sederhana, orang cenderung menghindari alat seperti itu
    • Lebih jauh lagi, alat developer itu sulit dengan cara yang mudah disalahpahami. Membuat alat developer mudah terlihat seperti formula kemenangan bagi perusahaan atau startup. Karena Anda sendiri developer, dan besar kemungkinan Anda menemukan masalah yang pernah Anda alami sendiri
      Anda juga tahu di mana para developer berkumpul dan apa yang efektif bagi mereka, jadi semuanya tampak baik-baik saja
      Namun seperti yang dikatakan, banyak developer tidak ingin membayar, dan akan mencari solusi open source yang melakukan hal yang dibutuhkan meskipun sedikit kurang nyaman. Selain itu, karena pihak yang Anda hadapi adalah orang-orang yang pekerjaan dan hidupnya membuat perangkat lunak, jawabannya bisa saja menjadi “ya sudah saya buat sendiri saja”
    • Itu tidak sepenuhnya benar. Hanya saja saya tidak ingin membuang waktu untuk mengurus 50 tagihan masing-masing 10 dolar
      Apakah tidak ada bisnis yang menggabungkan berbagai layanan menjadi satu tagihan? Atau apakah tetap harus memakai AWS, Azure, GCloud?