What are the basic pieces every app is made of?
Every app, no matter how simple or ambitious, is built from the same small set of pieces: something the user sees and clicks (the frontend), something that runs the logic behind the scenes (the backend), somewhere the data lives so it survives after the browser closes (the database), an agreed way for those pieces to talk to each other (the API), and the computers that keep the whole thing running and reachable on the internet (hosting). You do not need to become an engineer to vibe code well, but you do need to recognize these five pieces by name. That is the only way to tell an AI agent what to change, and the only way to notice when it has quietly skipped one.
I'm Mahmoud Zalt, an independent senior AI systems architect. I have shipped production software since 2010, that is 16 years, and I founded Sista AI (sistava.com), where I run a workforce of autonomous AI agents in production, not demos. I wrote this because the single biggest reason non-technical builders get stuck with an AI agent is not a bad prompt. It is not knowing what they are looking at when the agent describes its own work.
The five pieces, in plain English
Strip away the framework names and the buzzwords, and almost every app on the internet is the same five parts wired together. Learn these once and every conversation you have with an AI agent about your project gets easier.
| Piece | What it actually does |
|---|---|
| Frontend | What the user sees and clicks in the browser or app: the pages, buttons, forms, screens |
| Backend | The server-side program that runs your logic and decides what happens when a request comes in |
| Database | Where data is stored so it is still there after the browser closes or the server restarts |
| API | The fixed, agreed set of messages the frontend and backend use to talk to each other |
| Hosting | The rented computers where all four of the above actually run so the public can reach them |
Nothing about this list is specific to any framework or language. Whether an AI agent builds you a React app with a Node backend, or a completely different stack, these five roles still exist somewhere. Your job is not to know how to build each one. It is to know which one you are talking about when something works, or does not.
Frontend and backend are two separate programs
The most common confusion for a first-time builder is treating "the app" as one thing. It is not. The frontend and the backend are two different programs, running in two different places, and an AI agent needs to be told which one you mean.
The frontend runs on the user's own device, inside their browser or their phone. The backend runs somewhere else entirely, on a server you control, out of the user's direct reach. This split is not a technical formality, it is a safety boundary. Anything sensitive, a password check, a payment calculation, a private business rule, has to live in the backend. The frontend is public by nature: anyone can open your app's developer tools and read everything sitting in it. If you ever ask an AI agent to "add a secret API key to the app" without specifying where, there is a real chance it lands in the frontend, where every visitor can see it.
Once you can picture these as two separate programs having a conversation, half of the mystery around "how does my app actually work" disappears.
The API is a contract, not a place
The frontend cannot reach into the database and grab data directly, even though it might feel that way when you are clicking around a finished app. Instead, it sends a request to the backend through the API: a fixed, agreed list of allowed messages, things like "give me this user's orders" or "save this comment."
Think of the API as a restaurant menu. The frontend, playing the customer, can only order dishes that are actually on the menu. It cannot walk into the kitchen and cook something itself. The backend, playing the kitchen, decides how each order gets prepared and what comes back out. This is why, when an AI agent adds a new feature, it usually has to touch two places at once: it adds a new "dish" to the backend's menu, and it teaches the frontend how to order it. If your agent only changes one side, the feature will look finished in the interface but fail the moment it tries to talk to the server.
The database remembers, hosting runs the whole thing
The database is your app's memory. Close the browser tab, restart the server, come back a week later, and whatever was saved to the database is still sitting there waiting. Without it, every comment, every account, every order would vanish the moment the page reloaded.
Hosting is simpler than it sounds: it is just the rented computers where your frontend, backend, and database actually live so that people other than you can reach them over the internet. Before you deploy, your app only exists on your own laptop. Hosting is what turns "a project on my machine" into "a real product with a URL." Which specific tools fill each of these five slots (which hosting provider, which database engine) is a separate, later decision. What matters first is understanding that each slot exists and has a job.
Trace one click through all five pieces
The fastest way to make this concrete is to follow a single, boring action from start to finish. Say a user types a comment and hits save. Here is everything that happens, piece by piece.
- Frontend: packages up the text the user typed and sends it off.
- API: carries that request over to the backend as one of its agreed messages.
- Backend: checks that the user is actually allowed to comment, then processes the request.
- Database: stores the comment permanently and confirms it was saved.
- Frontend, again: shows the newly saved comment back on the screen.
All five steps run on top of hosting, the rented computers underneath everything. Every feature in every app you will ever vibe code is some variation of this exact loop: an action starts in the frontend, crosses the API, gets handled by the backend, touches the database if it needs to remember anything, and comes back to the frontend to be shown. Once you can see that loop, a bug stops being a vague "the app is broken" and becomes a specific, answerable question: which piece dropped the message.
Why this map matters once an AI agent is doing the building
You might reasonably ask why any of this matters if the AI is writing the code. Here is the honest answer: the agent knows these pieces intimately, but it does not know your intent unless you can point at the right one. Vague requests get vague, sometimes wrong, results.
The most common mistake I see is a builder describing a symptom in frontend language ("the button doesn't work") when the real problem is three pieces away, in the backend or the database. The AI agent will often go fix whatever you pointed at, confidently, even if it is the wrong piece, because it is following your instructions rather than diagnosing the whole system on its own. Knowing the five pieces lets you ask better, narrower questions: "is this a frontend display issue or is the backend not saving the record?" That single sentence can save you an hour of the agent patching the wrong layer.
The second common mistake is not noticing when the AI's own summary quietly skips a piece. If you ask for a feature that needs to remember something between visits, and the agent's explanation never mentions the database, that is worth a follow-up question before you assume the feature is actually done. This is the exact habit The Vibecoder's Handbook tries to build early, before you are deep into a project and guessing at what your own app is made of.
Do this now: pick one feature from your own project, and write its round trip in a single sentence, naming all five pieces the way the comment example above does. If you cannot fill in one of the five, that is exactly the piece to ask your AI agent about next.
Frequently Asked Questions
Do I need to learn to code to understand these five pieces?
No. Understanding what the frontend, backend, database, API, and hosting each do is a vocabulary problem, not a coding problem. You are learning to recognize which piece is responsible for what, so you can talk to an AI agent precisely. Actually writing any of these pieces by hand is what the agent is for.
What is the difference between the frontend and the backend in simple terms?
The frontend is what runs on the user's own device, inside their browser, the part they see and click. The backend runs elsewhere, on a server you control, and handles the logic and rules the user never sees directly. Anything sensitive belongs in the backend, because the frontend is visible to anyone who opens it.
Why can't the frontend just talk to the database directly?
Because that would remove any control over what gets read or changed, and expose your data structure to the public. The API sits in between as a fixed menu of allowed requests, so the backend can check permissions, apply rules, and only ever expose exactly what it chooses to.
What actually breaks most often when a feature doesn't work?
Usually the frontend looks fine and the real problem is one layer back: the backend never received the request, or received it but failed to save it to the database. Tracing the click through all five pieces, the way described above, is the fastest way to find which one dropped it.
Is hosting something I need to worry about early on?
Not while you are still building and testing locally on your own machine. Hosting only becomes relevant once you want other people to actually reach your app over the internet, at which point it is simply a decision about which rented computers your five pieces will live on.
Start by naming the pieces
None of this requires you to become a software engineer. It requires you to stop treating your app as one mysterious blob and start seeing it as five pieces with five separate jobs, so you can talk to your AI agent like someone who actually understands what they are building.
This article covers the short version. The full chapter in The Vibecoder's Handbook maps out the pieces for your own project, and walks through naming them before you write a single prompt. Read the free chapter ->
