Your AI-built app works. But is it ready for production?

You’ve built the app. You can sign in, add a record and show someone the result. That’s a real achievement, especially if a few weeks ago the whole thing was an idea in a notebook.

Then someone asks whether customers can start using it. It’s a reasonable question, and a surprisingly different one from “does the demo work?”

The next step is to look at what people will depend on. Can they trust the data? Can you make a change without breaking something unrelated? If a service goes down, will you know what happened and how to recover?

These questions apply to any application. An AI tool’s involvement tells you very little about the answers on its own. Follow the important behaviour and check the evidence.

Start with the things people will rely on

Pick two or three important user journeys. For a hypothetical customer portal, that might mean signing in, uploading a document and sharing it with the right person. Write down what success means beyond the screen looking correct.

A successful upload should still be there after a restart. The intended recipient should be able to open it. Another customer shouldn’t. If the upload fails, the person using the app needs a clear answer about whether to try again.

Walk through those journeys in a safe test environment, including the awkward cases:

• Someone submits the same request twice.
• Two people change the same record at roughly the same time.
• An outside service is slow or unavailable.
• A user’s access is removed while they still have a page open.
• A background task stops before finishing its work.

You’ll soon have a more useful conversation than “we need more testing”. You’ll know which outcome needs protecting and what you’ve actually tried.

Can someone else pick it up?

Ask an engineer who didn’t build the app to follow its setup instructions. Can they run it with test data, find the important business rules and make a small change? Where do they need help?

Those questions reveal more than whether the files look tidy. A rule copied into three places might be easy to read and still be easy to change incorrectly. A clever abstraction might save lines while hiding where something happens.

Look for tests around behaviour that matters, dependencies with a clear purpose, and short notes explaining decisions that aren’t obvious from the code. You should also know who controls the repository, hosting, domain and backups.

You don’t need a manual for every function. A reliable setup guide, a simple system map and a few important decisions written down are a useful beginning. If ownership is your main concern, the guide to taking over an AI-built app goes through the handover in more detail.

What happens when a part of it fails?

Take the document upload in our example. Perhaps the file reaches storage, but the database update fails. Or the upload completes and the response gets lost. What will the user see? Can the app recognise a repeated attempt, and can someone find incomplete work?

Follow each important operation far enough to understand what can be left behind. Decide which failures the app can recover from automatically and which need someone to investigate. An endless retry loop is rarely a useful answer.

The quiet cases deserve deliberate attention. People can report a broken screen. They may have no reason to suspect that a reassuring success message is wrong.

Recovery matters too. Find out what is backed up, how old a restored copy would be and how long recovery takes. Database backups, uploaded files and configuration may need separate arrangements. PostgreSQL’s backup and restore documentation, for example, distinguishes SQL dumps, file-system backups and continuous archiving; the method affects the recovery options.

Rehearse recovery somewhere isolated, with live emails and other side effects disabled. Check a real task against the restored app. A backup file existing is a useful start, but it doesn’t demonstrate that you can get the service working again.

Check permissions where the data is accessed

A login screen confirms very little about who can see what once they’re inside. In our portal, removing the “download” button wouldn’t stop someone requesting the file directly.

OWASP’s authorisation guidance recommends checking permissions on every request and denying access unless it is explicitly allowed. Check those rules in the trusted part of the system that handles the request, rather than relying on the interface.

Use separate test accounts to check the boundaries: a normal customer, another customer and an administrator, for example. Include downloads, exports and older links. Do this only against systems and data you’re authorised to test.

Trace sensitive data through storage, logs, backups and deletion. Check where credentials live and whether uploaded files are handled appropriately. Keep the review proportionate to the app, while being clear about what hasn’t been examined. A general readiness review can identify risks; it doesn’t establish that every vulnerability has been found.

Will you notice when it stops working?

Start with plain questions. Can customers finish their task? How long does it take? Is background work falling behind? Who receives the alert, and what should they do first?

Google’s monitoring guidance makes a useful distinction between observing a system from the inside and checking its externally visible behaviour. For the portal, both the server’s error logs and a safe check that a document can be retrieved may be useful. A server that responds successfully can still serve a broken application.

Keep enough context to follow a problem, such as a request reference and the running release, without recording passwords or unnecessary customer data. Give urgent alerts an owner. Test the route the alert takes; finding out that it goes to an abandoned inbox during an outage is avoidable.

The reliability note turns these questions into a practical sequence of work.

Make a release decision you can explain

A tool used by three colleagues and a public customer service have different consequences when they fail. Agree the standard for your app based on who uses it, what data it handles and what recovery would involve.

End the review with a short decision list:

1. Fix before release. Name the problem, its consequence and the evidence that will show it is resolved.
2. Accept temporarily. Record who accepts the risk, why, and when the decision will be revisited.
3. Watch in operation. Say what you’ll measure and what result should trigger action.
4. Revisit when things change. Link future work to a real trigger, such as opening access to a second customer organisation.

For our portal, access to another customer’s files would block release. A slow preview might be acceptable temporarily if the file remains available and the limitation is understood. The distinction comes from the consequence, not the size of the code change.

You won’t remove all uncertainty. You can replace the biggest assumptions with evidence, give the remaining work an owner and know what you’ll do if something fails. That’s a much firmer basis for letting people depend on the app.

Further reading

• OWASP: authorisation — enforcing access rules and checking them consistently.
• PostgreSQL: backup and restore — the different approaches to database recovery.
• Google SRE: monitoring distributed systems — useful checks and alerts.