Every AI app builder demos the same way. A prompt, forty seconds, a working app with a login screen and a database. Nothing in that demo tells you whether the thing can carry a business, because every one of them clears that bar.

The useful question is not "can it build an app". It is "when this app matters, can I still work on it". Most of these tools are prototyping tools. That is a legitimate and valuable thing to be. The damage happens when someone mistakes one for a production platform and finds out eighteen months in.

Here are eight checks that separate the two. None of them need you to build anything first, and most take under ten minutes.

Key takeaways

  • The decisive question is whether you can get the real source code out and run it somewhere else. Everything else is recoverable, lock-in is not.
  • Ask what it generates for authorization, not authentication. Almost all of them do login. Far fewer do "can this user see this record".
  • A builder with no concept of a staging environment is a prototyping tool, whatever its marketing says.
  • Being a prototyping tool is not a flaw. Use them for what they are good at, and plan the handoff before you need it.

1. Can you take the code and leave?

This is the one that matters most, because it is the only one you cannot fix later.

Ask: can I export the complete source, push it to my own git remote, and run it on my own infrastructure, with no part of it calling back to the vendor?

  • Check whether the export includes the backend, the database schema and the migrations, or only the frontend. A frontend export with a proprietary backend is not portability.
  • Look for a real repository with a commit history you own, not a zip download.
  • Find out whether the app depends on a vendor-specific runtime, SDK or auth service. If pulling the vendor out breaks the app, you have not got the code, you have got a copy of it.
  • Try it before you have anything valuable. The export is easy to test on a throwaway project and impossible to negotiate once you are dependent.

A tool that passes this check can be a prototyping tool and still be a perfectly safe starting point, because the exit is cheap. A tool that fails it needs to be judged as a permanent platform decision.

2. Does it generate authorization, or only authentication?

Almost every builder will add a login. Authentication, proving who you are, is a solved and well-packaged problem. Authorization, deciding what that person is allowed to touch, is where generated apps leak.

The test: build a two-user app and see what it writes.

  • Ask for a resource that belongs to a user, then try to read it as a different user by changing the id in the request. If you can, the tool generated a UI-level check and nothing more.
  • Look at whether permission checks live on the server or in the client. Client-side checks are decoration.
  • If it uses Postgres or Supabase, see whether it enables row level security by default, or whether it hands you a public key and an unprotected table.
  • Check what it does with an admin role. Hiding a nav item is not access control.

A tool that generates real server-side authorization is doing something genuinely hard. Most do not, and that single gap is the most common serious flaw we find in AI-built apps.

3. Is there a staging environment?

Production platforms have at least two environments and a way to promote between them. Prototyping tools have one, and it is live.

  • Can you have a staging copy with its own database and its own secrets?
  • Does a change deploy to a preview URL first, or does editing change the running app immediately?
  • Can you roll back a release, and how long does it take?
  • Are database migrations versioned and replayable, or does changing the schema mean editing the live one?

If every edit is instantly live and the only database is the real one, you are holding a prototyping tool. You can still ship with it. You just cannot change it safely once people are using it.

4. How does it handle secrets?

A quick, high-signal check. Create a project that needs an API key and look at where the key ends up.

  • Is it in a server-side environment variable, or inlined into code that reaches the browser?
  • Are production and development secrets separate, or the same value in both?
  • If you rotate a key, is there one place to change it?
  • Search the generated client bundle for the key. This takes thirty seconds and the answer is unambiguous.

Keys that reach the browser are not a configuration mistake you can tidy up later. They are a sign the tool has no real server-side execution model.

5. What does it do when things go wrong?

Generated code is usually good at the happy path and improvised about everything else. Push on the unhappy path deliberately.

  • Submit an empty form, a 10,000 character string, and a number where text is expected. Do you get a clean validation error, or a 500 with a stack trace?
  • Turn off a third-party integration the app depends on. Does it degrade or collapse?
  • Is there any server-side input validation, or only the HTML required attribute?
  • Is there structured error logging you can read, or does a failure disappear?

A builder that generates validation and error handling without being asked is thinking about production. One that produces a beautiful interface over unhandled promises is thinking about demos.

6. Can a human work on the output?

