Understanding What Your AI Builder Actually Built

Quick answer

You do not need to read every line an AI wrote. You need its shape: which code runs in the visitor's browser, which runs on a server, where data is stored, where secrets live, and what your project depends on to start at all. That model is what turns an opaque failure into a locatable one, and it is the difference between directing a build and hoping it works.

An AI builder generates working code fast. Understanding what it generated is a separate skill, and it's the one that actually determines whether you can fix, extend or trust the result. Ten guides now, see below for what's covered.

Guides in this hub

React Folder Structure Explained for AI-Built Apps

What each folder and file in your project is for, which ones you touch, and a prompt that maps it for you.

Why You Can't Put an API Key in the Frontend

What a visitor can actually see, why a client-side secret is a real bug, and which keys are genuinely fine there.

Environment Variables Not Working After Deploy

Why a value works in preview and goes missing on the live site: the five causes, how to tell them apart, and a prompt that lists every value your project needs.

Git and GitHub Basics for AI-Built Projects

Connecting a repository, commit discipline, and what belongs in .gitignore. The safety net a platform's single undo button is not.

Why Your Vibe-Coded App Isn't Production-Ready Yet

The five paths a demo never exercises, made concrete: malformed input, a failed third-party call, two users at once, and more.

When Does Your App Actually Need a Real Database?

The real test for whether you need one, and the setup step people skip: the access rules that keep each user's data private.

Adding Login and Google Sign-In

Your AI coding agent wires up login. You check the data is protected, and register Google sign-in's addresses yourself.

Dependencies, Packages and Why Builds Break Elsewhere

What package.json and a lockfile actually do, and why a build can fail once it leaves preview.

How to Add Schema Markup to an AI-Built Site (and Check It)

Where the JSON-LD block goes, why a single-page app needs it page by page, and four checks that prove it's there.

Getting Your Site Indexed

You clicked Publish. What GSC, Bing Webmaster Tools and IndexNow actually do next, and the honest limit on all three.

For error diagnosis, not concepts: Why Is My AI-Built App Not Working? starts from the symptom you can see and works back to its cause.

The interface you can see is not the project

An AI builder shows you a working screen within minutes, which makes it easy to believe the screen is the thing you built. It is one layer of it. Underneath sit files organised into a structure, components that render pieces of that screen, a data layer that may or may not exist yet, configuration that differs between the preview and the real world, and a list of external packages the whole thing depends on to run.

You do not need to be able to write any of it. You do need to know it is there, because every failure that is not visible on the screen is happening in one of those layers, and the first diagnostic question is always which one.

Frontend and backend, and why the split decides everything

The frontend is what runs in your visitor's browser. It can be read by anyone who opens developer tools, which is a permanent property, not a setting. The backend runs somewhere your visitor cannot see, which is why anything secret has to live there: API keys, passphrases, and any logic that decides what a user is allowed to do.

Most integration failures on this site trace back to that line being crossed or misunderstood. A payment signature generated in the browser exposes the passphrase that makes it meaningful. An authorisation check performed in the frontend can be bypassed by anyone willing to edit what they receive. The rule is durable and worth memorising: the frontend can ask, the backend decides.

Where data lives, and whether you need it to

A database is only required when something must outlive the page and be shared beyond one browser. Accounts, orders, submissions you need to read back: all database work. A brochure site whose contact form sends an email does not need one, and adding it anyway buys complexity with no return.

Once one exists it changes your obligations, not just your architecture. Stored personal information brings retention, access and deletion duties, and where the data physically sits becomes a real question rather than a technicality. Supabase and POPIA compliance covers that in the South African context specifically, and the structural question it answers applies wherever you host.

Environment variables: invisible, and therefore expensive

An environment variable is a value handed to your application by its surroundings rather than written into its code. That is what keeps an API key out of a public repository, and it is also why a wrong one is so hard to diagnose: nothing in the file you are reading shows the value, so the code looks correct while the behaviour is not.

This single concept explains a large share of the "works in preview, breaks once deployed" reports on this site. The builder's preview had the value; the host was never given it. The code did not change at all, which is exactly why reading the code again does not find the fault.

Generated code and a production system are not the same artefact

Generated code reliably handles the path it was demonstrated on. A production system also handles the paths nobody demonstrated: malformed input, a third-party service timing out, two people submitting at once, a deploy environment configured differently from the preview, and the failure states a webhook is contractually required to return.

Closing that gap is not a matter of asking the AI for better code. It is knowing which cases exist to ask about, which is why understanding beats prompting for this particular class of problem. Every guide in the integrations and fixes hubs is, underneath its specific subject, an instance of this same gap being closed, and this hub's own guide to why a vibe-coded app isn't production-ready yet covers all five paths directly, with each of them tied back to a concrete guide on this site.

What this hub covers next

This hub's ten guides work at this layer: what a generated project's own files and folders actually are, why the frontend/backend split protects a real secret, why that same secret can still break once you deploy, how to keep a real history of it all outside the platform, the full production-readiness gap that ties it together, when a project actually needs a real database, adding authentication without the mistake that most often ships, what actually happens when a dependency conflicts or a build reproduces differently elsewhere, adding schema markup to your own generated pages, and what actually happens once you've published, GSC, Bing Webmaster Tools and IndexNow included.

Not affiliated with the platforms we write about

AI Build South Africa is an independent resource. We're not endorsed by, or an official partner of, Supabase, Lovable, Base44, Bolt.new, Anthropic, Hostinger or any other platform named on this Site. We do participate in affiliate and referral programmes with some of these providers, including Hostinger and Base44. Platform behaviour changes without notice, so confirm current details against each platform's own documentation. See our Disclaimer for the full disclosure and our Terms of Service for the wider terms.

Frequently asked questions

Do I need to understand the code an AI wrote for me?

You need to understand its shape, not its every line. Which part runs in the visitor's browser, which part runs on a server, where data is stored, and where secrets live. That is enough to diagnose most failures and to judge whether a proposed fix is plausible. Reading every line is not.

What is the difference between generated code and a production system?

Generated code produces the correct result on the path it was tested on. A production system also handles the paths nobody demonstrated: bad input, a failed third-party call, two people acting at once, and a deploy environment configured differently from the preview. That gap is where most AI-built projects break after launch. This hub's own guide to why a vibe-coded app isn't production-ready yet covers all five paths in full.

Why does my app work in preview but break once deployed?

Almost always configuration rather than code. Environment variables that exist in the builder's preview but were never set on the host, a service URL still pointing at a development endpoint, or a key scoped to the wrong environment. The code is identical; what surrounds it is not.

What is an environment variable, and why does it keep breaking things?

It is a value supplied to your application by its environment rather than written into the code, which is how secrets like API keys stay out of your source. It breaks things because it is invisible: nothing in the code shows what the value is, so a missing or wrong one produces a failure with no obvious cause in the file you are looking at. This hub's own guide to environment variables and secrets covers the most common version of this directly: working in preview, breaking once deployed.

Does my project actually need a database?

Only if something must survive a page refresh and be shared beyond one visitor's browser. Accounts, orders, submitted forms and anything you need to read back later all require one. A brochure site with a contact form that sends an email does not.

Building