An AI app builder takes a description of an application and returns one that runs: screens, sign-in, a database behind them, and a deploy at an address you can share. You refine it by describing what is wrong, and it changes the code to match. It is the category that made vibe coding famous.
It compresses the first hours of a project into minutes, and that gain is real. The layer page sets out what the whole rung costs: the schema, the access rules and the decisions nobody made. This page is about the builder itself, and about the habits that decide whether you can keep what it gives you.
What it is for
- Putting a working idea in front of real users before paying for it to be built properly.
- A prototype for a pitch, where the point is that it runs, not how.
- An internal tool with a handful of users and a short, known life.
- A working version of a flow that would take a week to explain in a document.
Who it suits
Founders validating an idea. Product people and designers who want a running flow rather than a static mockup. Developers who want a throwaway prototype and are honest with themselves that it is throwaway.
Above all, it suits anyone who has decided before starting what happens to the result if the idea works. That decision is the difference between a prototype and an accident.
How to tell this is your category
- You describe the whole application, screens and data together, in one place, and the tool builds both.
- You change it by describing the change, not by editing files.
- You have never opened the code, or you opened it once and closed it again.
- If what you described was only the data, the sign-in and an API, with your own front end in front of it, you are using an AI backend and database builder, where the costs concentrate further.
What it costs you later
- The prompt history is the only specification. Every decision the application embodies was made in a conversation, if it was made at all. Nobody wrote down what a refund does, who counts as an admin, or what happens when a payment fails. When you need to explain the application, to a developer, an investor or yourself, the only document is the code. Writing requirements an AI coding agent can build from shows the form that history should have taken.
- Fixing by asking again. When a feature is wrong, the natural move is to describe it again, and the tool regenerates that area. Sometimes it rewrites code that was already correct along with the part that was not, and without tests nothing tells you which. Each round of trying again is an unreviewed change to code nobody has read.
- A prototype that gets users becomes production. Nobody decides it. The demo goes well, people start using it, their data builds up, and the prototype is now the product, because throwing it away would lose the data. Most of what is expensive on this rung comes from that moment arriving unplanned.
- The handover quote. A developer asked to take over a generated application has to work out what it does before changing anything. That work is real and billable, and it tends to surprise the person paying for it, who remembers the application costing an afternoon.
- Keys where anyone can read them. Connecting a payment provider or an email service means a key has to live somewhere. A key in code the browser downloads is a key any visitor can read. Find every key, and check where it lives, on every change rather than once, the case AI is finding bugs faster than teams can fix them makes for security testing.
Decide on day one
The cheapest moment to deal with all of this is before the first prompt, because that is when the answers cost nothing.
- Throwaway or keep. Say which, out loud, to whoever is paying. If it is throwaway, set the date it is thrown away, and keep real customer data out of it until then.
- If keep, write as you go. A short file of requirements, one line per decision, kept beside the prompts, turns the conversation into something a developer can read later. It takes minutes per feature, and it is the document you would otherwise pay someone to reconstruct.
- Keep the code somewhere you control. If the builder can export the code to a repository, do it from the start, so there is a history of what changed and when.
If you are already past the demo and the application has users, the layer page sets out the route off this rung: characterise what exists, write the requirements it never had, put tests around the paths that would hurt most, then change it one reviewed step at a time. Taking over a generated prototype works through each step, with the tests and documents it produces.