React Folder Structure Explained for AI-Built Apps

Why the file tree matters, even if you never write code

A working screen after one prompt makes it easy to believe the screen is the whole project. It's only the part you can see. Underneath sits a folder of files, the same kind of structure a developer would end up with by typing every line, and anything going wrong that isn't visible on the screen is happening somewhere in there. You don't need to write any of it. You do need to recognise what's there, because that's what turns "something's broken" into "the checkout page isn't saving the order", and your AI can act on the second one.

A typical AI-generated project, annotated

One setup you'll meet is a React app put together by a build tool called Vite. Base44's documentation, for one, describes its apps as "standard React apps built with Vite". Here's a typical example of what you'll see when you open the files of a project like that, or download them:

my-project/
├── index.html          # the HTML file the browser loads first
├── public/             # copied into the site unchanged
│   └── favicon.ico
├── src/                # the app's own code, built by the tool
│   ├── main.jsx        # the starting point that loads the app
│   ├── App.jsx         # the layout; which page shows where
│   ├── pages/          # one file per page a visitor can open
│   │   ├── Home.jsx
│   │   └── Checkout.jsx
│   ├── components/     # reusable pieces pages are built from
│   │   ├── ui/         # ready-made buttons, dialogs, inputs
│   │   └── CheckoutForm.jsx
│   └── lib/            # helpers, and the link to the backend
├── functions/          # backend code: runs on a server
├── package.json        # packages the project depends on
├── package-lock.json   # exact versions, written automatically
├── vite.config.js      # build tool settings
└── tailwind.config.js  # styling settings

Your builder's names may differ a little. Files may end in .tsx instead of .jsx (TypeScript rather than plain JavaScript), pages may live in app/ or routes/, and the backend folder may be called api/ or supabase/functions/, or not be there at all. The jobs stay the same, and that's what's worth learning.

The first split to understand is public/ against src/. Vite's documentation says files in public/ are "copied to the root of the dist directory as-is", so an image there reaches the live site exactly as it is. Everything in src/ is code the build tool processes and bundles into the files a visitor's browser downloads. That finished version lands in a separate folder, dist/ by default, which is rebuilt every time the project is built and never edited.

A page and a component are not the same thing

A page is something a visitor can go to directly, at its own address. It lives under pages/, one file each. A component is a smaller, reusable piece a page is built from: a button, a card, a form. CheckoutForm.jsx in the tree above is one. Nobody visits it on its own; the Checkout page shows it inside itself, and if a second page needed the same form, it would use the same file instead of a copy.

That's why the difference matters when something looks wrong. If the problem is on one page only, the page's own file is the place to start. If the same piece is wrong on every page it appears on, the problem is in the component, and fixing it there fixes it everywhere.

The components/ui/ folder looks like your own components at a glance, but it holds ready-made interface pieces (buttons, dialogs, form inputs) from a component library the project was set up with. Pages across the site share them, so a change there can change the whole site.

The parts of any project, and which ones you touch

These are the parts you're likely to meet in an AI-built web app, whatever your AI website builder calls them, and what your role is with each.

The lockfile and the generated folders need a word more. npm, the tool that installs packages, says the lockfile is "automatically generated" whenever it changes the installed packages, and "is intended to be committed", meaning it's kept with the rest of your project so every install gets the same versions. node_modules/ is where those packages are put when the project is installed on a computer. None of it is yours, and it's recreated from package.json and the lockfile, so unlike the lockfile it doesn't need to be kept with the project. Our guide to dependencies and packages explains what goes wrong when package.json and the lockfile drift apart.

Where's the backend?

The backend is the part of your project that runs on a server instead of in a visitor's browser. It's the only safe place for a secret key, such as a payment provider's key, because everything in the frontend is downloaded by every visitor. When you look at your project, you'll find one of three things:

• As a folder in the project. Base44's documentation, for example, lists a functions/ folder of "backend functions for backend logic", one file per function. Projects built on Supabase, a backend service some builders connect to, keep theirs in supabase/functions/.
• Somewhere your builder runs for you. Your project holds only a small file that connects to it, for example under lib/ or api/. The backend's settings live in the builder's own screens, not in your files.
• Not at all. A site that only shows information can be frontend only. That's fine until it needs to take a payment, send an email or store what visitors type, and then it needs a backend.

You don't have to know which one yours is. You do have to ask, because the answer tells you where a secret key may go, and whether downloading your files gives you everything. Our guide to why an API key can't go in the frontend covers what a visitor can see. The .env file needs the same care: Vite's documentation warns that variables starting with VITE_ "will be exposed in client-side source code", so a key stored under a name like that reaches every visitor.

What the file tree can't tell you

• Folder names are habits, not rules. Nothing stops an AI putting backend code in a frontend folder, or a secret key in a page file. The tree tells you where things should be. Only checking tells you where they are.
• A tidy tree says nothing about whether the code works. A project can look perfectly organised and still have a checkout that fails or a table anyone can read.
• Your files aren't your data. The customers, orders and sign-ups your site stores live in a database, not in these folders. A copy of the files is not a backup of the data.
• A file you don't recognise isn't safe to delete. Something else may load it, and the build can fail without saying why. Ask your AI what uses a file before removing it.

Using the map in your prompts

The point of all this is a better prompt. Compare these two:

• Vague: "The checkout is broken, please fix it."
• Precise: "On the Checkout page, the order isn't saved after payment. Check the backend function that records the order before changing the page itself."

The second one tells your AI coding agent where to look and what not to touch. You didn't need to read a line of code to write it, only to know that a page and the backend are different places.

The prompt to give your AI

Copy this into your AI coding agent's chat. It asks for a plain-English map of your own project and tells the AI not to change anything. It works whether or not your builder shows you the files.

I'm not a coder. Give me a plain-English map of this project.
Don't change any files.

1. List the top-level folders and files, and say in one
   sentence what each one is for.
2. List every page a visitor can open, with the file that
   builds it.
3. Tell me where the backend is: a folder in this project,
   a service my builder or another provider runs elsewhere,
   or none.
4. Tell me where secret keys are stored and used, and
   confirm none are in any file the browser downloads.
5. Tell me which files are generated automatically and
   should never be edited by hand.
6. Tell me which files hold the shape of my stored data.

Only name files and folders that really exist in this
project. If you're not sure about something, say so.

What to check in the AI's answer

• Everything it names exists. Open your builder's code view, or a downloaded copy, and find each folder it lists. A folder you can't find is a guess, not a map. If your builder doesn't show you files, ask the AI to quote the first line of each file it names.
• It gave a straight answer on the backend. "A functions/ folder", "run by the builder" or "there isn't one" are real answers. "It's handled" isn't.
• No secret key sits in the frontend. If it names a key in a page, a component or a file under src/, ask it to move the key to the backend and explain how.
• It kept generated files separate. node_modules/, dist/ and the lockfile should be on its do-not-edit list.
• It didn't change anything. If it edited files anyway, ask it to show you exactly what it changed.