Where software lives

This chapter gives you the words for that split and a ten-second test that sorts any app.

Local and remote, the two places software runs

Local software runs on the device in front of you. The code executes on the processor in your hand, and everything it needs (the program, your data, the computing power) is physically with you, so cutting the network changes nothing.

Remote software runs on a computer you will never see. That computer sits in a data center, a building full of machines someone else owns and operates, and the app on your screen is a window to it. Cut the network and the window goes blank, because the work was never happening on your device. When builders say "the cloud," they mean these remote computers under a friendlier name.

Builders use other words for the same split:

• Client means the local half: your phone, your laptop, your browser.
• Server means the remote half: the machine doing work on your behalf somewhere else.
• Serverless still means servers; the label only says nobody on your team manages a specific one, a vocabulary trap from Decode the technical questions that stop you.

Which half of your product needs the network

Whatever you build will have both halves: the screens and taps can live on your user's device, while any work a model does happens on computers you rent. Knowing which half is which answers the question a careful customer will ask in your first sales conversation: when this feature runs, where does our data go?

Run the Wi-Fi test on any app

You never have to guess where an app runs. Put your device in airplane mode, open the app, and ask it to do its main job. If everything still works, the software is local; if it dies immediately, it is remote; and if part keeps working while the rest goes quiet, it is a hybrid: the quiet parts run on someone else's computer.

Here is what the test finds on a current phone:

airplane mode on; each app asked to do its main job,
then asked for something new

WHAT SURVIVED                        WHAT DIED
notes: open, edit, save, search      chat assistant: every new answer
camera: shoot, review, edit          maps: search for a new address
writing tools: proofread and         meeting notetaker: the polished
  rewrite a short paragraph            summary of the meeting
chat assistant: yesterday's          app store: everything, including
  answers, still readable              the search box

Read the log like a map: everything on the left finished on the processor in your hand, and everything on the right lives in a data center. The chat assistant survived as a reading app and died as an answering app, because old answers are stored on the phone and new ones are produced remotely. The rows have familiar names: Apple's Notes app is the classic survivor, and ChatGPT is the purest resident of the right column, a thin window (a text box and your message history) onto a model running entirely on OpenAI's servers.

Put the device in airplane mode and watch what survives: what keeps working is local, what goes quiet is remote, and an app that half-works is a hybrid.

AI products are almost always hybrid

Most modern apps split the work: your device renders the screen, handles the taps, and keeps recent data close, while a remote computer stores the permanent records and does the heavy lifting. AI products push the split further, because the large models behind their best features run on racks of specialized hardware, not on anything you can carry.

Granola, the AI meeting notetaker, is the notetaker row in the log.

• The listening half is local. Audio capture happens on your device and the notes you type stay in front of you, so a dropped connection mid-meeting costs you neither.
• The polishing half is remote. The finished notes come from models running in the cloud, which merge the transcript with whatever you typed; offline, Granola degrades gracefully into a capable capture tool, and the intelligence returns with the network.

The dead column is smaller than it used to be. Current phones now run small models on the device that proofread a paragraph, rewrite a short note, and summarize brief text with no connection at all, which is why the writing tools row survived. What still dies with the network is work that needs a large model or fresh information: open-ended drafting, and answers about anything the device does not already hold. When one of those fails in airplane mode, you are looking at the location of the model, not at a bug.

Every app runs on your device, on someone else's computer, or on both at once, and an AI product is nearly always both: the small helpers travel with you while the heavy generation stays in a data center.

The obvious objection: you are almost never offline

Connectivity is close to everywhere now, so the split can read like trivia. But the tunnel only makes the split visible, and even on a perfect connection, where the work happens decides:

• What leaves the device. Local work can keep its inputs where they are; remote work carries them along, every time.
• What each use costs. A user's device is paid for once, while remote computers are rented and metered; Hosting, renting a computer on the internet teaches you to read that meter.
• What survives a failure. When a provider goes down, the remote half of every product built on it goes quiet at once; products that degrade gracefully, like the notetaker still capturing, come from teams that knew which half was which.

Where it runs is where your data goes

If the work happens on the device, the data can stay there. If it happens remotely, the inputs travel with it: the prompt you typed, the document the feature read, the audio your meeting tool captured. Knowing which half is remote turns vague unease into questions for a vendor or your own engineers: what leaves the device when this feature runs, where does it land, and how long is it kept?

Asking where a feature runs is really asking where your data goes: the remote half of an app defines exactly what has to leave your user's device.

We return to protecting what travels in Guardrails: keep secrets, money, and data safe and to stored information in Data, where information lives.

Try it now

This drill takes about ten minutes and spends nothing.

No setup: Put your phone in airplane mode and rebuild the log above with your own apps. Pick three you used today, ask each to do its main job, then ask it for something new, and write a verdict for each (local, remote, or hybrid) and note which half died. Expect features that draft or answer open questions in the dead column; a small fix-my-text feature may surprise you by surviving. You leave with a three-app verdict list; keep it, because The journey of a request will trace one of your remote verdicts stop by stop.

With your tools: Open Claude Code and have it dissect itself. Ask which parts of its work happen on your machine and what leaves it when you send a prompt. The answer is a textbook hybrid: reading files, editing them, and running commands all execute locally, while every response is generated by a remote model, so your prompt and the file contents pulled in as context travel to servers you will never see. In Codex or Cursor the move is the same: ask the sidebar which of its actions run locally and which files travel with each request. If nothing is installed yet, the Setup Clinic gets you there.

Chapter Summary

• Software runs in one of three places: on your device, on someone else's computer, or on both at once.
• Local software keeps working with the network gone, because everything it needs is physically with you; remote software goes blank, because the app was only a window to a data center.
• Client means the local half, server means the remote half, serverless still means servers, and "the cloud" is remote computers under a friendlier name.
• The Wi-Fi test sorts any app in seconds: airplane mode on, ask the app to do its main job, then ask it for something new, and watch what survives.
• A cached copy can fool the test, so always ask the app for something new before you judge it.
• AI products are almost always hybrid: small on-device models now proofread, rewrite, and summarize short text offline, while open-ended generation and fresh-knowledge answers still come from remote models.
• Even on a perfect connection, the location of the work decides what data leaves the device, what each use costs, and what survives an outage.
• Where a feature runs is where your data goes, which turns the privacy question into something precise enough to ask a vendor.
• Your drill artifact is a three-app verdict list from your own phone; the next chapter traces one of its remote verdicts.
• Next, The journey of a request follows one tap from your screen to a data center and back, with names for every stop.

Sources

• Granola product and security documentation on device audio capture and cloud-based note generation (last verified July 2026).
• Apple support documentation on Writing Tools with Apple Intelligence and on-device processing (last verified July 2026).
• Android developer documentation on Gemini Nano on-device summarization (last verified July 2026).
• OpenAI help center documentation for the ChatGPT mobile app (last verified July 2026).