SaaS hanyalah "vendor lock-in" dengan branding yang lebih bagus

• Integrasi SaaS dikatakan memungkinkan developer fokus hanya pada produk, tetapi pada kenyataannya selalu ada 5 biaya tersembunyi (pajak) setiap kali mengadopsinya
• Pada setiap tahap sebelum adopsi—penemuan, pendaftaran, integrasi, pengembangan lokal, operasi—waktu, kompleksitas, dan beban mental terus muncul
• Jika memilih platform terintegrasi (Cloudflare, Supabase, dll.) alih-alih SaaS terpisah, biaya dan kompleksitas berulang ini bisa dikurangi secara signifikan
• Karena vendor lock-in adalah kenyataan yang tak terhindarkan, daripada mencampur banyak layanan, yang terbaik adalah menjaga alur (Flow) pengembangan dalam satu platform terintegrasi
• Pada akhirnya, yang paling penting bukanlah framework atau layanan itu sendiri, melainkan software yang ingin saya bangun

---

SaaS hanyalah vendor lock-in dengan branding yang lebih bagus

• Developer sering mendengar nasihat, “fokus saja pada pengembangan produk”, tetapi dalam praktiknya, saat mengadopsi vendor SaaS untuk hal seperti auth, queue, penyimpanan file, dan optimasi gambar, muncul berbagai beban tambahan
• Bukan hanya biaya uang, tetapi juga pemborosan waktu, friksi, dan kelelahan mental.

1. Pajak penemuan (Discovery Tax)

• Sebelum mengadopsi layanan SaaS, perlu ada proses untuk memahami fitur dan nilai yang benar-benar dijual
• Perlu mengevaluasi detail seperti cakupan pemecahan masalah, kompatibilitas dengan stack yang ada, harga yang masuk akal terhadap skala, kejelasan dokumentasi, dan pola implementasi yang tidak biasa
• Proses riset ini tidak mudah diwariskan dari pengalaman sebelumnya atau diulang begitu saja, dan sebagian besar bersifat subjektif
• Ada beban untuk menilai sendiri apakah pesan pemasaran tersebut cocok bagi saya dan apakah layanannya benar-benar membantu

2. Pajak pendaftaran (Sign-Up Tax)

• Setelah memilih layanan, Anda harus memberikan email dan informasi kartu
• Perlu dicek apakah penagihan berbasis penggunaan tersedia, atau hanya mendukung lock-in berbasis langganan
• Struktur harga yang tidak transparan menjadi masalah, misalnya ketika anggota tim dikenai biaya tambahan hanya untuk mengakses dashboard
• Perlu diperiksa apakah pengujian bisa dilakukan tanpa masa uji gratis, atau apakah pembayaran diminta sejak awal
• Bahkan sebelum menulis satu baris kode, hubungan kontraktual dengan vendor sudah terbentuk

3. Pajak integrasi (Integration Tax)

• Dalam proses adopsi yang sebenarnya, memeriksa dokumentasi, memasang library, menghubungkan framework, dan menyelesaikan masalah tambahan di luar dokumentasi adalah hal yang tak terelakkan
• Kita sering menghadapi konflik antar tool atau masalah tak terduga
• Ketika SaaS hanya menargetkan penyebut umum paling minimal, stack modern atau lingkungan yang lebih khusus memerlukan lebih banyak pekerjaan

4. Pajak pengembangan lokal (Local Development Tax)

• Tidak jelas apakah layanan SaaS mendukung environment lokal
• Perlu ada emulator lokal, atau setidaknya kemungkinan melakukan stub untuk tujuan pengujian
• Untuk memeriksa sebagian fitur, kadang dibutuhkan cloud tunneling dan sejenisnya, sehingga konfigurasi environment menjadi rumit
• Situasi di mana percabangan konfigurasi untuk production, staging, dan lokal menjadi tak terhindarkan pun muncul

5. Pajak production (Production Tax)

• Setelah layanan diintegrasikan, beban baru muncul di environment production
• Diperlukan pengelolaan tambahan seperti ketersediaan di staging dan environment PR preview, manajemen API key, monitoring dan logging, serta notifikasi
• Harus siap menghadapi error atau ketidaksesuaian yang tidak muncul di environment pengembangan, tetapi hanya terjadi di environment operasi nyata
• Tanggung jawab menjaga kestabilan layanan pada akhirnya dibebankan kembali ke developer

Kesimpulan

• Slogan SaaS modern adalah "jangan menemukan ulang roda", tetapi setiap penambahan layanan selalu disertai friksi
• Mengadopsi layanan bukan sekadar integrasi, melainkan kontrak yang disertai peningkatan dependensi dan perubahan arsitektur. Vendor lock-in tidak terhindarkan, dan saat mengganti layanan, beban penulisan ulang kode bisa sangat besar.

