Glue Code for Grown-Ups

There's a moment that every AppSheet developer hits, somewhere between the first working prototype and the first real deployment. You've built something genuinely useful. The forms work. The views look reasonable. Your stakeholder is making impressed noises. And then you squint at the platform and think: but what happens when this goes wrong?

Not if. When.

AppSheet is a remarkable tool. I'll say that sincerely, before I say anything else. The speed at which you can turn a Google Sheet into a functioning, multi-user application is still mildly absurd to me, even after doing it more times than I can count. But remarkable tools have edges. And AppSheet's edges are sharp in ways that don't always announce themselves until something falls on them.

The most significant edge is this: AppSheet operates on live data. There's no versioning. No rollback. No "undo from three hours ago." If a bulk action updates the wrong records, or an automation fires twice, or someone does something creative with an editable column they shouldn't have had access to, the data that was there before is simply gone. AppSheet didn't take it. It just didn't keep it.

Google Sheets offers version history, technically. In practice, reconstructing a meaningful state from Sheets' change log, for a file being hammered by an active application, is the kind of archaeology that makes you question your career choices.

So I wrote a backup script.

Specifically, I wrote a Google Apps Script. A few dozen lines of JavaScript that runs on a weekly trigger, copies the entire Sheet data source into a timestamped backup folder, and sends me a confirmation email when it's done. The whole thing took maybe ninety minutes including the time I spent second-guessing the folder naming convention.

It's not glamorous. It's not the kind of thing you put in a portfolio. But it has made me slightly less nervous about production data sources sitting in Google Sheets, and that is not nothing.

What struck me, writing it, was how obvious it felt. Of course you'd want a backup. Of course the platform doesn't provide one that meets a reasonable bar. Of course the answer lives in the space between what AppSheet does and what Google's broader ecosystem can do. This is the pattern. And once you see it, you can't unsee it.

Every no-code platform has an escape hatch.

Airtable has its automations and its API. Notion has its integrations. Power Apps has Power Automate. AppSheet has Apps Script, which is, if you'll allow a mild digression, a severely underrated tool. It's JavaScript (roughly), it runs in Google's infrastructure for free, it has first-class access to every Google Workspace product, and it can be triggered by time, by spreadsheet events, by HTTP calls, or by a human clicking a button. It is, in other words, genuinely capable.

The backup script is the simplest version of what Apps Script can do for an AppSheet build. But it's the tip of a more useful iceberg. Here's what else lives there:

Data validation that AppSheet can't express. AppSheet's validation rules are reasonable for simple constraints. But cross-row logic, "this record is only valid if no other record with the same project code is marked as active", quickly bumps into the ceiling. Apps Script can run on edit, check whatever you need to check, and write a flag back to the Sheet that AppSheet can read.

Alerting when something looks wrong. AppSheet has no native anomaly detection. Apps Script can run nightly, look for records that haven't been updated when they should have been, orders that are sitting in a status for too long, a Sheet that's grown by an unusual amount in a single day, and email someone. Not because the platform failed, but because the data is trying to tell you something and, let's be honest, no one's got time to stare at data all day long.

Scheduled archiving. Completed records accumulate. AppSheet's performance degrades gracefully but it does degrade, especially across mobile connections. A script that moves rows older than ninety days to an archive Sheet, and keeps the working data lean, costs almost nothing to build and makes a real difference in an app that's been running for a year.

Cross-app synchronisation. If you have two AppSheet apps reading from different Sheets that need to stay in partial sync - say, a master contacts list and a project-specific subset - you can write the sync logic in Apps Script rather than trying to torture AppSheet's automation rules into something they weren't designed for.

None of this is novel. None of it is difficult, exactly. But collectively, it's the difference between an AppSheet app that works in a demo and one that runs reliably in production for two years.

There's a version of this conversation where someone says: if you need to write code, why are you using a no-code platform?

It's a fair question with a bad premise.

No-code doesn't mean no engineering. It means that the visual application layer - the forms, the views, the workflows, the mobile UI - doesn't require you to write a line. That's valuable. That's a genuine saving. A properly built AppSheet app represents a fraction of the development cost of an equivalent custom application, and it's maintainable by people who aren't developers.

But production software, the kind that holds real data for real people who depend on it, has requirements that sit outside the application layer. Backup and recovery. Observability. Data hygiene. Scheduled maintenance. These aren't AppSheet problems. They're infrastructure problems, and they belong in infrastructure.

Apps Script is infrastructure. Lightweight, accessible, Google-flavoured infrastructure, but infrastructure nonetheless. Using it alongside AppSheet isn't cheating. It's the job.

The vendors would rather you didn't think about the gap, because the gap is where their polished sales material starts to look a little thin. But the gap exists whether you think about it or not. The only question is whether you've filled it before something falls through.

I now have a folder in Google Drive with fifty-three timestamped copies of a spreadsheet that no one has ever needed to open.

That's exactly where I want them.