Guides / Concepts explained

What Is a Full-Stack App? A Plain-English Explanation

A full-stack app has a screen people use, a server that applies the rules, and a database that remembers. What each layer does and why it matters.

Mythex Team · 2026-09-29 · 6 min read

A full-stack app is an app that includes every layer it needs to work: the frontend people see and click, the backend that runs on a server and enforces the rules, and the database that remembers everything. A to-do list that saves your tasks, lets you log in from any device and shows nobody else your list is full-stack. A single page that only shows your opening hours is not.

"Stack" just means the layers of technology piled on top of each other. "Full" means all of them are there.

Why it matters when you build with AI

When you describe an app to an AI builder, the words you use decide which layers it builds. "Make a page that shows our menu" produces a frontend. "Let customers order from our menu and let the kitchen see new orders" needs all three layers, because orders must be saved, shared between two kinds of users and kept private.

Knowing the difference helps you in three ways:

• You ask for the right thing. If you want data saved, say so. A builder that only makes the frontend will look finished but forget everything on refresh.
• You spot fake completeness. A demo with sample data can look identical to a working app. Knowing the layers lets you check that the data really goes somewhere.
• You understand the running costs. A frontend alone can be served as static files. A backend and a database are programs that run on servers, which is where most hosting cost comes from.

An everyday analogy: a restaurant

Think of a restaurant.

• The dining room is the frontend. Menus, tables and the waiter's notepad. It is what guests see, and it should be pleasant and easy to use.
• The kitchen is the backend. Guests never go in. It takes orders, checks that the dish is available, cooks it and refuses odd requests. Rules live here.
• The pantry and the order book are the database. They hold what exists and what has been ordered, so nothing is forgotten when the shift changes.

A restaurant with only a dining room can show you a nice menu, but you can't get fed. That is a frontend-only app pretending to be full-stack.

The three layers in more detail

The layers talk to each other in a fixed order. The frontend asks the backend for something through an API — a defined set of requests the backend accepts. The backend checks the request, reads or writes the database, and sends back an answer. The frontend never talks to the database directly.

That order is the most important security idea in the whole stack. Anything in the frontend can be read and changed by the visitor, because it runs on their device. So the rules — "only the owner can see this invoice", "a coupon can be used once" — must be enforced in the backend. For more on the split, see frontend vs backend.

A worked example: a class booking app

Say you run a yoga studio and want people to book classes online.

What the visitor does: opens the site, sees this week's classes, taps one, signs in and books a spot.

What happens underneath:

1. The frontend shows the timetable. To fill it, it asks the backend, "What classes are on this week, and how many spots are left?"
2. The backend asks the database for the classes and counts the bookings for each, then replies.
3. The visitor taps Book. The frontend sends "book class 42 for this signed-in person".
4. The backend checks: is this person really signed in? Is the class full? Have they already booked it? Only if all is well does it write a new booking row to the database.
5. The backend replies "booked", and the frontend shows a confirmation.
6. Later, the studio owner logs in and sees the class list. The backend checks that she is an admin before showing everyone's names.

Now imagine this was built as frontend only. The timetable might display, and the Book button might show a nice tick, but the booking would vanish on refresh, the "spots left" count would be wrong for everyone else, and the owner would never see it. Step 4 — the checks — would be missing entirely. That is the practical difference.

Key terms

• Frontend (client side): the part that runs in the browser.
• Backend (server side): the part that runs on a server. Also called the API server.
• Database: where data is stored in an organised way. See what a database is.
• API: the list of requests the backend accepts from the frontend or other programs.
• Authentication: checking who someone is (login). Authorisation: checking what they may do.
• Deployment: putting all the layers on servers so the public can use them.
• Monolith vs services: one program that does everything, versus several smaller ones (for example a website and a separate API). Both are full-stack.

Common mistakes and misconceptions

• "It looks done, so it is done." Sample data and a working-looking button are not the same as saved data. Refresh the page, open it in a private window, and check the data is still there.
• Putting rules in the frontend. Hiding a button is not security. If the backend doesn't check, anyone who knows the request can make it.
• Putting secret keys in the frontend. A payment or AI provider key in browser code is readable by every visitor. Keys belong on the backend, in environment variables — see environment variables and secrets.
• Thinking full-stack means complicated. A small full-stack app can be a few screens, a handful of backend routes and three database tables. It is a description of the layers, not the size.
• Thinking you must pick every technology yourself. Any sensible, widely used stack will do for a first version. What matters more is a clear description of the data and the rules.

What to ask your AI builder for

Describe the app in terms of the three layers, even if you don't name them:

• The data: "Save classes (name, time, capacity) and bookings (class, person, time booked) in a database."
• The rules: "A class can't be booked past capacity. A person can book a class only once. Only admins can see who booked."
• The screens: "A weekly timetable, a booking confirmation, an admin page listing bookings per class."
• The checks: "Enforce these rules on the server, not only in the page. Keep any API keys on the server."

Then test like a sceptic: refresh, sign in as two different people, try to see data you shouldn't. The guide to building an app with AI walks through that loop end to end.

Full-stack apps on Mythex

Mythex builds full-stack web apps from a chat description. By default a new app gets a React and TypeScript frontend; when the app needs to save data, Mythex adds a dedicated Postgres database to the project, and you can ask for a separate API server (for example Python, Node, C# or Java) alongside the website. Everything runs together in a live preview and publishes to a public URL. The docs page on multi-service apps shows how a website and an API are previewed and published together, and the full-stack app builder page has starting points.