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 Google Sheet is the database and the admin panel. Add a row, add a 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?
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.
The intent layer for B2B outbound
CatchIntent spots real buying signals on LinkedIn and gives you a short daily list of in-market buyers, scored and with the opener drafted. You just send.
When this is a bad idea
Iām not going to pretend this works everywhere. Itās great here and would be a disaster in plenty of other places:
- High write volume? Nope. This works because the data changes a few times a week, not a few times a second.
- Need transactions, stock counts, actual relationships? Use a real database.
- Need instant consistency? Thereās a gap between editing and going live. Fine for a catalog, terrible for a checkout.
- In the mood to overengineer? Then ignore all of this. Reach for Kubernetes, a few microservices, a Kafka queue, event sourcing with CQRS, and a multi-region Postgres cluster. Gloriously over the top for a catalog that changes twice a week, but hey, youāll have fun.
Small, read-mostly, edited by humans who like spreadsheets. Thatās the sweet spot. Step outside it and youāre just inventing a creative way to hurt yourself.
The takeaway
Honestly the whole lesson is: meet people where they are. I could have built a slick admin panel theyād use nervously and then quietly go back to a spreadsheet on the side anyway. Instead, the tool they already trust is the backend.
Itās been running quietly ever since. They add new designs, hit Publish, and send buyers a link to their catalog āļø. And my tech support load has stayed at about zero, which was the entire point.