What's actually inside an AI-built app: a tour for non-developers
If you've shipped something with an AI app builder and want to understand what you're looking at, here's a friendly guided tour of the parts — without the jargon.
You typed a description, hit go, and twenty minutes later you had a working app. Great. But now you’ve clicked “view files” and you’re staring at a folder tree that looks like it was written in a different language. What is package.json? Why are there forty things in node_modules? What does “schema” mean and why do you have one?
This post is a guided tour. Not a tutorial — a tour. After reading it you won’t know how to write any of these files yourself, but the next time something looks weird, you’ll know which corner of the app to point at.
I’m going to use three running examples throughout, so the abstract parts have something concrete to attach to:
- Maya, a marketing lead, who built a referral leaderboard for her team.
- Jordan, a yoga teacher, who built a class booking site.
- Sam, who runs a bakery, who built a “pre-order tomorrow’s croissants” page.
All three of them used an AI app builder. All three apps look completely different to a customer. Under the hood, they’re shaped surprisingly similarly.
The frontend: what your customer actually sees
The frontend is everything that loads in someone’s browser. Buttons, layouts, fonts, animations, the way a form clears itself after you submit it. If you can see it, it’s frontend.
For Maya, the frontend is a leaderboard with rank, name, and number of referrals. For Jordan, it’s a calendar of classes with a “book” button. For Sam, it’s a list of pastries with little plus-and-minus buttons next to each one.
Inside the project, the frontend usually lives in a folder called something like app/, pages/, or src/. You’ll see files that end in .tsx or .jsx. Each one is roughly “one screen” or “one piece of a screen.” The leaderboard row is one file. The header is another file. The page that ties it all together is a third.
When you ask the AI builder to “make the buttons rounder” or “move the leaderboard to the right,” this is the part that changes.
The backend: the part that thinks
The backend is the part nobody sees, but everybody depends on. It’s the code that runs somewhere else — on a server, not in the customer’s browser — when something needs to happen that the customer’s browser shouldn’t be trusted to do alone.
Why can’t the browser do everything? Because the browser is the customer’s machine, and you can’t trust it. If Maya’s leaderboard updated referral counts purely in the browser, anyone could right-click and add 9,000 referrals to themselves. So the backend is where the rules live: “this person can do this, but not that,” “actually save this to the database,” “send this email.”
The backend usually lives in a folder called api/, server/, or app/api/. The files there are usually short. Each one handles a specific request: “create a booking,” “list today’s croissants,” “add a referral.”
When something works in your app but the result doesn’t stick — you click submit, you see a confirmation, but tomorrow the data is gone — the backend is almost always where the bug is.
The database: your app’s memory
Imagine your app’s memory as a row of filing cabinets. Each cabinet has a label on the front. One says “users.” One says “bookings.” One says “croissant_orders.” Inside each cabinet, every drawer is one row. Every drawer has the same set of slots: a name, an email, a created_at, a status.
That structure — “what cabinets exist, what slots each row has” — is called a schema. It’s the most important file in the project, even though it’s also probably the most boring-looking one. Find a file called schema.ts, schema.prisma, or something inside a folder named db/ or migrations/. Open it. You’ll see a list that mirrors what your app actually remembers about the world.
Jordan’s schema has a classes table, a bookings table, and a users table. Sam’s has products, orders, and order_items. Maya’s has members and referrals. The shape of the schema is the shape of the product, which is why changing it later is harder than changing how the buttons look.
A useful trick: if you can describe what your app remembers, in plain words, you can usually describe the schema. “I remember each customer’s name and email. For each customer, I remember the orders they placed. For each order, I remember which pastries and how many of each.” That sentence is, almost word for word, the schema.
Auth: the bouncer at the door
“Auth” is two words mashed together: authentication (who are you?) and authorization (what are you allowed to do?). Both are usually handled by a small set of files in a folder called auth/, or by a service whose name you might recognise: Clerk, Auth0, Supabase Auth, NextAuth.
The two questions are different. Authentication answers: “is this really Maya?” — usually with a password, a Google login, or a magic link emailed to her. Authorization answers: “is Maya allowed to delete other people’s referrals?” — and the honest answer for most AI-built apps in their first week is “we forgot to check.”
This is the part that’s most often quietly broken. The login screen works, so it feels secure. But the backend isn’t always checking that the logged-in person is the same person whose data they’re trying to read. If your app has any concept of “my data vs your data,” ask the AI builder explicitly: “Make sure users can only see and edit their own data.” You will be surprised how often that one sentence reveals a missing check.
Integrations: the things you didn’t build but are using anyway
This is where most non-developers underestimate what’s actually happening. The thing that sends Sam’s “your croissants are ready” email isn’t code — it’s an account at SendGrid or Resend. The thing that processes Jordan’s class payment isn’t code — it’s Stripe. The thing that hosts the photos on Maya’s leaderboard isn’t code — it’s a storage service like S3 or Cloudinary.
Each integration shows up in two places. There’s a small chunk of code in the backend that says “hey, Stripe, charge this card.” And there’s a key — a long secret string — stored somewhere safe (usually a file called .env that nobody should ever commit) that proves to Stripe that the request came from Sam’s bakery and not a stranger.
If you ever wonder why your app suddenly stops sending emails or stops accepting payments, the cause is almost always one of: an expired key, a hit usage limit, or a change in the integration’s policies. The code didn’t break. The handshake did.
The deploy: how it gets to the internet
The final piece is the part that turns the folder on your disk into a thing your customer can visit at a URL. This usually means three small things working together:
- The host: a service like Vercel, Netlify, Fly, or Render that runs your backend and serves your frontend.
- The domain: a name like
mayas-leaderboard.comthat points at your host. - The build: the recipe that takes your messy source files and turns them into the leaner, faster version that actually runs.
When something works locally but breaks in production, the trouble is usually here. A key that’s set on your laptop but not on the host. A library that’s installed in development but not in production. A database that exists in your browser but not on the live site.
The five-minute habit that pays for itself
You don’t need to read every file in your project. You don’t need to know what most of them do. But you should, once a week, do a five-minute walkthrough where you open each of the folders above and ask the AI builder, in plain words, what changed.
Maya does this every Friday afternoon. She types: “What changed in the schema this week, and why?” And: “Are there any new integrations in this app that I didn’t ask for?” The answers are almost always reassuring. The few times they aren’t, she catches problems while they’re still small.
That’s the whole point of understanding the parts. Not to become a developer. Just to be able to ask better questions.
Where to go next
If this tour helped, two follow-ups are worth your time. The ‘looks fine’ bug covers what to do when one of these parts is silently broken, and demo-ready vs production-ready covers how to tell when your app has moved from the first stage to the second. Same map, different uses for it.