What is a backend? A plain-English guide for people building with AI
What the backend of an app actually does, the six jobs it covers, how a single click travels through it, and how to describe one clearly to ChatGPT, Claude, Codex or Cursor.
Key Takeaways
- The frontend is what people see; the backend is what they trust. The frontend runs in the visitor’s browser and anyone can read or change it. The backend runs on a server you control, so it is the only place to keep data, secrets and rules.
- A backend is a bundle of jobs. Storing data, knowing who is signed in, deciding who may do what, running trusted code, doing work on a schedule, storing files and sending messages. Most apps need four or more of these.
- Permissions are the part that goes wrong. OWASP’s 2025 Top 10 ranks broken access control first and reports that every application in its test data had some form of it. Rules must be enforced on the server or in the database, never only by hiding buttons.
- Say what you need before the agent starts. Name the data, the sign-in method, the access rules and any scheduled work in your first prompt. An agent that discovers these halfway through tends to patch them into the browser.
- Free tiers are real but have edges. Supabase’s free plan pauses projects after a week without activity, and Firebase’s free Spark plan doesn’t include Cloud Functions. Read the limits before real users depend on your app.
Quick-Start Prioritization Framework
| If your app needs to… | Backend job | Typical tool |
|---|---|---|
| Remember things after a refresh, on any device | Database | Postgres, Firestore, MongoDB |
| Know who the user is | Authentication | Email code, password, Google sign-in |
| Show each user only their own data | Authorization | Server checks or row-level security |
| Charge a card or call an AI model with your key | Server endpoints | Serverless functions, API routes |
| Send a reminder at 8am with nobody online | Background jobs | Cron schedules, job queues |
| Accept photos or PDFs | File storage | Object storage buckets |
| Email a receipt or reset link | Email and notifications | Transactional email service, push |
AI coding tools are very good at making screens. Ask for a booking page and you get a polished form in seconds. Then you refresh the page and the booking is gone, or a friend signs up and sees your data. That gap is the backend. This guide explains what a backend is in plain words, breaks it into the jobs it does, follows one real request from click to database and back, and shows how to ask an AI agent for a backend so it builds the right thing the first time.
Frontend and backend in one paragraph each
Mozilla’s developer docs put it simply: client-side code (HTML, CSS and JavaScript in the browser) controls how things look and behave, and server-side code decides what information is sent, validates it, reads and writes databases and handles who is allowed in.
The frontend lives on the visitor’s device
When someone opens your app, their browser downloads your frontend code and runs it. That means they have a full copy. They can open developer tools, read every line, change values, and send any request your app could send. Anything in the frontend is public, including API keys you paste into it.
The backend lives somewhere you control
The backend is code and data on a server, or on a managed service that acts like one. The visitor can only talk to it through the doors you open, such as “create a booking” or “list my bookings”. Each door checks who is asking and what they are allowed to do before it touches data.
Why AI-built apps often skip it
A frontend demo looks finished without a backend. An agent asked to “make it save” may store data in the browser’s local storage, which lives on one device, disappears when the user clears their browser, and is invisible to every other user. It works in the demo and fails the first time two people use the app.
The seven jobs a backend does
“Backend” is a catch-all word. It is clearer to think of it as a list of jobs. Your app may need only some of them, but you should decide which ones on purpose.
1. Store data: the database
The database is the app’s memory. Bookings, users, messages, orders. Most backends use either a relational database such as Postgres, where data sits in tables with defined columns, or a document database such as Firestore or MongoDB, where each record is a JSON-like document.
2. Know who someone is: authentication
Authentication answers “who is this?”. Common options are a password, a one-time code sent by email, a magic link, or signing in with Google or Microsoft. After sign-in, the backend issues a session so the user stays signed in across pages.
3. Decide what they may do: authorization
Authorization answers “is this person allowed to do this?”. A customer may read their own bookings; an admin may read all of them. This is the job that causes the most real-world damage when it is missing. OWASP lists broken access control as the number one web application risk in its 2025 Top 10.
4. Run trusted code: endpoints
Endpoints (also called API routes or server functions) are small pieces of code the frontend calls by URL. They are where you do anything that needs a secret or must not be tampered with: charging a card, calling an AI model with your API key, calculating a price, or writing to the database after checking permissions.
5. Work when nobody is online: background jobs
Some work runs on a schedule or after the user has left: a daily summary email, cleaning up expired invites, retrying a failed payment notice. This needs a scheduler or a job queue on the backend, because the browser tab is closed.
6. Keep files: storage
Profile photos, receipts and uploaded PDFs go in object storage, not in the database. Storage needs its own access rules so one user can’t download another user’s files by guessing a URL.
7. Talk to people and services: email, push and webhooks
Sign-up confirmations, password resets and receipts need a transactional email service with a verified sending domain. Push notifications reach phones and browsers. Webhooks let other services, such as Stripe, tell your backend when something happens, like a payment succeeding.
Worked example: one click, traced end to end
Take a small booking app for a dog groomer. A signed-in customer picks Saturday at 10:00 and taps “Book”. Here is what a well-built backend does, in order.
- The browser sends a request to an endpoint, say POST /bookings, with the chosen time and the user’s session cookie. It does not send a user ID it made up; the server works that out.
- The endpoint reads the session and finds the user: customer 4182. If there is no valid session, it stops with a 401 error.
- It validates the input: the time is in the future, inside opening hours, and in a 30-minute slot.
- It checks the rule “a slot can be booked once” inside a database transaction, so two people tapping at the same moment can’t both win.
- It inserts the row into the bookings table with customer_id = 4182, taken from the session, not from the request body.
- It queues a confirmation email rather than sending it inline, so a slow email provider doesn’t make the button hang.
- It returns the new booking to the browser, which shows “Booked for Saturday 10:00”.
- Overnight, a scheduled job finds tomorrow’s bookings and sends reminders.
Where backends run: four common setups
You don’t need to rent and manage a physical server. These are the four patterns you will meet, roughly from most to least hands-on.
| Setup | What you manage | Good fit | Watch for |
|---|---|---|---|
| Your own server or container | Operating system, runtime, database, deploys, scaling | Long-running processes, unusual runtimes | Security patches and uptime are on you |
| Managed database + serverless functions | Function code, schema, environment variables across two or more services | Developers who want standard, swappable parts | Keeping keys and settings in sync across services |
| Backend-as-a-service (Supabase, Firebase, Appwrite) | Schema, access rules, and a separate frontend host | Apps whose logic fits the service’s building blocks | Free-tier limits; writing access rules correctly |
| All-in-one app platform | Mostly the app itself | Solo builders and agents doing the setup | How to export your data and code if you leave |
What a backend costs to start
Most services have a free tier that is enough to build and test. The edges matter once you have users.
Typical free tiers in November 2026
Supabase Free gives a 500 MB database, 50,000 monthly active users and 1 GB of file storage, allows two active projects, and pauses a project after one week of inactivity. Supabase Pro starts at $25 a month. Firebase’s Spark plan needs no card and includes 1 GiB of Firestore storage, 50,000 reads and 20,000 writes a day, but its pricing table lists Cloud Functions and Cloud Storage as not applicable on Spark; you move to the pay-as-you-go Blaze plan for those.
A rough budget for a small paid app
Here is simple arithmetic, not a quote. If you pair a $25-a-month backend service with a $20-a-month frontend host (Vercel Pro’s listed price), you start at about $45 a month before usage, email and domain costs. A single platform that includes hosting can come in lower, and a self-managed server can too, if you count your own time as free.
How to ask an AI agent for a backend
Agents follow the shape of the prompt. A vague prompt gets a frontend with fake data. A specific one gets tables, endpoints and rules.
Name the data
List the main things your app stores and their key fields, even roughly: “customers (name, email, phone), bookings (customer, start time, service, status, price)”.
Name the sign-in and the rules
Say how people sign in and who sees what, in plain words: “Customers sign in with an email code. Customers see only their own bookings. Staff see all bookings for today. Only the owner can change prices.”
Name the outside world
Say which emails go out and when, what runs on a schedule, and which services you connect: “Send a confirmation when a booking is made and a reminder at 18:00 the day before. Take payment with Stripe.”
Ask the agent to prove it
End with a test: “Create two customer accounts and show me that neither can see the other’s bookings, even by changing the ID in the request.” This catches the most common backend bug before your users do.
Common mistakes
These show up again and again in apps built quickly with AI help.
Secrets in the frontend
An OpenAI, Stripe secret or database key pasted into frontend code is readable by every visitor. Keep secret keys in the backend’s environment variables and call them from endpoints.
Trusting IDs from the browser
If an endpoint reads “userId” from the request body and returns that user’s data, anyone can change the number and read someone else’s records. OWASP calls this an insecure direct object reference. Take the user from the session instead.
Hiding buttons instead of enforcing rules
Removing the “Delete” button for non-admins is good design but not security. The delete endpoint itself must check the role.
No plan for undo
Agents can drop a column or overwrite rows. Before you let one change a database with real data, know how backups and restores work on your platform.
If you’d rather not assemble it yourself
If you’d rather not wire these pieces together yourself, Floot is one option: it gives each app a Postgres database, sign-in, endpoints, scheduled jobs, file storage, email and hosting in one project, and ChatGPT, Claude, Codex or Cursor can set it up through Floot’s MCP server. It is free to start.
Frequently Asked Questions
Do I need a backend for a simple website?
Not if every visitor sees the same content and nothing is saved, such as a portfolio or landing page. Static hosting is enough. Once you need sign-in, saved data, payments or emails, you need a backend.
Is a database the same thing as a backend?
No. The database is one part. A backend also decides who is signed in, enforces who can see what, runs code that uses secret keys, sends email and does scheduled work.
Can ChatGPT or Claude build a backend for me?
They can write the code, and with an MCP connection to a backend service they can also create tables and deploy it. You still need to decide the data, sign-in method and access rules, and check them with two test accounts.
What is the difference between an API and a backend?
An API is the set of doors the backend exposes, such as POST /bookings. The backend is everything behind those doors: the code, the database and the rules.
What does serverless mean?
Your code still runs on servers, but you don’t manage them. You upload functions, the platform runs them when a request arrives and bills by usage. It suits short request-and-response work; long or scheduled work needs a job system alongside it.
Is it safe to keep data in the browser’s local storage?
For preferences like dark mode, yes. For anything that must survive a device change or be shared between users, no. It lives on one device, can be cleared, and can be edited by the user.
Sources
- MDN Web Docs, Introduction to the server side, 2026 https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Introduction
- OWASP, A01:2025 Broken Access Control, 2025 https://top10.owasp.org/2025/A01_2025-Broken_Access_Control
- Supabase, Pricing, 2026 https://supabase.com/pricing
- Firebase, Pricing plans, 2026 https://firebase.google.com/pricing
- Vercel, Pricing, 2026 https://vercel.com/pricing
- Stripe, Receive Stripe events in your webhook endpoint, 2026 https://docs.stripe.com/webhooks