How to test a Google AI Studio app before launch

A working preview can show you a saved customer record without proving who else can open it. Before you polish an AI-generated feature, create two test accounts and try crossing that boundary.

Google AI Studio can help you generate an app, refine it through chat, and publish it. For a live SaaS, the useful question is whether you can explain and test what happens behind the screen.

What is Google AI Studio vibe coding?

Google AI Studio vibe coding lets you describe an app in plain language and use Gemini to generate and revise its code. Google’s product page describes starting from an idea, supplying screenshots or documents, remixing a project, and sharing the result.

The workflow starts with what you want the app to do. You inspect the result, ask for changes, and repeat. You can use that loop to explore a feature before committing to a larger build.

Google expanded the tool on 18 March 2026. Its announcement introduced the Antigravity coding agent and Firebase backend support. That matters if your idea needs more than a screen: connected apps also need to handle data and the rules around it.

For a small SaaS, a sensible first project might be a saved-draft feature. A customer writes a draft, saves it, leaves, and returns to edit it. Keep that example small enough that you can inspect every step.

The distinction between generating and checking code matters here. Google Cloud’s guide separates exploratory vibe coding from responsible AI-assisted development. The latter includes reviewing, testing, and understanding the generated code.

You can use AI Studio to build a demo or test a focused feature. Neither a successful prompt nor a polished preview proves that the feature is ready for paying customers.

Treat the first result as something to investigate. Ask what code runs, what data it touches, and what must happen before someone can access that data. If you can’t answer those questions yet, keep the feature away from real customer records.

How should you start building a focused feature?

Give Google AI Studio one complete user task, with clear limits and an observable result. “Let a signed-in customer save and reopen a private draft” gives you more to test than “build my content platform.”

Google’s website tutorial uses a staged process: describe the visual direction, create a written wireframe, then build and refine the site. You can apply that habit to a SaaS feature without confusing a website tutorial with a security checklist.

Write the feature’s rules before asking for code. For the private-draft example, your prompt could include:

• A signed-in customer can create, read, edit, and delete their own drafts.
• Another customer must not be able to access those drafts.
• A signed-out visitor must not receive private draft content.
• Use fake records while building and testing.

Those are requested behaviors, not proof that the generated code follows them. You still need to test each rule.

Ask for a short explanation of where the app stores records and where it checks access. Then compare that explanation with the code. Don’t accept “authentication is handled” as a complete answer. Signing someone in and deciding which records they may open are separate questions you need to check.

Leave visual polish until the basic task works under those rules. You can use screenshots or a mood board to guide the interface later. First, make the smallest useful version that lets you test saving, reopening, and refusing access.

A narrow feature also gives you a clear stopping point. You’re ready for the next review when you can demonstrate the promised behavior, including the refusals, with fake data.

Test two accounts before you polish the interface

Create two accounts you control and test whether either can access the other’s records in your Google AI Studio app. Use fake data in a test environment, never someone else’s real account.

Google Cloud’s guide says responsible AI-assisted development includes testing generated code. Checking who can access customer data is a concrete way to put that advice to work. It’s a recommended test here, not a claim that Google found a flaw in AI Studio.

Call your test accounts A and B. Create a draft under A with an unmistakable label. Then sign into B in a separate browser session so you don’t accidentally test with A’s login.

Try each action separately:

1. Open A’s draft while signed into B, using its saved link or record identifier.
2. Try to edit A’s draft from B’s session.
3. Try to delete A’s draft from B’s session.
4. Sign out and try opening the private draft again.

Check the result beyond the screen. Reopen the draft as A after an attempted edit or deletion. Confirm that its contents and existence haven’t changed.

If the interface hides A’s records from B, that only answers what B can see in the normal screen. Also inspect the requests that fetch or change a record. If you don’t know how, get help from someone who can review that path.

A private record must stay private even when someone requests it directly.

Record what you tried and what happened. A short test note is enough: account used, action attempted, expected result, actual result. Repeat the same checks after a fix. Don’t let a nicer error message substitute for confirming that the app refused the action.

Check paid calls before you connect real customers

An AI Studio feature that calls a paid service needs tests for secrets and spending before you expose it to customers. Treat these as separate checks from whether the feature produces a useful answer.

Google’s AI Studio codelab lists a Gemini API key and a Cloud project with billing enabled among its requirements. Those requirements don’t tell you how your own generated feature protects credentials or limits paid requests. You need to inspect that yourself.

For a draft-writing feature, ask the coding assistant to identify the exact path from clicking “generate” to calling the paid service. Read the relevant code rather than relying on the summary alone.

