You split a dinner bill in a payments app. You type the amount, tap send, and across the table your friend's phone buzzes with the money already in their balance. Everything you watched, the button, the spinner, the green check, ran on two phones. The part that made it real ran on a computer neither of you will ever see, which verified your identity, confirmed the money existed, moved it between account records, and wrote the result down so both histories agree from now on.
Frontend, what users see covered the half of the product that runs in front of the user. This chapter opens the half nobody sees, where products do the work they are actually valued for, and gives you a reliable way to tell which of your features must live there.
Three jobs only a server can do
The backend is the software that runs on a server and does work in response to requests from frontends.
It exists because a user's device cannot do everything, and the gaps fall into three jobs.
Holding what users share. Your phone can store your own photos, but it cannot store everyone's photos and let each of you see the others'. Anything that must read the same for every user, the feed, the booking calendar, the account balance, has to live in one place that all the frontends reach. That place sits behind the backend, and data, where information lives covers it in full.
Keeping secrets. The frontend is delivered to the user's device in full, and anything delivered can be inspected by the person holding the device, so a credential you put in frontend code is not hidden, it is handed to everyone who loads the page. Anything that must stay secret can only live on a machine you control.
Doing heavy work. Some jobs need more memory, more processing, or more specialized hardware than any phone carries. Searching millions of records, processing video, and running AI models on racks of GPUs all happen on servers because they cannot happen anywhere else.
These jobs double as the test you will use constantly. When an AI tool asks where some logic should run, or proposes an architecture for you to approve, ask in order: does this need a secret, does it need to be shared across users, does it need heavy work? A single yes sends the logic to the backend. All nos mean it can stay on the device, and it probably should.
Calling an AI model is backend work
A product that stores nothing and shares nothing still crosses this line the moment it adds one AI feature, because the secret test comes back yes. Every call to a model API carries an API key, a credential string that tells the provider whose account to bill. The key authorizes spending, and each request sent under it is metered and charged to whoever owns it.
Put that key in frontend code and you have shipped it to the public. Anyone who opens DevTools, the same panel you used to watch traffic in the journey of a request, can read the code their browser received and the requests it sends, copy the key, and make their own calls with it. None of this is hacking; they are reading what you delivered. They spend your budget, the bill arrives in your account, and automated scrapers comb the public web for exactly this mistake.
So the route for every AI feature is fixed. The frontend sends the user's input to your backend, your backend attaches the key and calls the model, and the model's response travels back through your server to the screen. The key stays on one machine you control and never rides along to a device you do not.
One AI feature, traced end to end
Duolingo Max's Explain My Answer feature runs this exact route at consumer scale. You miss an exercise and tap Explain My Answer. The app on your phone explains nothing itself; it packages the exercise context, the question and the answer you gave, into a request to Duolingo's servers. Those servers attach Duolingo's own credentials, call an AI model, and return a bounded explanation of why your answer missed, scoped to that exercise rather than an open-ended chat.
Run the tests on the feature and every one points the same way.
- Secret? Yes, the model credentials belong to Duolingo, and no learner's phone ever holds them.
- Shared? Yes, the course content and your progress already live in Duolingo's storage, which is why they follow you to a new phone the moment you sign in.
- Heavy? Yes, generating the explanation is model inference, work that runs on hardware no phone carries.
The division of labor is the part worth remembering. The phone asks and displays, while the server holds the key, makes the call, and bounds what comes back. Every learner who taps the button gets an explanation, and not one of them has ever touched the credential that paid for it.
When you may not need a backend at all
If every feature of your idea answers no to all three tests, skip the backend entirely. A unit converter, a metronome, and a journaling app that keeps entries only on the device are all real, useful, and complete with nothing on the other side of the network. Frontend-only products ship faster, cost almost nothing to operate, and contain far less that can break while you sleep.
The temptation, especially with AI tools that can scaffold a server in a minute, is to build the backend anyway for the accounts you might add later. Resist it until a feature actually fails a test, because adding a backend when a real need arrives is routine, while operating one you never needed is a standing cost in money and attention. We run the three tests on every feature before any code exists, and a clean sweep of nos is one of the best outcomes a build can get. Find your build and pick its shape returns to this decision when you scope your own product.
Try it now
No setup: Pick one feature of an app you used today, the like button in a social app, the search box in your email, the AI summary in your meeting tool. Run the three tests in order and write one sentence saying where its logic must run and which test decided it. Something like "likes must be shared across users, so the count lives on the backend" is the level of precision that carries an architecture conversation. If the feature passes all three tests with a no, confirm your verdict by using it in airplane mode.
With your tools: Open Claude Code, describe your product idea in a sentence, and ask what would have to live on a server if the idea gained one AI feature. Ask it to sort the answer into secrets, shared records, and heavy work. The list that comes back is the first draft of your backend inventory, and the chapters ahead give you the vocabulary for every item on it. In Codex or Cursor the move is the same: describe the idea in the sidebar chat and ask what a server would need to hold and why. If nothing is installed yet, the Setup Clinic gets you running.
Chapter Summary
- The backend is the software that runs on a server and does work in response to requests from frontends.
- A feature belongs on the backend when it needs something the user's device cannot provide: holding what users share, keeping secrets, or doing heavy work.
- Run the three tests in order on every feature. A single yes sends the logic to the server, and all nos mean it can stay on the device.
- Any AI feature belongs on the backend, because calling a model needs an API key, and the key is a secret.
- An API key put in frontend code is handed to everyone who loads the page, so they can copy it and spend your budget.
- The safe route is fixed: the frontend sends the input to your server, the server adds the key and calls the model, and the answer comes back through your server to the screen.
- Hiding the key is only half the job. An endpoint with no sign-in and no rate limit still lets strangers spend your budget, so decide who may call it and how often before it goes live.
- When every test comes back no, shipping with no backend is a good result. You can always add a server later when a real need shows up.
- Next up is APIs, how systems talk to each other, which covers how the two halves talk in a disciplined way.
Sources
- Duolingo announcement of Duolingo Max and the Explain My Answer feature.