Backend, where the real work happens

Frontend, what users see closed with the warning that scene ignored: frontend code ships to every user's device, so anything inside it is public. This chapter prints the line that turned the warning into a bill, the version that cannot leak, and a test for which features belong on the half nobody sees.

The exposed key, printed in full

Here is the heart of that demo page, close to what an AI tool produces for a page that calls the model directly, as every browser received it:

const KEY = "sk-live-8f3ab61c29d47e05";
sendToModel(KEY, userText);

An API key is a credential string that tells a model provider whose account to bill. This one sits in plain text inside a page delivered whole to every browser, because a browser cannot run code it has not received. The DevTools panel from the journey of a request shows it riding out on every request, and copying the string between the quotation marks takes a stranger under a minute. None of this is hacking; they are reading what you delivered. They spend, your account is billed, and automated scrapers comb the public web for exactly this mistake.

The version where the key never leaves

There is no better hiding place inside the page; the fix is a second computer. The page sends the user's text to a machine you control, and the key lives in code no visitor ever downloads.

// in the page, delivered to every browser: no key anywhere
sendToMyServer(userText);

// on your server, in code no visitor ever receives
const KEY = readSecret("MODEL_KEY");
sendToModel(KEY, userText);

The route is now fixed: the frontend sends the input to your server, your server attaches the key and calls the model, and the response returns through your server to the screen. The key rides only the middle leg, between machines you and the provider control, never on a device you do not.

Three jobs only a server can do

Keeping secrets is only the first of the server's three jobs, the jobs a user's device cannot do.

Keeping secrets. You have just watched this job fail and seen the fix: anything that must stay hidden can only live on a machine you control.

Holding what users share. Your phone can store your own photos, but it cannot hold everyone's 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, lives in one place every device reaches. The backend is that meeting point, keeping the shared records in storage only it can touch; data, where information lives covers that storage.

Doing heavy work. Some jobs need more memory and processing than a phone carries: searching millions of records, processing video, running the largest AI models. That last job runs on racks of GPUs, the specialized chips built for the enormous arithmetic a big model works through.

Together they define the invisible half: the backend is the software that runs on a server and does work in response to requests from frontends.

The jobs double as the test you will use constantly. When an AI tool asks where some logic should run, or proposes an architecture, the plan for where each piece runs, ask in order: does this need a secret, shared records, or heavy work?

A single yes sends the logic to the backend, and all nos mean the feature can stay on the device.

The obvious objection: your phone already runs AI

The phone in your pocket now runs real AI with no server in sight. Recent phones ship with small built-in models that summarize notifications and tidy voice notes with the network off; watch them work in airplane mode. So why route every AI feature through a server?

The AI a product bills for is a different animal from the AI a phone ships with: on-device models are small by design, while the models products build on are orders of magnitude larger and run on those racks of GPUs. And even a model that fit on the phone could not carry your key, which would land back inside code you delivered. When a small on-device model genuinely covers a feature, the three tests will say so.

One AI feature, traced end to end

Duolingo's Explain My Answer feature runs this route at consumer scale. Miss an exercise, tap the button, and the app explains nothing itself: it packages the exercise and your answer into a request to Duolingo's servers, which attach Duolingo's own credentials, call an AI model, and return a bounded explanation of why the answer missed.

Run the tests 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. Course content and progress live in Duolingo's storage, which is why they follow you to a new phone.
• Heavy? Yes. The model writing the explanation runs on a provider's racks, well past what the phone's built-in models handle.

The phone asks and displays while the server holds the key, calls the model, and bounds what comes back; no learner has ever touched the credential that paid for their explanation.

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 on the device are real, useful, and complete with nothing on the other side of the network. Frontend-only products ship faster and hold less that can break while you sleep.

The temptation is to build the backend anyway for the accounts you might add later. Resist it until a feature actually fails a test: adding a backend when a real need arrives is routine, while operating one you never needed is a standing cost. A clean sweep of nos is one of the best outcomes a build can get; Find your build and give the model a job returns to this decision when you scope your own product.

Try it now

This drill takes about ten minutes and spends nothing on either path.

No setup: Pick one feature of an app you used today, the like button in a social app, the AI summary in your meeting tool. Run the three tests and write one sentence saying where its logic must run and which test decided it, at the level of "likes must be shared across users, so the count lives on the backend"; that is the precision an architecture conversation needs. If every test comes back no, confirm the verdict by using the feature in airplane mode.

With your tools: Open Claude Code, give it the idea from your idea file, and ask what would have to live on a server if it gained one AI feature, sorted into secrets, shared records, and heavy work. The list that comes back is your backend inventory, and the chapters ahead put vocabulary on every item. In Codex or Cursor the move is the same: describe the idea and ask what a server would need to hold and why. If nothing is installed yet, the Setup Clinic gets you running.

Either way, add to the idea file. Run the three tests on the idea you have been circling and append the verdicts, plus the backend inventory if you took the tooled path, to the idea file from Decode the technical questions that stop you. When you pick your first real build, those lines say whether it needs a server on day one.

Chapter Summary

• The backend is the software that runs on a server and does work in response to requests from frontends.
• An API key is the credential that tells a model provider whose account to bill, and a key placed in frontend code is delivered to everyone who loads the page.
• Reading delivered code is not hacking, and automated scrapers comb the web for exposed keys, so an exposed key turns into strangers spending on your account.
• The safe route is fixed: the frontend sends the input to your server, the server attaches the key and calls the model, and the answer comes back through your server. The key rides only the middle leg.
• A feature belongs on the backend when it needs something the user's device cannot provide: keeping secrets, holding what users share, 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.
• Phones now run small AI models offline, but the models a product bills for run on the provider's racks, and the key could never ship inside your pages anyway.
• 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, and you can 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 blog and help center, the Explain My Answer feature (last verified July 2026).
• OpenAI help center, best practices for API key safety (last verified July 2026).
• Anthropic API documentation, API key management (last verified July 2026).