Eventually a person has to change this code, and that person may not have the tool. Judge the code as code.

  • Is it idiomatic for its framework, or an unusual structure only the generator understands?
  • Are there types, and do they mean anything?
  • Are concerns separated, or is there a single 2,000 line file?
  • Are dependencies current and conventional, or pinned to odd versions?
  • Are there any tests at all?

The practical version of this check: hand the export to a developer who has never seen the tool and ask how long it would take them to add a field to a form. If the answer is an afternoon, the output is maintainable. If they cannot find where to start, you have generated something that only the generator can maintain.

7. Does it know what it cannot do?

This is a judgement call about the vendor rather than the code, and it predicts a lot.

Honest tools describe themselves as a way to get to a working prototype fast, document their export path, and say plainly where you should take over. Tools that claim to replace engineering teams outright are selling the demo.

  • Does the documentation have a section on going to production, or does it stop at deploying?
  • Is there any guidance on backups, monitoring, migrations or scaling?
  • Does the pricing page mention environments, team roles and audit logs, or only generation limits?
  • Is there a changelog with breaking changes, and are deprecations handled with notice?

8. What happens at the volume you expect?

Prototypes are tested on ten rows. Count the queries.

  • Load the busiest page with the database query log on. One page triggering forty queries is an N+1 pattern that will not survive growth.
  • Are there indexes on the columns the app filters by?
  • Are long lists paginated, or does the page load the whole table?
  • Are uploads streamed, or read into memory?
  • Is there any caching layer, and can you control it?

The ten-minute version

If you want one quick pass before committing:

  1. Export the project. Run it locally with the vendor's services unreachable. Does it start?
  2. Search the client bundle for any key that should be secret.
  3. Create two users, make a record as one, request it as the other by id.
  4. Paste 10,000 characters into a text field and submit.
  5. Ask the docs how to roll back a bad deploy.

Four passes out of five and you are holding something you can build on. Two or fewer and you are holding a prototyping tool, which is still useful as long as you know it.

So which should you use?

For getting an idea in front of people this week, pick the fastest one and do not think about this list. That is the job those tools are built for, and overthinking the stack at that stage is the actual mistake.

The decision point is when the prototype starts working. When there are real users, real data and real money, the questions above stop being academic. Most teams hit that point sooner than they planned, which is why check one matters so much: with a clean export path, the transition is a project, and without one it is a rewrite.

If you are weighing specific tools, we compared the main ones in Lovable vs Bolt vs v0, and there are notes on taking each of them further in Lovable to production, v0 to production, Bolt to production and Claude Code to production.

FAQ

Is any AI app builder genuinely production ready?

The honest answer is that the category splits by what the tool produces rather than by brand. Tools that generate a conventional codebase in a mainstream framework, which you fully own and can run anywhere, can absolutely take an app to production, because at that point it is just a codebase and normal engineering applies. Tools that keep the application inside their own runtime are production platforms only to the extent you are willing to stay on them permanently. Judge the output and the exit, not the marketing.

What is the difference between a prototyping tool and a production platform?

A prototyping tool optimises for getting from nothing to something visible as fast as possible, and it is measured by how quickly you can show someone. A production platform optimises for changing an application safely while people depend on it, and it is measured by environments, rollbacks, migrations, access control and observability. The second set of features is invisible in a demo, which is why almost no builder leads with them.

Can I start on a prototyping tool and move later?

Yes, and for most products that is the sensible path. The move is manageable if you checked the export early and kept the app reasonably conventional. It gets expensive when the data model has to change, for example when data that should have been isolated per customer was shared across the whole system. That is a structural problem rather than a code problem, so it is worth asking how the tool separates tenants before you build on it.

How do I check the generated code if I am not a developer?

Several of these checks need no code reading. The two-user id test, the 10,000 character test, the export-and-run test and searching the bundle for a leaked key are all behavioural, and you can do them from a browser. For the maintainability question, the shortcut is to pay a developer for two hours to read the export and tell you what they think. It is the cheapest due diligence available on a decision this size.

Does the tool matter less than how I use it?

Mostly, with one exception. Good practice makes up for a lot: you can add validation, write tests, set up monitoring and fix authorization on top of almost any generated codebase. The exception is ownership. If you cannot get the code out and run it independently, no amount of discipline on your side compensates, because every future decision runs through a vendor you do not control.