Unit 3 · Module 1

Scripts In Relation To Apps

Where scripts sit, what apps host them, and what they’re typically used for

Where scripts sit

Scripts live inside apps. An app provides the environment — the Sheet, the Airtable base, the browser page. A script is a piece of code that runs in that environment to do a specific job. The app starts the script, decides what it’s allowed to touch, and shuts it down when it’s done.

A Next.js app — the project folder, the routes, the deployment to Vercel — is one of those environments. A script in a Google Sheet is a guest in another one.

Analogy: Restaurant and recipe card

An app is the whole restaurant — kitchen, menu, staff, hours, the building. A script is a single recipe card handed to the chef. The chef reads it once, makes the dish, throws the card away. The restaurant keeps running. The card couldn’t exist without the kitchen behind it.

Side by side

App Script
Owns its own runtime Yes — Node, Vercel, etc. No — runs inside something else
Has a UI Usually Rarely — borrows the host’s UI
Lifetime Long-running, always on Short-lived, fires when triggered
Typical job Be the product Glue, automate, or extend something else
Size Many files, folders, routes Usually one file, one or a few functions

The three jobs a script almost always does

Scripts in the wild fall into one of three buckets. Knowing the bucket tells you most of what to expect from the script’s shape.

1. Glue

Take output from one system, reshape it, send it somewhere else. A Sheet row becomes a Slack message. A Stripe webhook becomes an Airtable record.

2. Automation

“When X happens, do Y.” Triggered by time, an event, or a button click. A daily 7am summary email. An Airtable status field that updates when a record changes.

3. Extension

Customize an app in a way the original developers didn’t anticipate. A custom function in a spreadsheet cell. A Notion button. A Figma plugin.