You have picked up the vocabulary. You know that a frontend is what people see, a backend is the part they don't, a database is where information lives, and an API is how two systems talk. But knowing the words and picturing how they connect are two different things. Most people can name the parts of a car engine and still have no idea what happens when they turn the key.
This post fixes that. We are going to take one small, ordinary app and trace what actually happens inside it, step by step, as a real person uses it. By the end you should be able to close your eyes and see the pieces of your own app handing work back and forth.
The example app we'll tour (and why it's generic on purpose)
Let's invent an app. We'll call it BookNook, a made-up tool where a solo builder lets customers book a 30-minute consultation and pay a deposit. BookNook does not exist. It is not based on any real product, company, or codebase. We invented it purely to teach, so nothing here reveals a proprietary structure or a "correct" way anyone else does it.
That is the point of using a generic example. Real apps come loaded with quirks, brand names, and one particular tool's menu layout, and those details get in the way of seeing the shape underneath. A teaching app lets us keep the shape and drop the noise.
BookNook does three things:
- Lets a visitor create an account and log in.
- Lets a logged-in visitor pick a time slot and book it.
- Charges a small deposit when they book.
That is enough to touch every layer you will meet in almost any app you build with AI or no-code tools. If you want the plain-English definitions of any term below, keep the understand the app you built with AI guide open in another tab. It explains the terms used in this walkthrough.
The map: every part on one page
Before we follow anyone through the app, here is the whole thing laid out. Think of it as a floor plan.
| Part | What it is | BookNook's version |
|---|---|---|
| Frontend | What the user sees and clicks in their browser or phone | The booking pages, the login form, the calendar |
| Backend | The code that runs on a server, out of sight, and makes decisions | The logic that checks passwords, saves bookings, and talks to the payment service |
| Database | The organized store where information is kept between visits | The tables of users and bookings |
| Third-party service | An outside company's system your app calls for a job you don't build yourself | The payment processor and the email sender |
Four parts. Almost every app you have built or will build is some arrangement of these four. The frontend, backend, and API explained post goes deeper on the first two and the connective tissue between them, and where your app's data actually lives does the same for the database.
A quick note on the word server. When people say the backend "runs on a server," they mean a computer somewhere else, owned by a hosting company, that stays on and waits for requests. Your laptop is not it. The database usually lives on a server too, sometimes the same one, often a separate one.
Now let's put a person in the building and watch the parts wake up.
Journey 1: a user signs up and their data is stored
Meet Dana. Dana lands on BookNook and wants to create an account. Here is every handoff, in order.
1. Dana fills in the form (frontend). Dana types an email and a password into two boxes and clicks "Create account." Those two boxes and the button are the frontend. At this moment nothing has been saved anywhere. The information exists only on Dana's screen.
2. The frontend sends the details to the backend (over an API). When Dana clicks the button, the frontend packages up the email and password and sends them across the internet to the backend. That send-and-receive channel is the API. Picture the frontend handing a sealed envelope to a courier and the backend being the office that opens it.
3. The backend checks the request. The backend asks some questions before it does anything. Is this a real email address? Is the password long enough? Is there already an account with this email? This is the app "making decisions," and it happens in the backend precisely because you don't want that logic sitting on the user's screen where anyone could poke at it.
4. The backend stores Dana's data (database). If the checks pass, the backend writes a new row into the users table in the database: Dana's email, a scrambled version of the password (a good backend never stores the raw password), and the date. The database is the part that remembers. Close the browser, come back next week, and the row is still there.
5. The backend replies, and the frontend updates. The backend sends a short answer back across the API: "done, account created." The frontend reads that answer and shows Dana a welcome screen.
Five steps, four parts, one new user. Notice that the frontend never touched the database directly. It asked the backend, and the backend did the writing. That separation is a pattern you will see everywhere, and it is there on purpose, so that the rules live in one guarded place.
Journey 2: a user triggers an action that calls an outside service
Now Dana is logged in and wants to book a slot and pay the deposit. This journey adds a new character: a third-party service. We will keep this at the conceptual level. The goal is to see the shape of the handoff, not to wire up a real payment integration.
1. Dana picks a time (frontend). Dana clicks a slot on the calendar and a "Pay deposit" button appears. Still just the frontend.
2. The frontend asks the backend to start a booking (API). The click sends a request to the backend: "Dana wants the 2pm Thursday slot."
3. The backend checks the slot is still free (database). The backend looks in the bookings table to make sure nobody grabbed 2pm Thursday a second ago. This read is why the database matters even when Dana isn't saving anything new yet.
4. The backend calls the payment service (third-party service, over an API). Here is the new move. BookNook does not process card payments itself. Building and securing that is a specialized job, so the backend hands it to an outside company. It sends a request to the payment service's API that says, in effect, "please collect a deposit from this customer for this amount." The payment service handles the sensitive card details on its own systems. BookNook's backend never sees or stores the raw card number, which is exactly what you want.
This is the single most important idea to take from BookNook: your app talks to outside services the same way your frontend talks to your backend, through an API, by sending a request and waiting for an answer. An API is not one specific thing in one specific place. It is the pattern of one system asking another to do a job.
5. The payment service answers. It replies to the backend: "payment succeeded" (or "declined"). If it succeeded, the backend writes the confirmed booking into the bookings table.
6. The backend calls a second outside service to send a confirmation email. Sending reliable email is another job most builders hand off. So the backend makes one more API call, this time to an email service: "send Dana a confirmation for 2pm Thursday." Same pattern again: request out, answer back.
7. The backend replies to the frontend, and Dana sees "Booked." The loop closes. Dana gets a confirmation on screen and, a moment later, an email in her inbox.
One click from Dana, and the backend quietly coordinated a database, a payment company, and an email company. She saw none of it. That invisibility is the job working correctly.
How the parts hand off to each other
Step back from the two journeys and a rhythm appears. Almost every handoff in BookNook is a version of the same three-beat move:
- A request goes out. One part asks another to do something.
- The receiver does its one job. The backend decides, the database stores or fetches, the payment service charges.
- An answer comes back. The result travels the reverse direction so the next part can continue.
The frontend requests from the backend. The backend requests from the database and from outside services. The answers flow back the other way. Nothing important skips a layer. The frontend never reaches straight into the database, and it never calls the payment service directly. Everything routes through the backend, because the backend is the one place you can enforce the rules and hold the secrets.
If you can hold that rhythm in your head, you can reason about parts of your app you have never looked at. When something breaks, you can ask "which handoff failed?" instead of staring at the whole thing at once. That single question is the start of debugging, and it is a lot easier to answer once you have a map. (If some of what your AI tool generated looks strange when you go hunting, reading warning signs in AI-generated code can help you tell "unusual but fine" from "worth a closer look.")
A brief, honest note on the payment step. We kept it conceptual on purpose. Payments, logins, and anyone's personal data are the areas where a small mistake has real consequences. Handing card processing to an established payment service, rather than storing card numbers yourself, is the standard reason apps do it that way. When you move from a teaching map to your actual app, treat the exact wiring of payments and account security as the moment to slow down and, past a simple deposit form, to bring in a qualified professional. This is educational, not legal or security advice for your specific setup.
Now sketch your own app's version of this map
Reading a map is useful. Drawing your own is where it sticks. Here is a short exercise. Grab paper or any drawing tool and give yourself fifteen minutes.
- Draw four boxes: frontend, backend, database, outside services. Leave room between them.
- Fill in the frontend box. List the main screens a user of your app sees. The login page, the main list, the settings page, whatever yours has.
- Guess what the backend does. For each screen, write one sentence: "when the user does X, the backend probably has to Y." You don't need to be right. You are building intuition.
- List what lives in the database. What does your app need to remember between visits? Users, orders, posts, uploaded files? Each of those is likely a table.
- Circle every outside service. Do you send email? Take payments? Use an AI feature that calls another company's model? Text messages? Each of those is a third-party service your backend calls over an API. Draw an arrow from the backend to each one.
- Trace one real journey. Pick something a user actually does in your app and follow it, box to box, arrow to arrow, the way we followed Dana. Where does it start? What hands off to what? Where does the answer come back?
Do not worry about being accurate on the first pass. The value is in noticing which handoffs you can picture clearly and which ones are still fuzzy. The fuzzy ones are your reading list. Keep the sketch. As you learn more, you will correct it, and a corrected map is one of the best signs that you are starting to own what you built.
The Understand what you built hub is organized to help you fill in exactly those boxes, and any word above that stayed slippery is defined in the glossary, which is worth saving as a reference.
In Plain English
What this means: Your app, however it was generated, is almost certainly some arrangement of four parts, a frontend the user sees, a backend that decides, a database that remembers, and outside services that handle specialized jobs, all passing work to each other with the same request-and-answer move.
Who this helps: A solo builder who has learned the vocabulary but still can't picture how their own app's pieces connect and hand off.
When to use it: Reach for this map when something in your app breaks and you need to narrow down where, when you are deciding what you can safely change, or any time an explanation online assumes you already know how the layers fit together.
What to do next: Do the sketching exercise above for your own app. Even a rough, wrong-in-places drawing turns the abstract words into something you can point at and reason about.
Your next step
You now have a worked example to copy from. Open a blank page and sketch your own app's map, using the Understand what you built hub as a guide for the parts you are unsure about, and save the finished sketch alongside the glossary so both are there the next time you need them. When you are ready to go one layer deeper on any single box, the understand the app you built with AI guide is the place to start.
Kodbe is an independent commercial publication about maintaining and owning software built with AI or no-code tools. It is not affiliated with Kodbe Inc, Kodobe, Kodable, or Kodu.