Check these points:

• Secrets: Verify that private credentials stay on the server and don’t appear in browser-delivered code or responses.
• Access: Confirm that an unauthorized request cannot trigger a paid call.
• Repeat requests: Test what happens when you submit the same action repeatedly or from separate sessions.
• Limits: Set and test limits appropriate to your feature, and check what the provider actually enforces.

Choose a small test allowance before you run these checks. Don’t test repeated paid calls without a stopping point.

Also test the refusal path. When a customer reaches your chosen limit, the app should stop the paid action and explain what happened. Verify that the service didn’t receive another paid request despite the message on screen.

Don’t assume a billing alert stops spending. Check the provider’s controls and their exact behavior. If you can’t verify a safe limit, keep the feature restricted until someone can help you do so.

How do you review code you didn’t write?

Review generated code by tracing one user action through the files and checks it depends on. For a Google AI Studio feature, start with the action that touches private data or triggers a paid request.

Google Cloud’s guide explicitly includes understanding the code in responsible AI-assisted development. Asking the model to explain its work can help you begin. That explanation still needs checking against the files and the app’s behavior.

For the saved-draft example, ask the assistant to show you:

• The code that receives the request to open a draft.
• The code that identifies the signed-in customer.
• The check that decides whether that customer may open the requested draft.
• The code that returns or changes the stored record.

Keep the question tied to an action. “Explain the security” invites a broad answer. “Show me what refuses account B’s request for account A’s draft” gives you a specific claim to verify.

Use the same approach when asking for a fix. Describe the failed test, the expected result, and the behavior that must remain unchanged. Then review the changed code and rerun the test with both accounts.

Keep a known working version before each substantial change. Google’s codelab includes saving a project to GitHub, which gives you a place to review and track code changes.

You don’t need to pretend you understand a file because the assistant sounded confident. If you can’t follow the access check or the paid-call path, ask a developer to review it before launch. That’s a smaller, clearer request than asking someone to bless an entire app.

How do sharing, GitHub, and deployment fit together?

Google AI Studio provides paths to share a preview, save code, and deploy an app, but those steps answer different questions. A preview helps someone try the experience; a saved repository helps you inspect changes; deployment puts a version into a running environment.

Google’s website tutorial describes sharing a full-screen preview with collaborators or friends. It also describes setting up billing to deploy a site to a custom domain.

The AI Studio codelab takes a generated “Snake & Beats” React app through saving to GitHub and deploying to Cloud Run. That demonstrates a route from a generated project to a deployed app. It doesn’t establish that a different app’s customer access rules have passed testing.

Use each step for a specific purpose:

1. Share a preview with fake data to check whether the feature makes sense.
2. Save the code so you can inspect and compare changes.
3. Deploy to a test environment and check the settings and behavior there.
4. Release to customers only after the relevant checks pass.

Don’t treat “one click” as a description of everything required to run a paid SaaS feature. It describes a publishing action. Your review still needs to cover the behavior you’re about to expose.

Check the deployed version too. Confirm that it uses the intended data, credentials, and access rules. Repeat the two-account test against that version rather than assuming the preview’s result carries over.

Keep a clear record of which version you tested. If you change the code or settings afterward, identify which checks need another run before you release it.

What should pass before an AI Studio feature goes live?

An AI Studio feature should pass written checks for its promised behavior, private data, and paid calls before you offer it to customers. The checks should let another person repeat your test and see the same result.

That follows the responsibility described in Google Cloud’s guide: you guide the AI, then review, test, and understand what it generated. A successful preview covers only the behavior you actually observed in that preview.

Write a short release note with evidence for each relevant check:

• Core task: A test customer can complete the feature’s promised job.
• Private records: Account B cannot read, edit, or delete account A’s fake records.
• Signed-out access: A visitor without a login cannot retrieve private content.
• Paid requests: Credentials stay server-side, unauthorized calls fail, and tested limits stop further requests.
• Deployed version: The version you plan to release passes the checks in its intended environment.

Mark a check as untested if you haven’t run it. Don’t convert “the assistant says it handles this” into a pass. Keep the code explanation separate from the result you observed.

These checks aren’t a complete security audit. Your app may need more review depending on what it stores and does. If a feature handles sensitive records or you can’t verify its access rules, get qualified help before exposing it.

You can still use AI Studio to move quickly. Keep the scope small enough that you can check the work without guessing.

Before your next interface pass, create two fake customers. Save a private record under one, then try to open, change, and delete it as the other. If any attempt succeeds, stop the release and fix that path first.