I put Google Sheets as a backend (in production) when i wanted a select non technical people to be able to see and modify the data without the cost of building a backend.
I really wish auth was easier to setup for services though, i see no reason google can't provide this out of the box
I meant to authenticate a service (that is not running on GCP) to access the sheet, it requires a service account and felt more convoluted than what it needs to be
Completely agree. Managing service account JSON keys and configuring IAM roles just to access a single sheet feels like a huge overhead for simple projects.
Don’t really get the purpose for this apart from throw away projects.
For vibe coders is it really “hours” setting up a database these days? GCP cloud sql + drizzle ORM is minutes and actually scales unlike a spreadsheet, heck Claude can even write you a deployment script and run it over GCP CLI.
Which works out at $100 USD / year. You might think that's trivial, but when you start provisioning multiple environments over multiple projects it starts to add up.
It's a shame that Google haven't managed to come up with a scale to zero option or serverless alternative that's compatible.
Sheet Ninja is 108 USD / year and has tiny capacities for every metric. SQLite is free and would stomp this in every aspect on low budget hosting. Even a tiny API that stores CSV would be magnitudes more efficient.
But what would scare me the most, is that google can easily shut this thing down.
setup a DB project , use same cloud sql instance for all DBs. Did that for years on non prod or experimental projects.
$100 is a bargain for what you get in terms of resiliency
It is trivial to set up a database on GCP given that you know what you are doing and I would pay Google for that stability and support for setting up multi-tenancy and region.
Using Google spreadsheets as a backend will just cause them to charge everyone later.
Sheet Ninja isn't free. Even on their side, "free" does not mean what you think it means.
Unless things have improved it's also hideously slow, like trivial queries on a small table taking tens of milliseconds. Though I guess that if the alternative is google sheets that's not really a concern.
I like this idea, I wrote a tiny CRM-like thing for my mom a month or so ago (upgrade from a google sheet that I had previously upgraded from an Apple Note) and it uses Sheets as it's backend. She can always go back to the Sheet and lose nothing but the web interface she uses it tailored to exactly what she needs. I couldn't be happier with it and she loves it.
I'll have to remember this for my next little one-off tool.
> When things scale, SQLite will still be fine, will fit 99% of the vibe coders needs!
No it won't. SQLite is a poor choice at handling this, period. With all those hacks it still doesn't make any sense over something like PostgresSQL which is designed for that use case.
Yet another reason why I dismiss this nonsense of vibe coding.
I accept what you say, my point is for 99% of vibe coded and vibe coders stuff you have no reason to spin up anything more than sqlite, if you grow migrate to postgres, you will have drizzle help you!
A single vps like 1-2 GB ram and 2 CPU can suffice 100s of your projects
SQLite can handle 100s of users easyily
And 99% of vibe coded projects won't grow further than 100s of concurrent users
Nice execution on the Google Sheets as backend angle — it's a much lower friction onboarding story than "set up a database." How are you handling concurrent writes when multiple users edit the sheet at the same time?
Thanks and great question - appends are atomic via Google's Sheet API, but updates/deletes are currently positional based on row ID. It's 'last-write-wins' for now if there are multiple concurrent updates.
Hi all - a friend and I have been dabbling in the entrepreneur space for years, but we never really pulled the trigger because of our corporate jobs. We suffer from the same thing that plagues a lot of engineers: we know how to build products, but we are weak at distribution and marketing.
We feel that being able to build is becoming table stakes and the ability to actually get a product into people's hands is more important than ever. We built SheetNinja (https://sheetninja.io) to force ourselves to learn that side of the business from the ground up.
We chose a validated market (sheets-to-api) so we could focus on the "how to find users" problem rather than wondering if the category was useful. It also fits our current "vibe coding" workflow i.e. when we use LLMs or Replit to spin up an idea, a Google Sheet is often the fastest way to handle CRUD without the friction of setting up a traditional database.
We are looking for feedback on the tool itself and the landing page. We have a lot of visitors but a lower sign-up rate atm.
The "we chose a validated market so we could focus on learning distribution" framing is really smart and honestly something I wish I'd done earlier. I'm building a workspace/collaboration tool and spent way too long on the product side before realizing the distribution muscle is a completely separate skill that doesn't develop on its own.
One thing I've noticed from the sheets-as-backend pattern: the reason people
keep reaching for spreadsheets is because the editing UX is instant and familiar.Any tool that wants to replace this for non-technical users needs to nail that "just click a cell and type" experience. That's the hard part honestly.
One feature suggestion: webhook support for row changes:
If my Sheet updates (say, a new waitlist signup), I'd want to trigger for e.g. a Slack notification. Supabase has something similar with their database webhooks. I use that extensively for kicking off signup workflows.
You can do this now directly in the Google environment. Should be trivial to vibe code Google Apps Script to hit a Slack endpoint. You'd probably use an 'on edit' trigger to run the code.
For your signup workflows, how sensitive would you be to latency? Would a 30 to 60 second delay be a dealbreaker, or are you looking for something that hits Slack the instant the row is created?
(The challenge with Google Sheets is we'd have to poll for changes)
I think it can be one option to achieve a tiny goal.
Some companies often think that using AWS or GCP is too much of a stretch for a minimum target.
So, it can be a good way to meet their request.
This site is pretty broken. The project seems cool but I’d recommend a more static landing page. I bounced very quickly. Didn’t even make it to the bottom with all the distracting animations.
I have done this for my own projects for years it’s great for projects that are only for me and gives me a very good db editor also. Cool project though the only risk I see is that if the target audience are vibe coders they will you known just vibe code an integration
Thank you! The idea of our target audience just vibe coding this themselves definitely gave us pause for thought while we were building it :)
We're thinking of playing around with the pricing right now to make sure it is cheaper to just use this than to spend the time and tokens recreating the logic. We will see how it plays out.
You do not need to go through these guys Google provides access to the URL to use the sheet as a database and also allows you to deploy Javascript and even host the site with AppScript (example https://script.google.com/macros/s/AKfycbzYt_aXBdQlnMM7idlVD... )
Good project but I wish something like this can exist for proton mail, I have made some puppeteer scripts which can hook up to proton docs.
But Proton is really doing some great disservice to not having a public api for their docs.
I can imagine it being used for anonymous comments page for webpages etc.
I am not sure if there is something that you can do about it though given that the fundamental issue of this is caused by proton not having an api whereas I think google docs does have API.
I put Google Sheets as a backend (in production) when i wanted a select non technical people to be able to see and modify the data without the cost of building a backend.
I really wish auth was easier to setup for services though, i see no reason google can't provide this out of the box
You can auth with Google auth after you configure an app, what are you thinking of that would be simpler?
I meant to authenticate a service (that is not running on GCP) to access the sheet, it requires a service account and felt more convoluted than what it needs to be
Completely agree. Managing service account JSON keys and configuring IAM roles just to access a single sheet feels like a huge overhead for simple projects.
Don’t really get the purpose for this apart from throw away projects.
For vibe coders is it really “hours” setting up a database these days? GCP cloud sql + drizzle ORM is minutes and actually scales unlike a spreadsheet, heck Claude can even write you a deployment script and run it over GCP CLI.
Don't do this guy, cloudsql costs a lot.
Cloud SQL costs gazillions, sheet is free (other than selling your data)
>sheet is free (other than selling your data)
Except the sheets-to-api SaaS charges $9/month if you want more than 250 requests.
Cloud sql lowest tier is pennies a day, this ninja platform is also not free.
A spreadsheet is a misclick away from corruption, why not spend another prompt on getting Claude to configure a db?
Which works out at $100 USD / year. You might think that's trivial, but when you start provisioning multiple environments over multiple projects it starts to add up.
It's a shame that Google haven't managed to come up with a scale to zero option or serverless alternative that's compatible.
Sheet Ninja is 108 USD / year and has tiny capacities for every metric. SQLite is free and would stomp this in every aspect on low budget hosting. Even a tiny API that stores CSV would be magnitudes more efficient.
But what would scare me the most, is that google can easily shut this thing down.
setup a DB project , use same cloud sql instance for all DBs. Did that for years on non prod or experimental projects. $100 is a bargain for what you get in terms of resiliency
It is trivial to set up a database on GCP given that you know what you are doing and I would pay Google for that stability and support for setting up multi-tenancy and region.
Using Google spreadsheets as a backend will just cause them to charge everyone later.
Sheet Ninja isn't free. Even on their side, "free" does not mean what you think it means.
> Cloud sql lowest tier is pennies a day
Unless things have improved it's also hideously slow, like trivial queries on a small table taking tens of milliseconds. Though I guess that if the alternative is google sheets that's not really a concern.
Most are lucky to get a few sign ups.
> Cloud SQL costs gazillions,
WTF is "Cloud SQL"?
I have a postgresql server running on a $5/m VPS that I add DBs to as and when I explore some new idea.
Google have you covered: https://www.youtube.com/watch?v=Kl8ig2BtLAY
You can fire up a burstable postgres for about $20/mo
SQLite is enough for 98% of all of these use cases, and 100% of the ones this would appeal to
This is a great project, very cool, but it is actually insane to me that CRUD is so apparently hard that Google Sheets is the best solution
The attractiveness of a spreadsheet comes in the display and the charts, etc.
For a serious database doing actual transactions, I'm not sure about the utility.
What's old is new again: Filemaker Pro
I like this idea, I wrote a tiny CRM-like thing for my mom a month or so ago (upgrade from a google sheet that I had previously upgraded from an Apple Note) and it uses Sheets as it's backend. She can always go back to the Sheet and lose nothing but the web interface she uses it tailored to exactly what she needs. I couldn't be happier with it and she loves it.
I'll have to remember this for my next little one-off tool.
Afaik Google Sheets comes with REST API endpoints by default.
How is this different?
Which scenarios do and which DO NOT require Sheet Ninja?
Version-controllable, plaintext knowledge bases have a durability advantage that no SaaS tool can match. Your notes will outlive any company.
SQLite, SQLite + drizzle with WAL mode, push it to a VPS, do not waste your time on anything else :)
Thank me when things become super easy!
When things scale, SQLite will still be fine, will fit 99% of the vibe coders needs!
When they don't then migrate to what ever!
This requires technical skill
If Claude can do it reasonably well then there’s another tier of technical skill that can reach.
> When things scale, SQLite will still be fine, will fit 99% of the vibe coders needs!
No it won't. SQLite is a poor choice at handling this, period. With all those hacks it still doesn't make any sense over something like PostgresSQL which is designed for that use case.
Yet another reason why I dismiss this nonsense of vibe coding.
I accept what you say, my point is for 99% of vibe coded and vibe coders stuff you have no reason to spin up anything more than sqlite, if you grow migrate to postgres, you will have drizzle help you!
A single vps like 1-2 GB ram and 2 CPU can suffice 100s of your projects
SQLite can handle 100s of users easyily
And 99% of vibe coded projects won't grow further than 100s of concurrent users
Nice execution on the Google Sheets as backend angle — it's a much lower friction onboarding story than "set up a database." How are you handling concurrent writes when multiple users edit the sheet at the same time?
Thanks and great question - appends are atomic via Google's Sheet API, but updates/deletes are currently positional based on row ID. It's 'last-write-wins' for now if there are multiple concurrent updates.
Hi all - a friend and I have been dabbling in the entrepreneur space for years, but we never really pulled the trigger because of our corporate jobs. We suffer from the same thing that plagues a lot of engineers: we know how to build products, but we are weak at distribution and marketing.
We feel that being able to build is becoming table stakes and the ability to actually get a product into people's hands is more important than ever. We built SheetNinja (https://sheetninja.io) to force ourselves to learn that side of the business from the ground up.
We chose a validated market (sheets-to-api) so we could focus on the "how to find users" problem rather than wondering if the category was useful. It also fits our current "vibe coding" workflow i.e. when we use LLMs or Replit to spin up an idea, a Google Sheet is often the fastest way to handle CRUD without the friction of setting up a traditional database.
We are looking for feedback on the tool itself and the landing page. We have a lot of visitors but a lower sign-up rate atm.
Thanks, in advance!
https://sheetninja.io
The "we chose a validated market so we could focus on learning distribution" framing is really smart and honestly something I wish I'd done earlier. I'm building a workspace/collaboration tool and spent way too long on the product side before realizing the distribution muscle is a completely separate skill that doesn't develop on its own.
One thing I've noticed from the sheets-as-backend pattern: the reason people keep reaching for spreadsheets is because the editing UX is instant and familiar.Any tool that wants to replace this for non-technical users needs to nail that "just click a cell and type" experience. That's the hard part honestly.
Please share the repo for the API and we will happily provide technical feedback.
I'm not sure I see why this needs to be a paid service. Unless I understand incorrectly, you can get the same result for free, self contained, with freely available code like this: https://gist.github.com/richardblondet/ce87a397ef669d4d25dd2...
Really good project for a quick data back end.
One feature suggestion: webhook support for row changes:
If my Sheet updates (say, a new waitlist signup), I'd want to trigger for e.g. a Slack notification. Supabase has something similar with their database webhooks. I use that extensively for kicking off signup workflows.
You can do this now directly in the Google environment. Should be trivial to vibe code Google Apps Script to hit a Slack endpoint. You'd probably use an 'on edit' trigger to run the code.
That's a great suggestion, thank you
For your signup workflows, how sensitive would you be to latency? Would a 30 to 60 second delay be a dealbreaker, or are you looking for something that hits Slack the instant the row is created?
(The challenge with Google Sheets is we'd have to poll for changes)
I think it can be one option to achieve a tiny goal. Some companies often think that using AWS or GCP is too much of a stretch for a minimum target. So, it can be a good way to meet their request.
This site is pretty broken. The project seems cool but I’d recommend a more static landing page. I bounced very quickly. Didn’t even make it to the bottom with all the distracting animations.
I really like the idea of using Google Sheets for quick prototyping and maybe "vibe coding" without the friction of setting up a traditional DB.
I haven’t noticed a scrolling issues, btw
I have done this for my own projects for years it’s great for projects that are only for me and gives me a very good db editor also. Cool project though the only risk I see is that if the target audience are vibe coders they will you known just vibe code an integration
Thank you! The idea of our target audience just vibe coding this themselves definitely gave us pause for thought while we were building it :)
We're thinking of playing around with the pricing right now to make sure it is cheaper to just use this than to spend the time and tokens recreating the logic. We will see how it plays out.
I made a similar project: https://veneer.leftium.com
You can publish any publicly readable sheet/form (append rows with publicly available form):
- sample sheet: https://veneer.leftium.com/s.1RoVLit_cAJPZBeFYzSwHc7vADV_fYL...
- sample form: https://veneer.leftium.com/g.chwbD7sLmAoLe65Z8
A pay option like this definitely seems worse than the Firebase backend that AI Studio would automatically use.
Looks great! I’ve definitely wanted this exact thing before. I will consider reaching for this next time I need to throw together a quick app.
Just impossible to read the landing page on mobile due to endless carousel sliding which constantly returns you to the top of the page
I didn't have any "top of page" navigations that I didn't control going on.
Did this 9 years ago :o, cached it though.
The animations in the page keeps interrupting me and scrolling me up after I scroll past them.
Is this in the 'How it Works' section? I'll get that fixed - thanks for letting me know.
Yes https://youtube.com/shorts/rQdvvGtapL4
This is really helpful thanks. I've just pushed a build to disable the scroll-jacking - ETA 5-10 mins!
If this site does not run on top of a google sheet then don't believe it.
Oh man fix the site. If I scroll down it auto scrolls up after 2 seconds. And other bugs.
Sorry about that - I've pushed a fix to stop it from auto-scrolling which should be propagating through soon. Thank you for flagging this
Thanks! No need to be sorry :)
You do not need to go through these guys Google provides access to the URL to use the sheet as a database and also allows you to deploy Javascript and even host the site with AppScript (example https://script.google.com/macros/s/AKfycbzYt_aXBdQlnMM7idlVD... )
The +1 button doesn’t work?
Umm, does Google sheets let you fetch rows in O(log(n)) time or aggregate numbers?
Is this meant to replace databases?
Awesome！
"Ship now, pay later" you're not wrong.
Do vibe coders need an api for an api? Sounds like something solvable with a skill
Good project but I wish something like this can exist for proton mail, I have made some puppeteer scripts which can hook up to proton docs.
But Proton is really doing some great disservice to not having a public api for their docs.
I can imagine it being used for anonymous comments page for webpages etc.
I am not sure if there is something that you can do about it though given that the fundamental issue of this is caused by proton not having an api whereas I think google docs does have API.
It's more a message to proton if anything.
The world needs less vibe coded slop, not more