An AI-built app is not ready for customers simply because its demo works. Before opening access, check that data is stored correctly, users can see only the records they are allowed to access, and your team knows what to do when a service fails. A demo helps you assess an idea; operational readiness needs testing.
Suppose you have built an appointment request app. The map appears, the form looks tidy and the save button shows a success message. Does the request remain after the browser closes? Can another customer open its details? Answer these questions before accepting real data.
Demos are easier to build, but business responsibilities remain
On 9 November 2026, Google announced Maps integration in AI Studio. Users can build sample branch finders or route planners through prompts: instructions describing the app they want.
Google distinguishes demo use from production. The integration documentation explains daily Maps Demo Key limits and the need to connect a billing account for production. Making a map appear does not automatically resolve access settings, data requirements or your business service process.
The same checks apply to AI-built apps made with other tools. Assess how the application behaves in use, rather than the name of the model that wrote its code.
Check that visible features actually complete the job
A prototype is an early version for trying the interface and workflow. Some data may still be sample material, and buttons may not connect to the real process. Before continuing development, ask which parts work and which remain simulations.
Choose one complete journey, such as a customer sending a request and an administrator responding. Follow it to the end. Do not stop when a confirmation page appears; check the administrative record and the notification your team receives. For browser-based requirements, the scope of a web application or internal system should cover that workflow.
Check login and data permissions together
A login page is insufficient evidence that data is protected. A signed-in customer should still be restricted to their own records. Administrators need appropriate permissions too, rather than unrestricted access simply because it made the demo easier to build.
Ask your developer to test different accounts in a testing environment. Try accessing another user’s order details and check that the system refuses. Include the services behind the interface, rather than merely hiding buttons. In its Firebase security checklist, Google recommends denying access by default and then granting access to the required resources. Implementation depends on the application’s technology.
If the app uses personal data, limit collection to what the process requires. Define who can see it and how deletion requests will be handled. Avoid putting real customer data into trials before access and permitted use are clear.
Distinguish sample storage from operational data
Ask where data is stored and who controls the storage account. Test whether changes remain after reloading the page, switching devices or signing in again. Data appearing to be saved in one browser does not establish that the whole storage process meets your requirements.
Check what happens when the connection drops as someone presses a button. Users need to know whether a request succeeded, failed or is still processing. For actions such as bookings, test that retrying does not create duplicate records.
If the app needs stock, payment or accounting connections, discuss system and API integration early. An API is a way for systems to communicate. An interface using sample data does not establish that the connection works with actual data and permissions.
Calculate costs once people start using the app
Separate building costs from running costs. List the services involved, such as hosting, databases, file storage, email, maps or AI models. Check which charge according to usage and what happens when a quota runs out.
Do not assume a free trial arrangement continues when customers use the app. For the Maps in AI Studio example, Google explains demo and production terms separately. Budget around your chosen configuration and usage pattern rather than extrapolating from a short demonstration.
Define who receives usage alerts and who can change limits. For infrastructure, consider administrative access and recovery as discussed in our hosting selection guide. Cost alerts support monitoring; do not assume they automatically stop all charges.
Review keys and service account management
Ask your developer to explain which credentials may be present in the user application and which must remain on the server. API keys do not all perform the same role. Firebase explains that certain keys identify a project, while authorisation still depends on access rules and other settings.
For other service keys, apply appropriate restrictions, such as the applications or APIs permitted to use them. Service account private keys and server secrets must not be embedded in code sent to the browser. Make sure the business has the administrative access it needs without sharing one personal account among everyone.
Test failures and assign responsibility for problems
Separate testing from the application customers use. Firebase’s guidance also recommends separate development, staging and production environments. Staging is where changes are tried before reaching the live service.
Alongside normal journeys, test empty data, invalid input, slow connections and unresponsive third-party services. Record the results so your team knows which issues are resolved and which remain deferred. Failure messages should help users continue without revealing sensitive information.
Agree who manages backups, how restore testing works and how to return to an earlier application version if an update causes problems. Maintenance does not end when you share the app’s link. Someone needs to monitor errors and assess updates to the services and libraries in use.
Start with a launch your team can supervise
Before widening access, run a pilot with selected users, defined tasks and clear limits. Record problems and how they were handled. A pilot helps identify gaps within the trial’s scope, but does not guarantee that every risk has been eliminated.
If an important journey cannot yet be tested or data access remains unclear, keep that part out of customer use. Bring the prototype, a list of working features and test findings to the next discussion. Book a Consultation with Webzoo to discuss your business application requirements.
