Frontend, backend, database, hosting
Let's go one layer deeper, using our example: a user clicks "Save profile."
. The visible app, running in a web browser or as a mobile app. It draws the form, notices the click, and collects what the user typed. By design it's untrusted: anyone can open it, inspect it, and change it. So its job is to look good and feel responsive, not to enforce anything important.
. When the button is clicked, the frontend sends the data to the backend — code running on a server. The backend checks the user is logged in, validates the data ("is this actually an email address?"), applies the business rules, and only then saves it. This is where trust lives, because users can't tamper with it.
. The backend hands the data to the database to store. Not a magic box — think of it as a set of very strict spreadsheets (called tables) that can be searched instantly and never forget. Tomorrow, the backend reads the profile back out to show it again.
Hosting. In production, none of this runs on your laptop. It runs on rented computers from a hosting provider like Cloudflare, Vercel, or a cloud platform. Hosting is what makes your app reachable at a real web address instead of only on your own machine.
A useful instinct: when something breaks, ask which layer. "The button does nothing" is frontend. "It saves the wrong thing" is usually backend. "It forgot my data" points at the database. Naming the layer is half of fixing the bug — and half of writing a the AI can act on.