Kapan Pilih PRD Mode Web GAS (Apps Script) Dibanding Web SaaS Biasa?

Waktu bikin PRD baru di Skematik, kamu ketemu pilihan tipe proyek: Web SaaS, Mobile App, Marketplace, E-commerce, Internal Tool, Web GAS, sampai Landing Page. Kebanyakan orang refleks pilih Web SaaS karena itu yang paling familiar didengar. Padahal buat sejumlah kasus, terutama aplikasi internal skala kecil, Web GAS alias Apps Script justru pilihan yang lebih murah dan lebih cepat kelar, asalkan aplikasimu memang cocok masuk kategori itu.

Artikel ini bukan bilang satu tipe lebih unggul dari yang lain. Ini panduan milih: kapan Web GAS pas, kapan sebaiknya kamu tetap di Web SaaS biasa, dan kenapa PRD dari dua tipe ini isinya beda bukan cuma soal platform.

Pilih Web GAS kalau

Empat tanda ini biasanya nunjukin aplikasimu cocok jadi proyek Web GAS.

• Aplikasinya internal dan skalanya kecil sampai menengah, dipakai tim sendiri atau UMKM, bukan produk yang dijual ke publik luas
• Datanya cukup ditaruh di Google Sheets, ratusan sampai beberapa ribu baris, bukan jutaan baris dengan relasi rumit antar tabel
• Kamu nggak mau, atau nggak perlu, bayar hosting server terpisah, modal akun Google yang udah ada aja cukup
• Tim udah familiar Google Workspace, jadi nggak ada kurva belajar tambahan buat yang pakai

Contoh konkret yang biasanya pas: absensi karyawan dari HP, kasir toko kecil, form pengajuan cuti dengan approval atasan, dashboard rekap penjualan tim sales, atau sistem antrian sederhana. Semuanya punya pola yang sama. Datanya nggak sebesar e-commerce nasional, penggunanya terbatas, dan yang penting cepat jalan tanpa drama hosting.

Satu cara cepat mengecek: kalau kamu bisa membayangkan datamu muat rapi di beberapa tab Spreadsheet, dan yang pakai aplikasinya bisa dihitung dengan jari sampai puluhan orang, itu sinyal kuat Web GAS bakal cukup. Kalau kamu mulai butuh tabel relasi berlapis atau ribuan pengguna aktif tiap hari, itu sinyal buat mikir ulang.

Jangan pilih Web GAS kalau

Sebaliknya, ada tiga sinyal yang berarti kamu sebaiknya lari ke Web SaaS biasa atau tipe lain yang lebih cocok.

• Butuh performa tinggi atau data sangat besar, karena Apps Script punya kuota harian dan batas eksekusi sekitar 6 menit per run di akun gratis, jadi proses berat bakal kena stop paksa
• Butuh aplikasi mobile native, karena GAS cuma bisa nyajiin web app yang dibuka lewat browser, bukan app yang di-install dari App Store atau Play Store
• Butuh skalabilitas ke ribuan pengguna bersamaan, karena Spreadsheet nggak dirancang buat concurrent write sebanyak itu, walau sudah dibungkus LockService sekalipun

Kalau kamu ragu soal batas 6 menit dan kuota ini, rinciannya plus cara menyiasati tiap batas ada di panduan batas kuota Google Apps Script. Baca itu dulu sebelum mutusin, karena sebagian batasan bisa disiasati dan sebagian lagi memang keras.

Ongkosnya juga beda arah. Web GAS nggak ada tagihan hosting bulanan, tapi kamu "membayar" dengan batasan platform. Web SaaS biasa punya tagihan server, tapi hampir nggak ada plafon performa yang mendadak menghentikan proses di tengah jalan. Bukan soal mana yang lebih murah secara mutlak, tapi ongkos mana yang lebih masuk akal buat kasusmu.

Kenapa PRD-nya beda, bukan cuma platformnya

Ini yang sering dilewatkan. Milih Web GAS bukan cuma soal nanti kodenya pakai Apps Script, tapi PRD-nya sendiri mengunci konvensi yang berbeda dari PRD SaaS biasa. Kalau ini nggak dikunci di level PRD, kamu bakal dapat agent yang ngoding Web GAS dengan insting SaaS, dan hasilnya kode yang kelihatan benar di atas kertas tapi error terus begitu dicoba di Apps Script beneran. Di Skematik, milih tipe proyek Web GAS otomatis mengunci tiga konvensi ini ke PRD-mu.

• Baca-tulis Spreadsheet borongan, bukan per-sel: ambil seluruh rentang data sekali jalan, olah di memori, baru tulis balik sekali, bukan looping baris demi baris yang lambat dan boros kuota
• LockService buat cegah tabrakan tulis simultan: Spreadsheet nggak punya transaksi bawaan kayak database sungguhan, jadi tiap penulisan wajib antre lewat lock
• google.script.run menjembatani client dan server, bukan fetch(): di Apps Script kamu nggak bikin endpoint REST, browser manggil fungsi server langsung

Bandingkan dua potongan berikut. Yang pertama gaya SaaS biasa, yang kedua gaya Web GAS.

// Web SaaS biasa (client fetch ke REST API)
fetch('/api/pesanan', {
  method: 'POST',
  body: JSON.stringify(data),
})
  .then((res) => res.json())
  .then(tampilkanHasil)
  .catch(tampilkanError);

// Web GAS (client manggil fungsi server langsung, bukan fetch)
google.script.run
  .withSuccessHandler(tampilkanHasil)
  .withFailureHandler(tampilkanError)
  .simpanPesanan(data);

Kalau PRD-mu nggak nyebutin ini dari awal, agent yang ngoding proyek GAS bisa aja refleks nulis fetch ke endpoint /api seperti kebiasaan bikin SaaS pada umumnya, dan itu nggak akan jalan di Apps Script.

Belum pernah pegang Apps Script sama sekali?

Wajar kalau istilah kayak doGet, LockService, atau google.script.run masih asing kalau kamu baru mau coba Web GAS. Mulai dari pengantar Apps Script untuk pemula biar konsep dasarnya kebayang duluan, lalu lanjut ke batas kuota Google Apps Script biar kamu tahu batasan mana yang beneran jadi masalah buat aplikasimu, bukan cuma cerita samar-samar.

Nggak ada tipe proyek yang salah di sini, cuma ada yang cocok dan yang kepaksaan. Pilih Web GAS kalau empat tanda tadi kena, dan biarkan PRD-nya mengunci konvensi yang benar sejak awal, bukan ditambal setelah agent-mu kadung nulis fetch ke API yang nggak pernah ada.