Backend, where the real work happens

AI asks: Where should this logic run?

The honest version of this question is "should this happen on the user's device, or on a server somewhere?" Day 3 gave you the vocabulary for the two options. Day 9 is when you learn how to actually decide.

What "backend" actually means

The backend is the work that happens out of sight, on a computer somewhere else, in response to requests from the frontend.

The reason backends exist is that there are at least three things you cannot do well on a user's device.

First, store things permanently and share them across users. Your phone can store your photos, but it cannot store everyone's photos and let you all see each other's. That requires a shared remote place, which is the backend's job.

Second, keep secrets. Anything that runs on a user's device can be inspected by that user. If you put your API key for OpenAI in the frontend, someone will find it and run up your bill. Secrets live in the backend.

Third, do heavy lifting. Tasks that require a lot of memory, a lot of computation, or a specific kind of hardware (a GPU, for example) usually do not fit on a phone. They run on a server.

If the thing you are building does not need any of these three (a calculator, a metronome, a journaling app that stores only on the device), you may not need a backend at all. Day 16 will come back to this with a decision tree.

Image slot

Suggested meme: the classic iceberg meme. Tiny tip above water labeled 'the button you clicked'. Massive underwater portion labeled 'everything that happened when you clicked it (auth check, rate limit check, database read, business logic, database write, queueing a notification, logging the event, returning a response)'. Save as public/lessons/day-09-meme.png and add src='/lessons/day-09-meme.png'.

One tap, many rooms.

What is actually inside a backend

If you crack one open, a typical backend has four kinds of things in it.

Endpoints. The specific doors at the server that frontend requests are allowed to knock on. (Day 10.)
Business logic. The actual rules of your product. "A user can only like a photo once," "a free user can send up to ten messages a day," "an admin can see everyone's data." Most of the meaningful intellectual property in a software product lives here.
Database calls. Reads and writes to wherever your data lives. (Day 11.)
Calls to other services. Sending an email through Resend or SendGrid, charging a card through Stripe, getting a model response from OpenAI or Anthropic. The backend orchestrates all of this on behalf of the frontend.

You will not write these yourself. You will need to know they are there, so that when AI tools name them, you know what they are pointing at.

How to answer the "where should this logic run" question

Three quick tests, in this order.

Does it need a secret? If yes, it has to run on the backend. No exceptions.

Does it need to be shared across users? If yes, it has to run on the backend, otherwise each user only sees their own version of the world.

Does it need a lot of computation, or a specific kind of hardware? If yes, backend.

If you answered no to all three, the thing can run on the frontend, and you should consider doing that, because frontend-only things are simpler to ship and cheaper to operate.

A surprising number of useful tools are entirely frontend. A pomodoro timer, a unit converter, a quick text editor. If your idea is one of those, you have just saved yourself most of Week 2.

A vocabulary sweep

API. The set of doors (endpoints) the backend exposes to the frontend. The "interface" in "Application Programming Interface" is literally a list of doors. (Day 10.)
Server-side rendering (SSR). When the server prepares the actual HTML before sending it, instead of letting the user's device assemble it. Good for speed and SEO, more complex than letting the frontend render.
Microservice. A backend split into many small backends, each responsible for one thing. Useful at large scale, overkill for almost everything else.
Monolith. A backend that is all one big program. Less fashionable than it used to be, still the right answer for most early-stage builds.
Cron job. A piece of backend code that runs on a schedule rather than in response to a request. ("Every night at 2 a.m., send the daily digest email.")

Forward references

Day 10 zooms in on APIs, which is the contract between frontend and backend. Day 11 covers the database, which is where most backend code spends most of its time. Day 12 is the question that broke the scientist from the founding essay: where does the backend itself actually run?

Day 9 wrap

The thing you can now say plainly. The backend is the work that happens out of sight, on a server somewhere, in response to requests from the frontend. It exists because there are at least three things (storage, secrets, heavy work) that cannot live on the user's device.

The thing you can now do. When AI asks "where should this logic run," apply the three tests in order (secret, shared, heavy) and answer with confidence.

The guardrail to remember. If your thing does not need any of the three, you might not need a backend at all, and resisting the urge to build one anyway will save you weeks.

See you on Day 10, where we look at the contract between the two sides.