What is the difference between frontend and backend?

Frontend and backend is the most useful distinction to grasp about any app, because so much else hangs off it: what visitors can see, where your data lives, and above all where the safety of your app is decided. Once the line is clear in your head, a lot of otherwise confusing advice suddenly makes sense.

Where each one runs

The clearest way to hold the difference is to think about where each part physically runs. The frontend runs on the visitor's own device, inside their browser. When someone opens your app, their browser downloads the frontend and runs it right there on their phone or laptop. The backend runs somewhere else entirely, on a server you rent, which the visitor never touches directly. This matters more than it first appears. Because the frontend runs on the visitor's device, they can, if they choose, look at it, read it, and tamper with it. Because the backend runs on a server they cannot reach, it is the only place you can put things you need to keep private or trust to be true. The whole discipline of building a safe app comes from putting the right work on the right side of this line.

What each half is responsible for

The frontend is responsible for presentation and interaction: showing your pages, laying out your content, responding when someone clicks or types, and sending their actions off to the backend. It is the dining room, concerned with how things look and feel. The backend is responsible for truth and work: storing and fetching data from the database, deciding what is allowed, checking logins, taking payments, and doing anything that must be reliable and cannot be left to the visitor's device. It is the kitchen. A booking, for example, is displayed by the frontend but actually made and recorded by the backend, because you cannot trust the visitor's browser to be the final word on whether a slot is free. This division, show in the front, decide in the back, is the backbone of how apps are put together.

Why the line is where safety lives

The single most important consequence of this split is about security, and it trips up a great many AI-built apps. Anything in the frontend can be seen and altered by anyone using the app, because it runs on their device. So a secret key placed in the frontend is not secret; a rule enforced only in the frontend is not enforced, because a determined visitor can simply bypass it. Real protection has to live in the backend, where the visitor cannot reach it. The classic failure is an app that checks who you are or hides a key in the frontend, looking perfectly fine, while the backend does not actually enforce anything, so the protection is theatre. Knowing that trust must live in the backend is the mental tool that lets you ask the right question: is this safety real, or is it only in the part the visitor controls.

Which parts you actually built

When you build with an AI tool, you are usually working most directly with the frontend: the pages you can see and rearrange are the visible half. But if your app remembers anything or has logins, the tool also built you a backend, often quietly, around a database like Supabase and some server-side rules. Many people are surprised to learn how much of their app is backend they never consciously touched. This is worth knowing for a plain reason: when someone asks whether your app is secure, or where your data is, or what happens under load, they are asking about the backend. You can judge the frontend just by using the app, but the backend is invisible from the outside, which is exactly why it deserves a deliberate look rather than an assumption that because the front looks finished, the back must be too.