Why We Put Your Backend in a Spreadsheet

When we tell people Sheetspin runs your website's backend out of a Google Sheet, the reaction usually splits two ways. Developers wince. Everyone else asks why nobody did this sooner.

Both reactions make sense. So here's the thinking.

The backend you actually need is small

Most websites — small business sites, portfolios, restaurants, non-profits, agencies — don't need a "backend" in the heavyweight sense. They need a place for contact form submissions to land. A list of blog posts. Some FAQs. Maybe a gallery of images. A newsletter signup. A handful of site-wide settings like a tagline or social links.

That's it. That's the whole backend.

But the tools we reach for are built for something much bigger. A headless CMS assumes you have a content team. A custom API assumes you'll keep maintaining it. A database assumes you'll write migrations. Every option carries the weight of problems you don't actually have.

A spreadsheet is already the right shape

Look at what your data actually looks like. Blog posts? Rows with a title, body, slug, and a published flag. FAQs? Rows with a question, answer, category, and order. Form submissions? Rows. Gallery captions? Rows. Events? Rows with dates.

Tabular data wants to live in a table. A spreadsheet is a table. The "translation layer" most backends spend their effort on — turning structured data into rows and back again — disappears entirely when your data was always rows to begin with.

And spreadsheets bring something databases don't: a UI your client already knows how to use. The restaurant owner editing their menu doesn't need a CMS login. They open the sheet. They edit a cell. The site updates. There's no admin panel to build, no permissions system to design, no "content workflow" to teach.

The infrastructure problem solves itself

Here's the part that makes developers wince and then, usually, nod. Google Apps Script runs your code on Google's infrastructure, for free, with no server to manage. The script is bound to your sheet, deployed as a web app, and given a permanent HTTPS URL. It scales the way Google Sheets scales — which, for the size of site we're talking about, is effectively unlimited.

You get:

• A real HTTPS endpoint
• Automatic caching
• Built-in email sending
• File storage via Drive
• OAuth-protected admin access
• Zero infrastructure to maintain

For zero dollars. Forever. Because Google is already running it for the spreadsheet itself.

The lock-in question, inverted

The standard objection to building on top of someone else's platform is lock-in. What happens when the SaaS raises prices, gets acquired, or shuts down?

But Sheetspin inverts this. Your data is in a Google Sheet — a format that has existed for nearly two decades, that exports cleanly to a dozen others, and that you can download as a file at any moment. The Apps Script that serves your API is also yours, sitting in your own Google account, editable and forkable. There is no Sheetspin server in the loop. If Sheetspin disappeared tomorrow, your site would keep running, because nothing about the running system depends on us.

That's the opposite of lock-in. That's escape velocity built in from day one.

The manifest pattern

The one piece of real engineering inside Sheetspin is the manifest pattern. Instead of hardcoding your site's structure into the script, the script reads a _manifest tab in your sheet on every request. That manifest lists your modules, their tab names, their column schemas, their form fields.

This means adding a blog, removing a gallery, or changing form fields is a spreadsheet edit — not a code change. The endpoint URL never moves. The script never gets redeployed. Your site evolves at the speed of editing a cell.

It's a small idea, but it's what makes the rest of the system feel like magic instead of a hack.

What we gave up

Be honest about tradeoffs. A Google Sheet is not the right backend for everything. If your site needs millions of rows, complex joins, transactional writes, or sub-50ms response times, you need a real database. If you need fine-grained user accounts, role-based permissions, or compliance certifications, you need a real platform.

Sheetspin is for the long tail of sites that don't need any of that — but currently get sold solutions designed for sites that do. We picked a deliberately narrow target: the sites that exist in the gap between a static HTML page and a full web app.

Why a sheet, really

Underneath all of it is a belief that the right tool is usually the simplest tool that fits the shape of the problem. Most small-site backends are a contact form, a few content tabs, and some images. A spreadsheet is, almost by accident, the most natural representation of exactly that.

So we stopped fighting it. We put the backend in a sheet, and the whole thing got smaller, friendlier, and more durable in the process.

Try it at [sheetspin.com](https://sheetspin.com).