Two roles that exist the moment anything is online: the machine that asks (client) and the machine that answers (server).
Why it exists
A user's phone cannot hold everyone's data or be trusted to enforce the rules on its own: your order history, other people's listings, and the logic that decides what is allowed all have to live somewhere shared and controlled. So work splits into two roles, the device that asks for things and the machine that holds the shared state and answers. Naming which side a piece of behavior belongs to is what lets a team reason about where data lives, what a user can tamper with, and where a given bug has to be fixed.
How it actually works
Your phone or laptop is the client. It sends a request over the internet. Somewhere, a server receives that request, does the work, and sends a response back. Every website, app, and API is some version of this back-and-forth.
The same computer can be a client in one moment and a server in another. The words describe roles in a conversation, not fixed machines.
A senior PM walks you through it
A junior PM, stuck
In triage the dev asked "is this client or server?" about a wrong Kacchi price on the menu. I froze. I was looking at the same screen he was and could not tell which side to blame, or who should pick up the ticket.
The trick is to stop looking at the screen and look at the exchange behind it. Every screen is one side asking and the other answering, and each line was written by exactly one of them. This is one captured call for the menu: what the phone sent up, and what the server sent back. Once you can tell whose line is whose, "client or server" answers itself. Read it with me.
GET /api/products, one exchange: who wrote which line
The phone sent this up
11.1
2:
3:1569
The server sent this back
41.1200
5{
6"count":12,
7"products":[
8{
9"id":"p_1042",
10"name":"Kacchi Biryani (Family Pack)",
11"price":649,
12"in_stock":true
13}
14]
15}
Click a step to see the lines it points at.
Mistakes I've seen
Blaming the visible layer because it is what you can see. The screen is the client, but the wrong value often arrives from the server already broken; check the response before you assign it.
Filing "client or server" from the screenshot alone. You need the captured exchange; without the raw request and response you are guessing which side wrote the wrong line.
Forgetting the same machine plays both roles. The server that answers the phone is itself a client when it calls the payment gateway, so "server" is about role in the exchange, not a fixed box.
Assuming a missing auth line is a server bug. If the request never carried the login proof, the client dropped it; that is fixed on a different side than a server rejecting a valid one.
Say: "The price is in the response body, so whatever is wrong with it left the server that way. This is server-side." You found the line, named which side wrote it, and routed the ticket. That is the whole client-versus-server skill.
Where a PM meets this
Almost every bug is on one side or the other. "Is it the client or the server?" narrows down who looks at it.
Slow experiences can come from a slow client (an old phone) or a slow server. They are fixed very differently.
Hear it in a meeting
"The client sends it fine, the server just isn't responding."