Where software lives

This chapter gives you the map for that split.

Every app runs on your device, on someone else's computer, or on both at once, and once you can tell which one you are looking at, whole categories of confusion go away.

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 or on your desk, and everything it needs (the program, your data, the computing power) is physically with you. Cut the network and it keeps working, because nothing it depends on lives anywhere else.

Remote software runs on a computer you will never see. That computer usually sits in a data center, a building full of machines that 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 in the first place.

Builders use a few other words for the same split, and you can translate them on sight.

• 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 is a marketing label for a particular flavor of remote. There are still servers involved; you just never have to manage a specific one. It is the kind of vocabulary trap we took apart in Decode the technical questions that stop you.

Choosing which kind of remote your product should use is a real decision, and it gets a full chapter in Hosting, renting a computer on the internet.

The Wi-Fi test settles it in ten seconds

You never have to guess where an app runs or read its documentation to find out. Take the network away and watch what survives.

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. If part of it keeps working while the rest goes quiet, you are looking at a hybrid, and the parts that went quiet are the ones running on someone else's computer.

Every app on a home screen looks equally alive, and the icon tells you nothing about where the app actually runs. Dropping the network is what makes that dependency show up. The notes app and the camera carry on as if nothing changed, while the AI chat app and the maps app dim immediately, because their working halves are in a data center somewhere else.

AI products are almost always hybrid

Most modern apps split the work. Your device renders the screen, handles taps and keystrokes, and keeps a copy of recent data close at hand, while a remote computer stores the permanent records and does the heavy lifting. AI products push that split further, because the models that generate their output run on racks of specialized hardware in data centers, not on anything you can carry.

Granola, the AI meeting notetaker, dissects cleanly along this line.

• The listening half is local. Audio capture happens on your device, which is why a connection drop in the middle of a meeting does not cost you the recording or the notes you are typing.
• The polishing half is remote. The finished notes come from cloud models that merge the transcript with whatever you typed. Offline, Granola degrades gracefully into a capable capture tool, and the intelligence returns when the network does.

That pattern repeats across the products you use every day. Phones do run small models on the device for narrow jobs like keyboard suggestions and photo search, but anything that drafts, summarizes, or answers open questions at the quality you now expect is calling a remote model. When an AI feature fails in airplane mode, you are looking at the location of the model, not at a bug.

ChatGPT and the Notes app under the test

The clearest example of each end of the spectrum is probably on your phone already.

• Apple's Notes app keeps working in airplane mode. Notes open, new notes save, and edits hold. It is local software with quiet remote syncing layered on top, and the sync resumes on its own when you reconnect.
• ChatGPT fails the moment you send. The app on your phone is a thin window, a text box and a scrollback, and the model that produces every answer runs on OpenAI's servers. With the network gone, the window has nothing to show you.

Most of what you use daily sits somewhere between those two, and the test tells you where.

Where it runs decides what data leaves your device

Asking where a feature runs is really asking where your data goes. If the work happens on your device, the data can stay there. If the work 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 tells you exactly what must leave the device, and that turns a vague unease into questions you can put to a vendor or your own engineers. What leaves the device when this feature runs, where does it land, and how long is it kept? We return to protecting what travels in Guardrails: keep secrets, money, and data safe, and to where stored information lives in Data, where information lives.

Try it now

No setup: Put your phone in airplane mode and open three apps you used today. For each one, use its main feature, then ask it for something new, and write down a verdict: local, remote, or hybrid. On the hybrids, note which half died. If the app has an AI feature, that feature is almost always in the dead half, and now you know why. Soon the classification starts happening on its own every time an app stalls.

With your tools: Open Claude Code and have it dissect itself. Ask which parts of its work happen on your machine and which parts need the network, and what leaves your machine when you send a prompt. The map it returns is a textbook hybrid: reading files, editing them, and running commands all execute locally on your computer, while every response is generated by a remote model, which means your prompt, plus the file contents pulled in as context, travels to servers you will never see. You have just classified your own primary instrument. In Codex or Cursor the move is the same: ask the sidebar which of its actions run locally, which require a network call, and which files travel along 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 runs on the device in front of you and keeps working when you cut the network.
• Remote software runs on a computer in a data center, and the app on your screen is just a window to it, so it goes blank when the network drops.
• Client, server, and serverless are builder words for the same split, and you can translate them on sight.
• The Wi-Fi test sorts any app into local, remote, or hybrid in seconds: turn on airplane mode, ask the app to do its main job, and watch what survives.
• A cached copy can fool the test, so ask the app for something new before you judge it.
• AI products are almost always hybrid, because the model runs on remote hardware, which is why a meeting tool can keep capturing through an outage while its polished notes wait for the network.
• Where a feature runs tells you what data leaves your device, which gives the privacy question a precise form instead of a vague worry.
• 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 documentation on on-device audio capture and cloud-based note generation.