• Karena itu, alih-alih mengulang keputusan seperti ini terus-menerus, lebih efisien memilih platform all-in-one sejak awal
• Yang penting adalah software yang benar-benar ingin dibangun developer
• Platform terintegrasi seperti Cloudflare, Supabase menyediakan database, queue, image, dan storage dalam environment yang sama, sehingga sangat mengurangi beban pajak yang disebutkan di atas.
  • Tidak perlu berpindah-pindah konteks antar banyak vendor
  • Frekuensi masalah terkait pengelolaan API key berkurang
  • Kebutuhan mengelola kompatibilitas dan percabangan per environment menjadi minimal
  • Memberikan pengalaman integrasi yang konsisten di environment pengembangan maupun production
• Platform seperti ini memberi kesan seolah semuanya berjalan di mesin yang sama, meminimalkan jarak antara kode dan layanan, sehingga mengembalikan rasa tenggelam dalam pengembangan ("Flow") yang tidak bisa diberikan SaaS mana pun.

Yang penting bukan memilih framework atau layanan, melainkan menjaga software yang ingin saya bangun dan alur (Flow) saya

[galadbran]

Supabase sering dijadikan contoh yang baik, jadi layanan SaaS seperti apa yang sebaiknya dihindari?

[GN⁺]

Opini Hacker News

• Ini adalah pandangan yang melihat "rent seeking" ala Adam Smith sebagai versi modern yang diperluas secara besar-besaran
  Menurut saya, perilaku ekonomi seperti ini merugikan masyarakat sehingga sebaiknya dihindari dan bahkan dikriminalisasi
  Di sisi lain, ekstrem perangkat lunak gratis juga bermasalah secara ekonomi, karena upaya pembuat perangkat lunak tidak bisa sebanding dengan nilai yang diperoleh pengguna
  Saya berpendapat bahwa pembelian perangkat lunak dan kontrak layanan terpisah harus dibedakan, karena masing-masing benar-benar memberikan nilai yang berbeda
  Masalah pada SaaS adalah semua itu dibundel jadi satu, sehingga pada praktiknya pengemasannya menjadi terlalu ganjil dibanding layanan itu sendiri

  • Kalau saya sebegitu bersemangat, argumennya adalah saya seharusnya membangun sendiri SaaS tersebut lalu mendirikan perusahaan yang menyediakan deployment dan operasi on-premise dengan harga mirip SaaS saat ini
    Jika perusahaan bisa mempertahankan kendali atas data dan mencegah vendor lock-in sambil tetap menawarkan kualitas, jaminan, dan harga yang sama dengan SaaS, maka mereka bisa menguasai pasar

  • Saya selalu memikirkan ini: bukankah cukup dengan hanya menyediakan binary agar pengguna bisa menjalankannya di AWS, GCP, atau Cloudflare Workers?
    Dari sudut pandang saya, saas menarik sebagai pengembang tetapi tidak saya sukai sebagai konsumen, jadi saya terjebak dalam dilema etis
    Jika saya menjual perangkat lunak, bagaimana kalau pengguna mendistribusikannya ulang tanpa izin? Saya tidak bisa mengendalikan distribusinya seperti pada SaaS
    Saya pendukung foss (open source), tetapi seperti yang Anda katakan, pendekatan ini juga bermasalah secara ekonomi
    Saya juga memikirkan model seperti penerbitan lisensi lewat GitHub Sponsors, dan untuk beberapa proyek mempertimbangkan model autentikasi memakai SSPL, atau beralih ke BSD/MIT jika membeli lisensi (mirip Redis lama)
    Namun saya ragu apakah orang benar-benar akan membeli jika model seperti ini diterapkan, dan meski saya juga mempertimbangkan mendukung kedua pendekatan, saya belum menemukan jawaban yang jelas dan ingin meminta saran
    Sebagai referensi, proyek yang saya buat antara lain alat untuk membuat cryptocurrency gratis bagi siapa pun, fitur mengambil blog dari YouTube, dan penyimpanan tanpa batas yang memakai komunitas dan video YouTube sebagai pengganti Google Photos, serta saya juga memikirkan peningkatan privasi. Jika ada ide monetisasi, saya ingin mendengarnya

  • Disebutkan bahwa sebagian besar SaaS memiliki biaya berkelanjutan dari sisi penyedia, seperti hosting, support, dan R&D
    Sulit bagi saya untuk sepenuhnya memahami logika mengapa struktur seperti ini disebut "rent seeking"

  • Tidak semua SaaS bisa dianggap rent seeking, dan ditunjukkan bahwa "stickiness" perangkat lunak itu sendiri pada dasarnya mirip dengan rent-seeking
    Kebanyakan perusahaan SaaS memang mengejar stickiness, tetapi itu bukan sifat yang unik milik SaaS

  • Saya berada di posisi menjual produk SaaS saya kepada pelanggan yang ingin membelinya di pasar dengan harga yang masuk akal

