Show HN: Using Google Sheets as the back end/APIs of your app

Original Article ↗ Hacker News Discussion ↗

Product concept & use cases

  • Service exposes Google Sheets as CRUD APIs so non-devs can manage data while apps consume it.
  • Many see this as great for scrappy MVPs, internal tools, small teams, and prototypes (menus, vocab content, community membership, dashboards, etc.).
  • Some like Sheets more as the front end (UI) with a real backend behind it.

API limits, reliability, and performance

  • Confusion over Google Sheets limits; one commenter cites 60 writes/min, product creator reports 300 reads and writes/min and says this can be raised.
  • Several report Sheets API being unreliable at scale: sporadic 429/503/internal errors, days with 30–40% failures, multi‑minute response times.
  • Others say Sheets works fine for light/medium scale, but becomes painful with large data or heavy polling.

Caching and architectural patterns

  • Many recommend aggressive caching (Redis, in‑memory, SQLite, S3) to avoid rate limits and latency.
  • Suggestions to use “share as CSV” for reads, which is heavily cached.
  • Some propose Apps Script triggers (onEdit) to maintain caches or outbox sheets, but note limited APIs for automatically installing this and distaste for mutating user sheets.

Security, auth, and policy constraints

  • Product currently requests broad scope: see/edit/create/delete all spreadsheets, which worries people; advice is to use a dedicated Google account.
  • Some organizations block Docker, Redis, or custom servers entirely, making Sheets more attractive despite its flaws.
  • Others question putting sensitive business data into Google Sheets/public cloud.

Comparison to alternatives

  • Many mention existing tools: PocketBase, Airtable, Notion, AppSheet, Glide, opensheet, Sheety, SpreadAPI, BaseQL, Baserow, NocoDB, Budibase, etc.
  • View that once you’re “willing to pay” and need reliability/scale, you typically outgrow Sheets and move to proper databases.

Product feedback (UX, docs, and marketing)

  • Multiple people report SSL issues on the bare domain and invalid certificates.
  • Pricing is absent/unclear, causing hesitation.
  • Docs are seen as minimal; API responses are just JSON dumps with little customization.
  • Some skepticism about big-brand logos and “developers all over the world” language.