Your Next Backend Could Just Be a Google Sheet | Akash Rajpurohit

Switch to dark mode Switch to light mode<br>Mobile Nav Hamburger

The ask

So a relative of mine runs a wholesale business. They design and make kids’ ethnic wear and sell it to shops, mostly offline. Phone calls, WhatsApp, the usual.

They wanted a website. Nothing fancy, just something to send a buyer so it looks legit and shows the latest designs, instead of looking like it’s from 2009.

The catch: I’m the tech support. And family tech support is a lifetime thing, you don’t really get to quit. 😄

So before writing any code I gave myself two rules:

They edit products themselves, without calling me.

After launch, I want to touch it basically never.

That second rule quietly killed most of the obvious options.

Building the site itself was the easy part, honestly. I leaned on Claude for most of the design and the code, and for a simple catalog that is close to a solved problem now. You can get something that looks good up pretty fast.

The real problem was the boring one: keeping myself out of the loop. What kills a setup like this isn’t the tech, it’s the bottleneck. If every catalog update and every small fix has to route through me, the whole thing slowly dies. So that was the actual goal, design myself out of it.

The part where I don’t build a CMS

Normally you’d reach for a CMS here. Database, admin panel, the whole thing.

I’ve babysat enough of those to know how it goes. Plugins to update, a DB to back up, someone forgets the login, and there’s a monthly bill for a site that changes maybe twice a week. Spinning up a whole database for a catalog that updates when a new design gets stitched felt like buying a forklift to carry groceries.

Then it clicked. They already keep all of this somewhere. Not in some tool I’d have to teach them. In a spreadsheet. Designs, sizes, colours, all of it, row by row.

So I stopped fighting it and just made the spreadsheet the actual backend .

💡 The whole trick

The Google Sheet is the database and the admin panel. Add a row, add a<br>product. Edit a cell, edit the product. Nothing new to learn.

How it works

One sheet, two tabs. One for products, one for the partners who get access to the full catalog. The site itself is just static files sitting on a CDN, so it’s fast and basically free to keep online.

The interesting bit is the middle. How does a row in a spreadsheet end up as a page on the internet without me being in the loop?

Edit the Google Sheet and click Publish, a GitHub Action runs the sync script to optimize images and write JSON and commit, then Cloudflare builds and deploys the Astro site to the edge.<br>There’s a GitHub Action that runs a small sync script. It walks the sheet row by row, pulls each photo from Drive (they just paste a share link), and writes everything out as plain JSON the site can build from.

The images are where most of the work happens. Their product shots are proper studio-quality, high-resolution photos, which means each one is way bigger than anything a thumbnail or a product page actually needs. So the script resizes them, strips the junk, and re-encodes them into a modern web format. It also keeps a tiny manifest of what it already processed, so the next run only touches the images that actually changed instead of re-crunching the whole catalog every single time. Big studio files turn into lean little thumbnails and nobody has to think about file sizes.

All of that gets committed back to the repo, Cloudflare ↗️ picks it up, builds the Astro ↗️ site and ships it to the edge. Astro sends almost no JavaScript by default, so the pages just load fast, which is exactly what you want for a catalog people will mostly skim on their phones.

Oh, and a nice accident: the repo now holds the full history of every change to the “database”. Free version control on a spreadsheet, didn’t even plan for that one.

One button

When should the site rebuild? Rebuilding on every edit is a bad idea, because a sheet fires an event on basically every keystroke, and you really don’t want a deploy kicking off because someone is mid-word in a product name. A nightly cron felt lazy and also slow (edit in the morning, live tomorrow, no thanks).

So I dropped a Publish button right inside the sheet with Apps Script ↗️. They edit all they want, click it when they’re happy, done. That’s the whole deploy from their side.

Under the hood it’s pleasantly dumb. A few lines of Apps Script hit the GitHub API and fire a repository_dispatch event, which is the thing that kicks off the Action. No webhook server to host, nothing sitting around waiting. The sheet pokes GitHub, GitHub does the rest.

Partner access works the same way. A little Cloudflare Worker ↗️ checks their code against that same partners tab, live, on each visit. So access lives in the same sheet as everything else, and adding or removing a partner is just editing a row.

PROMOTED

Built & launched by me

The intent layer for B2B...