• Vendor lock-in biasanya terasa ketika di internal perusahaan ada pertanyaan, "kenapa kita tidak mengadopsi alat NEWTHING?" lalu jawabannya adalah kita sudah terikat kontrak jangka panjang 5 tahun dengan Oracle, MS, IBM, atau Salesforce, jadi tidak ada pilihan
  Akibatnya, sekitar 10 tahun kemudian Anda benar-benar terikat penuh pada vendor itu, dan terbentuk situasi di mana Anda tak bisa lagi berpindah

  • Jika bisnis bisa bertahan sampai 10 tahun, itu justru bisa dianggap berkah atau masalah yang membosankan, tetapi saya ingin memberi saran agar di tahap awal startup jangan menghabiskan waktu memilih terlalu banyak alat, melainkan cepat pilih satu platform dan fokus

  • Bahkan dalam kasus seperti ini, ada pandangan bahwa sebaiknya layanan diabstraksikan dengan antarmuka yang terstandarisasi
    Jika sudah diabstraksikan, nanti saat berpindah ke layanan lain cukup sediakan implementasi alternatif
    Pendekatan ini memang berorientasi masa depan, tetapi ditunjukkan bahwa banyak perusahaan sekarang belum siap sampai ke tahap itu

• Menurut saya, meminimalkan dependensi adalah salah satu faktor terpenting untuk meningkatkan keberlanjutan produk dan bisnis
  Di tempat kerja saya sebelumnya, saya bertanggung jawab mengintegrasikan pengalaman tanda tangan elektronik ala DocuSign ke dalam produk kami
  Kami berdiskusi dengan vendor besar seperti DocuSign dan Adobe, tetapi saya merasa banyak keterbatasan API yang tidak cocok dengan kebutuhan produk dan pelanggan, sehingga akhirnya kami memutuskan untuk membangunnya sendiri secara internal
  Biasanya membuat sendiri alat seperti DocuSign adalah langkah yang buruk, tetapi produk kami sudah memiliki kepercayaan pelanggan sehingga hambatan adopsinya rendah
  Dalam proses membangunnya sendiri, pada awalnya memang banyak pekerjaan, tetapi ketika perlu melakukan penyesuaian kecil yang benar-benar spesifik untuk pelanggan, kami bisa merespons dengan cepat, dan dari sudut pandang bahwa kalau memakai vendor perubahan itu akan menjadi proyek besar yang jauh lebih merepotkan, keputusan membangun sendiri adalah pilihan yang tepat

• Saya memahami bahwa penulis berargumen bahwa SaaS adalah vendor lock-in sehingga sebaiknya tidak dibeli
  Namun justru dalam isi tulisannya dia menyarankan untuk all-in pada platform tertentu yaitu Cloudflare
  Pada akhirnya, pilihan apa pun menjadi lock-in, dan bahkan open source atau self-hosting pun kalau diganti tetap harus menulis ulang banyak kode
  Menggunakan fitur yang bergantung pada vendor tidak sama dengan "lock-in yang sesungguhnya", dan lock-in terjadi ketika biaya serta waktu untuk berpindah justru lebih besar daripada mempertahankan cara yang ada
  Jika perangkat lunak dibuat loosely coupled dan cohesive, mengganti bagian tertentu akan lebih mudah
  Karena jika antarmukanya sederhana, penggantiannya juga mudah
  Karena itu, pilihan "semua tetap lock-in, jadi sekalian saja terikat lebih kuat pada satu platform" mungkin nyaman bagi pengembang, tetapi merupakan strategi yang buruk dari sudut pandang manajemen, dan perusahaan harus berfokus pada fleksibilitas serta kemampuan untuk berubah

  • Dari sudut pandang pebisnis, kita harus memilih solusi yang memberi perusahaan fleksibilitas dan kemampuan berubah, dan menurut saya itulah mengapa terikat ke SaaS tanpa alternatif adalah tindakan yang bodoh
    Pada tahap awal atau saat belum ada pendapatan, memakai platform lebih menguntungkan daripada SaaS, dan ketika bisnis tumbuh lalu memasuki tahap ekspansi, barulah masuk akal memikirkan perubahan teknologi jangka panjang

  • Saya sering memakai Cloudflare Workers, dan saya juga menulis kode agar bisa dipindahkan ke mana saja
    Dengan wrangler dev, bisa dijalankan secara lokal, dan dalam praktiknya juga dapat berjalan di pure node/bun/deno tanpa banyak perubahan

