Understanding Technology

Frontend and backend, APIs, databases, login, deployment, security—a minimal technical foundation.

Frontend and backend, APIs, databases, login, deployment, security—a minimal technical foundation. You don't need to write code, but you do need to know which layer something happens on. Confuse the layers and your requirements won't land—and the errors you see will be unreadable.

After reading, you should be able to answer:

• The difference between "just change the frontend" and "we need to touch the backend"
• Why you get logged out for no reason, and what a token is
• The spots where AI-generated code most often opens security holes

Frontend and backend

One-sentence dividing line: anything changeable in the user's browser is frontend; anything that has to compute on your server is backend. Anything involving money, permissions, or someone else's data always lives on the backend. So "just change the frontend" usually means styling and interaction, while "we need to touch the backend" means logic and rules—when you hear those two phrases, you should be able to gauge how big the change is: a frontend tweak can ship the same day; touching the backend means assessing data, permissions, and compatibility. A more practical model: the frontend is about "does it look right," the backend about "is it computed right"—and the real correctness always lives on the backend.

The API: the contract between the two

The frontend and backend don't talk directly; they talk through an API. An API is a contract: you send me these parameters, I return this data. A PM doesn't write APIs, but needs to know three things. First, APIs work on the data shape you define, so when a requirement says "show the user's level and last login time here," that tells the engineer an API needs to be added or changed. Second, one page load can call several APIs, and whichever is slow makes the page slow—that's what "a performance problem needs to be located at the API level" means. Third, the API is where permissions are enforced: the check for "are you allowed to do this" happens here, and hiding a button on the frontend doesn't count.

How login works

Login isn't "verify once and done." It's "verify once, then carry a token on every request after." The token is a signed pass: the server checks it on every request before deciding whether to hand over data. When you mysteriously get logged out, it's usually because the token expired, got cleared, or you switched devices. Understanding tokens also helps you plan: any feature that needs to know who you are goes through this verification, so align early with your engineer on where the credential lives, how long it lasts, and what happens when it's forgotten.

What a database looks like

Just tables. Each table stores one kind of thing: a users table stores users, an orders table stores orders, and tables relate to each other by id—the orders table has a user_id column pointing at a row in the users table. When you sketch a data model, this is what you're drawing: users, orders, products, and who relates to whom. Aligning this diagram with engineers early saves a lot of rework later—"one user can place many orders" and "one order can contain many products" are two entirely different table structures, and changing between them is expensive.

Deployment and environments

The same code runs in three places: development (on your machine), staging (where everyone tests), and production (what users use). When something breaks, first ask which one: "broken in staging, fine in production" and "down in production" are completely different incidents. Before a full launch, think about gradual rollout: give it to a small slice of users first, and go wide only if nothing breaks; if it does, roll back to the previous version. The PM's job is the launch plan: when to release, to whom, what metric to watch, and the failure plan.

Six security basics

AI-generated code fails most often in these six spots. Give them a scan after every generation. Secrets don't go in code: API keys and database passwords belong in environment variables—never in frontend code, which is the same as publishing them. Permissions are checked on the backend: hiding a button on the frontend isn't permission control; the API itself must verify whether this person is allowed. All user input is untrusted: concatenating SQL and rendering HTML directly are both injection entry points. Only return the fields you should: an endpoint that returns a phone number and ID number together is the most common data leak. Money and stock are computed on the backend: any number the frontend computes and passes along can be tampered with. Deletion must be recoverable: soft delete first, and physical deletion goes through a separate flow. owasp-top10