Google Apps Script
is not a toy.

There is a certain sort of technical snobbery about Apps Script. It is a scripting layer inside a spreadsheet, so it must be a toy. Meanwhile a genuinely large number of businesses run their operations on Sheets, and the thing that automates those Sheets is running real work, whether or not it is fashionable.

Our position is straightforward: Apps Script is a legitimate platform for a defined class of problem, and it is engineered badly almost everywhere because nobody treats it as one.

What it is genuinely good at

1. Living where the data already is. No hosting, no deployment pipeline, no separate login. If the process runs in a spreadsheet, the automation runs in the same file the team already opens every morning.
2. Workspace-native permissions. Access is governed by the Drive sharing you already manage, rather than a second permission model you have to keep in step with the first.
3. Scheduled work. Time-driven triggers handle the nightly report, the weekly export, the reminder that goes out every Monday — the jobs that never justify a server.
4. Glue between Google and everything else. Pulling from an API into Sheets, pushing form responses into a CRM, generating documents from a template and filing them. This is the majority of what businesses actually want automated.

Where it stops, and you should stop with it

Honest limits, because building past them is where people get hurt.

1. Execution time. Scripts are killed after a few minutes. Anything that processes tens of thousands of rows in one pass has to be re-architected into batches with saved state, and at some point batching a job that wants to run for an hour is just an expensive way to avoid a proper backend.
2. Daily quotas. Email sends, URL fetches and trigger runtime are all capped per day. A system that works in testing can hit a wall in month three when volume doubles, and the failure is abrupt.
3. Concurrency. Two people editing the same sheet while a script writes to it is a race condition. Locking exists, and almost nobody uses it.
4. Anything with real money or real personal data at stake. Not because the platform is insecure, but because the audit trail, environment separation and rollback story you want around those things is not what a bound script gives you.

The failure mode is never that Apps Script cannot do it. It is that it can, just about, for eighteen months — and then the business depends on a script one person wrote, that nobody has version controlled, that silently stopped running in March.

What treating it as a real platform means

1. Version control outside Google. Push the project to a repository with clasp so the code has history, review and a copy that survives somebody leaving.
2. Errors that reach a human. A failed trigger is silent by default. Every scheduled job needs a failure path that emails or posts somewhere a person actually looks.
3. Separate configuration from code. API keys and identifiers live in script properties, never in the source, so the same script can point at a test copy without an edit.
4. A standalone project, not a bound one. Bound scripts die with the file they live in. Standalone projects can be shared, versioned and deployed independently.
5. Idempotence. Assume every job will be run twice. Design so the second run does nothing rather than sending the invoice again.

The migration question

Most of our Apps Script work is one of two conversations. Either a business has a working spreadsheet process and wants it automated properly — a good, cheap, quick engagement. Or a business has outgrown one, and the honest answer is that the next step is a real application with a database, and the script should be retired rather than extended.

The signal for the second conversation is usually one of three things: the spreadsheet has more than one editor at the same time, the row count is in six figures, or somebody has started keeping a second sheet to correct the first one. Any of those and you have crossed the line.