• Inti OP (penulis) bukan menentang SaaS itu sendiri (toh pada akhirnya dia merekomendasikan solusi as a service seperti Cloudflare atau Supabase), melainkan menyoroti biaya operasional dan beban pengelolaan hubungan yang muncul ketika harus menandatangani dan mengelola terlalu banyak penyedia
  Semakin sedikit jumlah vendor dan semakin sedikit dependensi, semakin mudah operasionalnya
  Memang membayangkan semua fungsi diimplementasikan hanya dengan standard library terlalu idealistis, tetapi secara realistis itu sangat sulit

  • Anda merangkum maksud saya dengan tepat, dan benar juga bahwa saya menuliskannya secara provokatif di judul
    Intinya adalah usulan untuk mencoba memakai satu platform daripada mencampur banyak layanan sejak awal
    Alasan saya menyukai Cloudflare adalah karena binding-nya distandardisasi seperti fetch, dan fetch terasa seperti Unix pipe di dunia web

• Ada pandangan bahwa ironis jika demi menghindari vendor lock-in, seseorang justru all-in ke satu platform dan mengikat dirinya lebih parah ke satu perusahaan

  • Argumennya adalah kalau Anda tidak suka platform karena lock-in tetapi tetap memakai SaaS, maka itu tidak konsisten secara logis
    Karena SaaS juga punya biaya penyebaran ("pajak")

• Justru diskusi ini terlihat lebih dekat ke pembelaan open source
  Dengan pendekatan open source dan self-host, sebagian besar "pajak" yang disebutkan dalam tulisan (biaya penemuan, pendaftaran, integrasi, dan pengembangan lokal) dapat dihilangkan
  Saya pikir production tax pada open source bisa diatasi lewat ekosistem yang aktif, plugin, dan ekosistem modul

  • Ditunjukkan bahwa open source pada akhirnya tetap membutuhkan banyak waktu untuk dikelola dan dikembangkan sendiri, jadi jika biaya waktu ikut diperhitungkan, itu juga tidak gratis

• (Diibaratkan seperti perbedaan antara agama dan kultus) jika data bisa diekspor lalu dibawa pergi dalam format standar, maka itu bukan vendor lock-in
  Disebutkan juga adanya kekhawatiran bahwa pelanggan akan merasa tidak terlalu dirugikan jika mereka bisa mendapatkan data mereka sendiri, tetapi terlalu banyak layanan SaaS yang membuat hal itu mustahil

  • Sebagai orang yang sedang mencoba memonetisasi side project, saya bingung lisensi dan model distribusi seperti apa yang harus saya pilih
    1. open source sepenuhnya permisif seperti MIT
    2. open source dengan batasan seperti AGPL/SSPL
    3. source dibuka tetapi diubah ke lisensi permisif hanya jika membayar (dengan kebijakan lisensi yang dinyatakan eksplisit sejak awal)
    4. menjual binary tanpa membuka source
    5. mengikuti salah satu pendekatan di atas tetapi secara default menyediakannya sebagai SaaS, sambil juga mendukung struktur agar pelanggan bisa pergi dengan mudah
       Saat ini saya kebanyakan merilis dan mendistribusikannya dengan MIT, lalu menjaga hal-hal penting tetap tertutup

• Keterbatasan SaaS adalah pelanggan tidak bisa menikmati manfaat dari "biaya marjinal yang nyaris nol" pada perangkat lunak
  Penyedia SaaS memang menurunkan harga sampai tingkat tertentu dengan mencerminkan keuntungan itu, tetapi ketika jumlah pengguna sudah cukup besar dan harga satuannya tinggi, pada akhirnya pengguna SaaS dirugikan
  Namun di tahap awal startup, membangun sendiri adalah pilihan nekat, dan pada tahap "bertahan hidup" serta "meminimalkan biaya awal", SaaS adalah strategi yang sangat masuk akal
  Baru setelah bisnis tumbuh dan SaaS tertanam dalam keseharian, masalah lock-in, migrasi, dan biaya perpindahan mulai muncul
  Saya pikir masalah SaaS pada akhirnya hanyalah efek samping dari keberhasilan

• Itulah sebabnya model SaaS seperti ini sangat banyak
  Model bisnis dengan pendapatan berulang seperti anuitas, sekaligus memiliki kekuatan penetapan harga, sangatlah menarik