The part of your product that runs on the server, out of sight: the logic, the rules, and the handling of data.
Why it exists
A page can show information but it cannot be trusted to decide anything: any visitor can open it, read it, and change what it sends back. Prices, stock counts, who is allowed to do what, and whether a payment really succeeded all have to be settled somewhere the user cannot reach. The backend exists to hold that logic and data on the server, so the rules are enforced in one place customers cannot edit.
How it actually works
A page cannot decide what is in stock, what a customer owes, or whether a password is correct. That thinking happens in the backend, code that runs on the server where users cannot see or change it.
The frontend asks the backend questions and shows the answers. The backend is where the real decisions and the valuable data live.
A senior PM walks you through it
A junior PM, stuck
An engineer rejected my quick discount idea. I said the app can just send the discounted price to checkout, and he replied "pricing must be validated server side" and closed it. I do not see why the app cannot send the right number. It is our app.
Here is why, in one real exchange. The app can send any number it likes; the point is that the server does not trust it. This is a checkout request where the app claimed Kacchi costs 1 taka, next to what the server actually did with that claim. It takes two minutes to read and it makes his rule obvious. Look at the request, then the response.
POST /api/orders: client claims 1 taka, server charges 649
What the app sent
11.1
2:
3{
4"product_id":"p_1042",
5"qty":1,
6"price":1
7}
What the server did
81.1201
9{
10"order_id":"o_5512",
11"product_id":"p_1042",
12"qty":1,
13"price":649,
14"total":649
15}
Click a step to see the lines it points at.
Mistakes I've seen
Speccing a discount as "the app sends the lower price." The server reprices from its own data, so the discount has to be a rule the server knows, not a number the client hands it.
Reading a 201 as "the client's body was accepted as-is." The server takes the request as a request, then substitutes its own trusted values; the response is the truth, not the body you sent.
Assuming "it is our app so we can trust it." The app runs on the customer's phone, where anyone can edit what it sends. Our code, their machine.
Confusing where a field is displayed with where it is decided. Price shows in the frontend but is decided in the backend, so a wrong price is almost always a server-data ticket.
Tell him: "Understood, the server reprices from its own data and ignores the client's number. So for the discount, what rule do I give the backend, a percentage or a promo code?" You saw the server override the client and asked the right next question. That is the skill.
Where a PM meets this
Backend work is where invisible-but-expensive engineering time goes. A feature that looks small on screen can be weeks of backend work; this is usually why estimates surprise you.
Sensitive rules (pricing, permissions, payments) must live in the backend, because anything in the frontend can be tampered with.
Hear it in a meeting
"The UI's done, we're just waiting on the backend to return the right numbers."