Course A · Module A4 Build · Lesson 12 of 17

Anatomy of an App

Six plain-English parts. Once you know their names and jobs, nothing in Course B will be a fog.

~10 min · No tools needed · Prereq: A11 completed

When the AI builds you an app, it's assembling six standard parts — whether you can see them or not. Right now those parts are invisible, so when something goes wrong (or a developer uses a term) you have no map. This lesson's single win: you'll leave with a clear mental map of every part of a web app, so Course B's hands-on work starts from understanding, not guesswork.

The six parts, in plain English

Frontend What users see and touch. Every button, form, screen, and color. When you open an app in your browser, you're looking at the frontend. Built with HTML, CSS, and JavaScript — but Lovable/Bolt generate all of that for you.

Backend The logic and rules, running on a server. When you click "Submit," something decides what to do with your data — validate it, call an AI, save it, send an email. That decision-making lives in the backend, out of sight.

Database Where data lives. All the users, orders, messages, and records your app needs to remember between visits. Think of it as a very structured spreadsheet that the backend can read and write instantly.

Hosting Where the app runs. Someone's computer has to be switched on, connected to the internet, and serving your app 24/7. That computer is a hosting provider — Vercel, Netlify, Supabase, or similar. Lovable handles this for you automatically.

APIs How apps talk to each other. When your app calls an AI model, checks a payment, or reads from another service, it's using an API — a standard doorway with a known address and format. You used this idea already when you built webhooks in A10.

Auth Logins and identity. The layer that decides who is allowed in and what they're allowed to do. Passwords, magic links, Google sign-in — all of it is "auth" (short for authentication). Don't build this yourself; use a service like Supabase Auth or Clerk.

How they connect

Picture a restaurant. The frontend is the dining room — what guests see and interact with. The backend is the kitchen — the rules and recipes that turn an order into a meal. The database is the pantry — ingredients stored and retrieved on demand. Hosting is the building itself — someone owns and maintains it so the restaurant can exist at a fixed address. APIs are the supplier deliveries — ingredients (data) arriving from the outside on a known schedule via a known door. Auth is the front-of-house staff checking reservations — verifying who gets in and where they sit.

Every web app, from a two-screen prototype to a full SaaS product, has all six. The only thing that changes is how complex each one is.

What this means for you as a builder

What Lovable / Bolt handle

Frontend — generated from your description
Backend — basic logic wired up automatically
Hosting — deployed for you on save
Simple auth — available as a toggle

What you add as you grow

Database — connect Supabase for persistent storage
APIs — wire in AI models, payments, external data
Auth — add user accounts when your tool goes multi-user
Custom backend logic — Course B goes deep here

The Course B preview: each of these six parts gets its own hands-on lesson in Course B. You'll connect a real database, call a real API, and add auth to a real app. This lesson is the map; Course B is the territory.

Check yourself

Answer before opening — recalling it is what makes it stick.

A user submits a form and the data disappears when they refresh. Which part is missing?

The database. Without a database, the backend has nowhere to store data persistently. The form works (frontend) and the logic runs (backend), but nothing is remembered between page loads.

Your app calls the OpenAI API to generate text. Which part of the six is that call happening in?

The backend — using an API. The backend makes the call to an external service (OpenAI) through its API. The frontend just shows the result. Two parts working together.

A colleague says your app "needs auth." What are they asking for, in plain English?

Logins — a way to verify who each user is and what they're allowed to do. Without auth, anyone with the URL can see everything. With auth, users sign in and the app knows who they are.