Is an AI app builder safe? Where your code and data actually live

An AI app builder is as safe as its answers to five questions: what runs where, how you sign in, who can see your project, what the AI model receives, and whether you can take your code and leave. With App Builder Agent the editor and live preview run in your browser, builds and workflows run on the platform's servers, sign-in is Google-only, projects are saved to your account and can be deleted, API keys go in a .env file, and the complete source can be exported on the Member plan and above. No certifications are claimed; the section on limits says exactly what that means.

People ask "is it safe" with different worries in mind: a founder does not want the next unicorn's code training a model, a small business does not want customer phone numbers on an unknown server, and a developer wants to know whether the API key they pasted ended up in a bundle. This guide answers each in plain terms for App Builder Agent, then gives practical rules for handling your own users' personal data in the apps you build, since that is the part you are responsible for.

What runs in your browser and what runs on the platform's servers

• In your browser - the chat, the code editor, and the live phone preview. When you tap through your app in the preview, the app is running locally in the page. Nothing is installed on your computer.
• On the platform's servers - the AI agent's requests to the model, project storage, Android builds (test APKs and signed APK plus AAB), published websites at appbuilderagent.com/p/your-name/, AI workflows that run on a schedule or trigger, and the hosted backend if your app uses one.
• At the AI model provider - the prompts and the relevant project files the agent sends to generate code. The agent sends what it needs for the task, not your whole account.
• On your users' phones - anything the app you built stores locally (a to-do list, a cached menu). That data never touches the platform unless your app sends it to a backend.

Builds run on the platform's servers rather than on your machine, which is why nothing needs installing, and why a build takes seconds rather than an afternoon of setup. The AI app builder page describes the flow end to end.

Your account, your projects, your right to delete

• Sign-in is with a Google account only. There is no password to leak or reuse; access is governed by your Google account's own security, including two-step verification if you have it on.
• Projects are private to your account. A published website is public at its link by design; everything else stays with you.
• You can delete projects from the builder at any time. Export first if you want the code afterwards.
• Support is in the builder - a Support panel opens a chat with the team, so a question about your data goes to a person rather than a form.

What the AI model sees, and what to keep out of it

To write or change code, the agent sends your instruction plus the relevant files of the project to the AI model. That is the whole mechanism; there is no way to build with AI without the model seeing the code it is editing. What you control is what goes into the prompt.

• Describe data, do not paste it. "A customer list with name, phone and last visit" gives the same result as pasting fifty real customers, without the fifty real customers.
• Keep secrets out of chat. If you need the agent to use an API key, say "put this key in .env as STRIPE_KEY" once; do not repeat keys in later messages or write them into screens.
• Use sample content. Fake names, example.com emails and round numbers make good test data and are safe in prompts.
• Treat prompts as records. Chat history stays with the project so you can restore earlier versions; assume anything typed there persists until the project is deleted.

API keys and .env

When you give the agent a key for a third-party service (maps, payments, an AI model, SMS), it writes the key into a .env file in the project and the code reads it from there. That keeps keys out of screen code and out of the chat transcript after the first mention.

• A key used by the mobile app itself ends up inside the APK, as with any mobile app. Use publishable or restricted keys on the client, and keep secret keys on the backend side.
• Restrict keys at the provider: by app package id, by domain, by allowed API, and with spend limits where the provider offers them.
• Rotate a key from the provider's dashboard if a tester, an old build or a shared screenshot might have exposed it.

Owning and exporting your code

The editor shows the generated code, and you can edit it directly. On the Member plan ($1.49 per 30 days at the time of writing) and every plan above it, you can export the complete project as a zip: React Native or Flutter for mobile apps, a Vite site for websites. The exported code is yours, builds with standard tools, and does not depend on the platform. This is the answer to "what if the service disappears": export, and keep a copy alongside your signing key backup. The plan guide lists what each tier includes.

Honest limits

• No certifications are claimed. Do not read anything here as a compliance attestation. If your procurement process needs one, ask Support what can be provided and decide accordingly.
• The hosted backend is for small apps. It is built for bookings, orders, profiles, loyalty stamps, notes. It is not designed for regulated records such as medical files or full card numbers; use a specialist provider for those and keep only references in your app.
• AI-generated code can contain mistakes, including security mistakes such as an unprotected admin screen. Test with a second account, read the code for anything that handles money or personal data, and ask the agent to add checks where you find gaps.
• Published websites are public. Anything you put on a /p/ page can be read by anyone with the link.

Handling your users' personal data in the apps you build

Once your app has users, you are the one responsible for their data under GDPR, UK GDPR, CCPA or your local law. These habits cost almost nothing when the agent does the work.

1. Collect the minimum. A booking needs a name and a phone number, not a date of birth. Say so in the prompt.
2. Add sign-in and per-user data from the start. Ask for accounts with a hosted backend so each user sees only their own records; the login and dashboard guide shows the pattern.
3. Build the deletion path before launch. Google Play requires account deletion for apps with sign-up; it is also a GDPR right.
4. Write the privacy policy from what the app actually stores, publish it at a link, and put it on the About screen. The privacy policy guide has a checklist and a prompt.
5. Lock the admin screens. Owner dashboards must check a role, not just hide a button.
6. Do not log personal data. Ask the agent to keep phone numbers and emails out of crash reports and console logs.

Test every data rule with a second Google account: sign in as a plain user and try to open the owner dashboard, another user's booking, and the deletion flow. Five minutes of this finds more than an hour of reading code.

Apps with accounts and a dashboard are where these questions matter most, and the login and dashboard apps in the gallery show clean versions of the settings, deletion and role patterns above. Build yours with the rules in place, export the source when you go paid, and you will know exactly where your code and your users' data live.

Frequently asked