AI App Builder Checklist: Test Permissions, Recovery and Code Handover

The demo looks ready. You sign in, create a request, attach a photo and watch a tidy dashboard update. Then a colleague opens the app with a second account and sees the request you just created, even though it belongs to a different customer.

That is the kind of test to run before a successful demo becomes a production launch.

An AI app builder can help you reach a working screen quickly. The next question is whether the application behaves correctly with different users, real records and failed requests, and whether someone can maintain it after the person who prompted it has moved on.

The checklist below uses a hypothetical service-request portal: customers submit work, staff update its status and managers review the queue. Adapt the tests to your own workflow. Our guide to evaluating a new AI model covers model selection; this guide is about accepting the application built around it.

Write down the job the app must complete

Choose one journey that matters to the business. For this portal, a customer should submit a request, receive a reference and be able to find the saved request later. Staff should see the requests assigned to them and record their work. A manager needs the permissions appropriate to the queue they oversee.

Describe the result in business terms before discussing frameworks or prompts. Which record must exist? Who can read it? What confirms that an update succeeded? A loading animation and a notification are not enough evidence that the receiving system saved the work.

Keep the first release narrow. If the portal is meant to replace a submission form, you may not need generated invoicing, scheduling and customer messaging in the same pilot. Each extra feature adds decisions about access, data and recovery that someone has to own.

Use representative test records, including awkward ones. Long names, empty optional fields, older requests and attachments from a phone will tell you more about everyday usability than a single perfectly formatted example.

Test the second account before adding more features

Create two separate customer organizations in a test environment. Add an ordinary user and an administrator to each. Decide what every account should be able to read and change, then test those boundaries through the interface and the application's request paths.

Try opening a record from the other organization using its URL. Check lists, searches, exports and attachment links as well as the detail page. Hiding a button does not establish that the underlying operation rejects an unauthorized request.

Test signed-out and expired-session behavior. A person should not keep access to private records because an old page remains open. Also check what happens when an administrator removes a user or changes their role.

For Firebase applications, Google's Security Rules testing guide describes emulator-based tests with authenticated and unauthenticated contexts. These can help turn permission expectations into repeatable checks. Review the server path separately: Firestore's security documentation notes that server client libraries bypass Firestore Security Rules and use application credentials, making the server's authorization and IAM configuration important too.

Whatever database you choose, ask the team to demonstrate the denied cases. A successful login establishes identity; the application still needs to decide which records and actions that identity may access.

Use release gates with evidence someone can inspect

This is an original acceptance framework for the example portal. It does not assign scores to particular app builders. A failed boundary check should stay visible rather than disappearing inside an average quality score.

For each row, name the person who can accept the result. Product can confirm the intended journey, engineering can explain the implementation and the operating owner can verify that recovery is workable. A screenshot is useful when it shows the result, but often needs a stored record or a denied request beside it.

Find out where the demo data ends

Replace sample records with a small, controlled test dataset. Create a request, sign out, sign in again and check the saved fields. Open it from another authorized account. Edit it and verify which values actually changed in storage.

Then check relationships. If a staff member belongs to two teams, does the request appear in the right queue? If an account is deactivated, does the system preserve the history without continuing to grant access? Similar totals can hide incorrect relationships.

Test attachments from upload through retrieval. Check who can open them, what happens when an upload fails and whether a deleted or replaced file leaves an incorrect reference behind. A visible thumbnail may represent only local browser state until the upload finishes.

Ask the builder for changes in small steps and inspect the resulting difference. Regenerating a screen can change assumptions about a field or an API response. Keep a few existing records in the test set so a new feature does not quietly make older data unreadable.

Make failed and repeated requests part of the review

Double-click the submit button. Refresh while a request is being sent. In a controlled test, interrupt a connection after the backend may have accepted the write. The user needs a way to find out whether their request exists before submitting another copy.

Give important operations a reference the application can use to recognize a repeated attempt. The exact design depends on the service, but the desired result should be clear: one intended request and an understandable outcome when the customer retries.

Now make an external dependency unavailable in the test environment. The app should explain what is still pending and who can resolve it. A message saying “something went wrong” may leave the customer unable to decide whether to wait or repeat the action.

If the app uses a model, test the business journey when that model is slow, unavailable or gives an unusable response. Decide which work can continue without it. For this portal, saving the customer's request may be more important than generating a suggested category immediately.

Run the code outside the original workspace

Have a second developer start from a clean checkout with documented configuration. They should be able to install dependencies, run checks, build the application and identify which external services it requires.

Google AI Studio's Build mode documentation describes GitHub synchronization and ZIP export for external development. If you use another builder, verify its current export and deployment options directly. Exporting files is the start of the test; getting a working application from them establishes whether the handover is complete.

Keep server credentials out of client bundles and repositories. Distinguish private service secrets from configuration designed to be public, and document how the deployment receives each value. A replacement developer should not have to ask someone to copy credentials from a chat history.

Check ownership of the repository, domain, deployment project and billing account. The organization relying on the app needs a practical way to manage those resources when a contractor leaves or a team member changes role.

The development environment can change too. Google's Firebase Studio migration notice sets its shutdown for March 22, 2027, with new workspace creation and signup already disabled from June 22, 2026. The notice says core Firebase backend services continue outside Studio. For teams with existing workspaces, this is a concrete reason to test their migration and handover before the deadline.

Review the running cost against the actual workflow

List the components that produce charges: hosting, database work, storage, outbound messages, model calls and any paid integrations. Check how they behave when a customer refreshes, uploads a large file or repeats an unsuccessful task.

A quiet demo gives little evidence about a month of production use. Model a normal period and a busy period using your expected volumes, then compare the assumptions with usage from a limited pilot. Keep setup costs and ongoing maintenance visible as well.

Make sure cost notifications reach someone who can act. Google Cloud's budget documentation distinguishes alerts-only budgets from supported spend-cap controls. An alerts-only budget does not automatically stop usage or spending. Check what applies to each service rather than treating a notification threshold as a universal spending limit.

If the business needs a firm operating ceiling, decide how the application should respond as it approaches the applicable limits. A clear restriction or a reduced feature set may be more manageable than an unexpected bill or a sudden, unexplained failure.

Try the recovery procedure with someone who did not build it

Restore a test backup into the agreed test environment and check the recovered records. Open an attachment, inspect a request history and verify the relationships the business depends on. The presence of a backup file does not establish that the service can be restored from it.

Practice returning to the preceding application release. Consider what happens if the newer release changed stored data. Switching the interface back may not reverse that change, and you need a plan for records created after the rollout.

Leave a short operating guide with the app owner. Include how to find a failed request, which service to inspect, who can repair access and what should trigger a rollback. Ask a colleague to use the guide during a rehearsal and note the steps that require unwritten knowledge.

A limited pilot can be appropriate once the agreed gates pass. Keep its user group and purpose clear, review failures and costs, and expand only when the evidence supports the next step. You can still benefit from fast AI-assisted development while giving the team a system it knows how to run.

Our full-stack development team can review and complete the application around an AI-built prototype. Where model calls or agent actions need their own evaluation, our AI agent development services can help define those checks. Contact Emerging Stacks with the prototype, its intended users and the journey you need to make dependable.