What an app backend is
An app backend is the part of the product that does not live on the user phone: an API that receives the requests, a database where the data stays, and an auth service that decides who is allowed to see what. The app on the phone is not the decision maker and only shows what the backend permitted, which is why a perfectly healthy app can do nothing at all once the server stops answering.
- Lesson 6 of 8
- Beginner
- Free, no signup
Two faces, one backend
The app on the phone
the visible half of the product, and the half the user judges it by
- Builds the screen and takes the user input
- Sends the request and shows the answer
- Anything inside it is readable
The site or admin panel
the same data, through another door and usually for another person
- Sees the orders and changes their status
- Has more access, so its rules are separate too
Both talk to one backend, and neither one decides anything by itself
The backend
where the decision is made and the data actually stays
- API: the only door open from outside
- Database: orders, users, messages
- Auth service: which user each request belongs to
- File storage: images and attachments, addressed from the database
This drawing is simplified: in a real product a cache layer and a push notification service usually sit beside these same pieces.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
What is a backend, and why is half the app there?
A backend is the half of an app the user never sees, and without it the app is only a photo album. Anything that has to be shared between several people, has to survive the app being deleted, or must not be in the user own hands, lives there rather than on the phone.
One example is clearer than any definition: the order list of a shop. If that list is stored on the phone, it disappears when the phone is replaced, it is not there on the same person tablet, and anyone who opens the app files can change the numbers. Those three sentences are the whole reason a backend exists.
The app on the phone does three things in practice. It builds the screen, it takes the user input, and it sends a request. Deciding is not its job. That sounds obvious and it is the first rule broken in new projects: the app calculates the discount and sends the final amount, and then it turns out anyone can send that same request with whatever number they like.
So the honest division is this: the app displays, the backend decides. If you have read how an app works, this is the same border seen from the server side this time.
What sits inside a backend?
A backend is not one program but several pieces, each doing one job, usually sitting together on one server.
The first piece is the API, the door the app comes through. The app calls an address, sends data, and gets an answer that is usually JSON. What each address expects and what it returns is the contract between app and server, and what an API is opens that contract fully.
The second piece is the database. The place where orders, users and messages are actually written and where they stay after the server restarts. The app should never connect to the database directly, because then the database password has to live inside the app, and anyone who opens the app file has it.
The third piece is the auth service. Its job is not only to say whether the password was right; its job is to attach itself to every later request and say which user this request came from. Without that answer the server has no way of knowing whose order list was just asked for.
The fourth piece, always thought about too late, is file storage. Profile pictures and attachments do not usually sit inside the database; they have their own place and only their address is stored in the database. Whether that address is public or signed and temporary is a security decision in itself.
All of this runs on the thing explained from underneath in how the internet works: a machine that is never switched off, waiting on an address.
When someone says the server is down, what actually happened?
"The server is down" almost never means the computer was switched off. Three completely different situations gather under that one sentence, and each has a different cure.
The first: the request never reached the server at all. The user connection was gone, the domain name was not translated into an address, or the app is on a network that does not hand out that address. The server is entirely healthy here and has no idea anyone came looking.
The second: the server answered and its answer was an error. The status code matters here and it has two families. A five hundred means the problem is on the server side; a four hundred means the request itself was wrong. An app that shows both as "server is down" sends the user on a wild goose chase; a 401 means sign in again, a 500 means sit and wait.
The third, more common than either: the server did answer, but far too late. Something in the middle ran out of patience and cut the connection while the program was still working. From the app side that is indistinguishable from a server that is off.
The third is where teams lose the most time, because the patience number is usually written somewhere nobody goes looking. PHP own manual, describing the request_terminate_timeout setting, says it is "the timeout for serving a single request after which the worker process will be killed", and adds plainly that this option should be used when max_execution_time did not stop script execution. Which means two numbers live in two separate files, and the smaller one has the last word.
The practical consequence for anyone writing an app: give every request you send a stated timeout, sort error responses by status code rather than by their text, and write a different behaviour for each family. That takes ten minutes in the first hour of a project, and if it is skipped it comes back months later as reports saying "the app does not work", none of which can be reproduced.
One request, and the four places it can die
The app sees all of these the same way unless you make it tell them apart.
-
1
The user network
The request never left the phone. The server has no idea.
-
2
Domain name lookup
The name was not turned into an address. The site is up for some people and not others.
-
3
A server side error
An answer came back with a five hundred code. The app should say try again later.
-
4
The timeout ran out
The program was still working and a number in a config file ended it first.
This order is not fixed: a request can pass several stations cleanly and fall at the last one.
Buy a ready made backend or write your own?
There is a third route, and most small teams end up on it: a backend as a service, a service that hands you the database, the sign in and the file storage ready made so you bring up no server at all. Google Firebase and Supabase are two well known examples.
What you are buying is written plainly in their own documentation. The Firestore security rules getting started page says these rules let you focus on building a great user experience "without having to manage infrastructure or write server-side authentication and authorization code". That single sentence explains the whole saving: work that usually takes weeks becomes one rules file.
What you give in exchange is on the same pages and gets read less. Once the middle server is gone, the app talks straight to the database, and the only thing standing between your data and a hostile user is that rules file. The Firebase documentation puts it in exactly that tone: security rules are defined outside your app, so clients are not responsible for enforcing security. That is a reassuring sentence until you remember what follows from it, which is that any mistake in that file is a mistake no other code will catch.
Two small notes on those same pages turn out expensive later. First, Firestore shows its simple example rule sets and writes underneath them that while these rules are valid, they are not recommended for production applications. Second, the server client libraries bypass all the security rules and authenticate another way. Meaning the code you write on your own server is exempt from the rules you wrote for the app.
The lock in question is better heard from them than from us. Supabase writes on its architecture page that it does not abstract the Postgres database and you access it with full privileges, and in its principles that to avoid lock in it makes it easy to migrate in and out, which is why it uses existing standards like pg_dump and CSV files. That is a vendor claim about its own product, not a measurement of ours; we have not run a real migration off either one and cannot tell you how long it takes in practice.
Our position is simple. For an app one person is writing that has to be on somebody phone next month, a ready made backend is the right choice, and fussing over writing it yourself buys only a few months of delay. For a product with money logic in it, a point arrives where that logic has to run on your own server, and it is better to know that on day one than to discover it halfway.
A ready made backend against your own
The managed service
- Sign in, database and file storage work from day one
- You write no server side authentication or authorization code
- All data security gathers into one rules file
- The app talks straight to the database
Your own backend
- Every money decision runs on a server you hold
- The API is your contract and you shape it yourself
- The first weeks go on infrastructure instead of screens
- When the server falls over at night, somebody has to wake up
Neither column wins; the right one depends on how much money logic the product carries and who is on call.
Ask yourself these before you choose
A backend decision is almost never a purely technical one. Answer the four questions below seriously and the answer shows itself.
One: if somebody sends a request tomorrow that your app never sends, what happens? If your answer is "our app does not do that", you have not thought about the backend yet. Somebody working against your app does not have to use your app.
Two: which numbers must the user not get to set? Price, stock, score, role. Any of those arriving from the app side is, in practice, user input.
Three: if you left this service tomorrow, what comes with you? Not as an accusation against the vendor, as an exercise. The answer usually shows how much of your product is actually yours.
Four: who brings the server back up at three in the morning? If the answer is nobody, the managed service is more expensive and counts as the cheap option.
And one piece of advice unrelated to all four: before writing the first line of backend, draw the shape of the data on paper. The tables or collections, their fields, and who each row belongs to. Changing the shape of the data after a thousand users have data in it is more expensive than anything else in the project. If you have no team and the decision has grown larger than you, the RGB app service page says how we take this exact stage forward.
Have these on paper
- The list of tables or collections with their fields
- Which user each row belongs to
- The numbers only the server is allowed to set
- The app behaviour for each error family, separately
These mean you are not ready yet
- The database password is written somewhere inside the app
- The app calculates the final amount and sends it
- No request has a stated timeout
- Nobody knows what would remain if you left the service
The fast path, with AI
What models are genuinely good at in backend work today is not writing code, it is producing the specification. Get the shape of the data and the access list out of a model before any code and read it yourself, and two thirds of the common mistakes die before they are born, whoever writes the code afterwards.
- Write what the product should do in plain language, with no technical terms. Who signs in, what they see, what they create and what they change.
- Run the recipe below with a strong model rather than a cheap one. This pass is judgement, not mechanical work; our current pick is on the AI section of the site.
- Read the access table line by line. It is the one place a non programmer can also spot the mistake, because it is written in sentences rather than in the syntax of a rules language.
- Delete any row you cannot explain the need for in one sentence, then ask again. Models tend to build the table more complete than your need.
Copy-ready recipe
I am designing the backend of this product:
{plain description of the product in ordinary language}
Write no code. Give me three things and no more:
1) The data shape: the list of tables or collections, the fields of each with their types, and which user each row belongs to. Mark every field only the server may write with the label "server only".
2) The access table: for every table and every user role, four columns for read, create, update and delete. Fill each cell with one complete sentence, such as "only rows where the user id equals the row owner". Write no rules syntax and no code.
3) The list of things the client must never get to set, with a one line reason for each.
Strict rules:
- Write no service name, no library name, no version number and no price.
- Add no field that is not in the description above; where you see a gap, do not fill it, write it in a separate list called "questions I should ask".
- Where you do not know, say you do not know. Do not guess.Before you trust the output: Read the access table yourself before it turns into any code, and pause on three things. First, any cell containing the sentence "all signed in users": that is almost never the right answer, and it is exactly what the Firestore documentation warns about with its own simple example rules. Second, any field the model did not mark "server only" that decides money or role. Third, take the "questions I should ask" list seriously; it is the list of things somebody else will guess for you later if you do not answer them.
AI in this kind of work
The backend is where AI help carries the largest gain and the largest risk at once. The gain is in design: the data shape, the access table, and rereading rules you wrote yourself. The risk is that the very thing you hand a model so it can help is usually a connection string or a service key.
Tools that actually help
- Claude Good for the design pass above and for rereading the access table. Iran is on neither of Anthropic two supported-countries lists. We read that on Anthropic own page rather than measuring it.
- Claude Code Once the backend grows past one file, a command line tool works on the project itself and reads the server log too, which is exactly what the third error family in this lesson needs. It runs on the same Anthropic account, and Iran is not on the list.
- Gemini Cost effective for summarising a documentation page and for simpler passes. Google own page says the Gemini web app runs in over 230 countries and territories, and Iran is not on that list.
Where it backfires
The first risk is simple and everybody does it once: pasting the database connection string or a service key into a prompt. A secret that has gone to an external service is no longer a secret, and unlike an ordinary API key, a database connection string reaches all the data directly. The simple habit is to never copy the config file and to write the name of the variable instead of its value.
The second risk is subtler and comes straight out of Firebase own documentation: the server client libraries bypass all the security rules and authenticate instead through Google Application Default Credentials. Meaning that if you ask a model for code and it writes a server side example, that code is exempt from the rules you spent hours on, and you will see no error at all. Every time you take backend code from a model, check this first: which library is this piece talking through.
Sources: Firebase: get started with Cloud Firestore Security Rules Firebase Security Rules: how they work and where they are defined Anthropic: supported countries Google: where Gemini Apps are available
Where this advice stops
This lesson explains the shape of a backend, not how to build one. Three things deliberately left out: scaling when a few thousand people work at once, the real cost of either route, and the design of the database itself. We give no cost number because it depends on usage and any number written here is wrong tomorrow. And a more honest limit: we have not migrated a real product from a managed backend service onto our own server, so everything said about how hard that is repeats the vendors own words rather than a measurement of ours.
From our own work
The third case in this lesson, the server answered but far too late, can be shown on the very server that just handed you this page. We opened both config files today. In /www/server/php/85/etc/php.ini line 404 says max_execution_time = 900, and in /www/server/php/85/etc/php-fpm.conf line 40 says request_terminate_timeout = 180. So on a site whose PHP settings say fifteen minutes, what actually ends the request is three, and that number lives in a different file nobody usually opens. For an app talking to such a server it means a heavy operation can end in the third minute with no message from the program at all, and the user only sees "the server is down". That single mismatch is the first place we look when we investigate a slow API.
Real follow-up questions
Is an app without a backend possible at all?
Yes, and more often than you would think. A calculator, a flashcard app, offline tools and any app whose data belongs to that one phone need no backend. The moment one becomes necessary is where two devices have to see the same thing, or where the data has to survive the app being deleted.
Can the app use the same backend as the website?
Usually yes, and it is usually the right choice, but not through the same doors the website uses. A website works with cookies and forms, while an app needs an API that works with a token and answers in JSON. Meaning the same database and the same logic, with a new entry layer.
Should we build the app first or the backend first?
Neither. Write the contract between them first, meaning the list of addresses with the input and output of each. After that two people can work in parallel and the moment of connection is not an argument; without it, one side is always waiting for the other.