How to Know When an AI-Built Application Is Ready for Production

An AI-assisted tool can produce a working interface quickly. That is not the same as an application a business can depend on. The gap is made up of access control, data rules, integration behaviour, error handling, monitoring, documentation, ownership and a support arrangement — none of which are visible from the screen.

The fastest thing to produce in modern software is the part you can see. A form, a table, a dashboard and a login screen can all exist within hours, and they will behave correctly for the person demonstrating them.

Production is a different test. Production means other people, real data, other systems, mistakes, edge cases, and a Tuesday morning where something fails and someone has to work out why. Most of what makes that survivable sits behind the interface.

So the approval question is not "does it work?" — in a demo, it almost always does. The question is "what is it doing, and what happens when something goes wrong?"

Authentication answers whether someone is who they say they are. Authorization answers what they may then do. They are separate problems, and the second is the one that gets skipped, because a demo is usually run by one account that can see everything.

Ask to be shown the application from a limited account, not the owner's account. A manager who can reach another department's records, or a customer who can change an identifier in a URL and load someone else's data, is a production defect regardless of how the screen looks.

Data outlives the application. It is worth knowing where it lives, who administers it, what shape it is in, and whether it can be exported without a developer present.

Two questions surface most problems: what happens when a required field is missing, and what happens when the same record is submitted twice. If neither has been considered, the data will drift quietly, which is worse than failing loudly.

Most business applications are only useful because they are connected to something else — email, payments, a CRM, a file store, an internal API. Each connection is an assumption about another system's behaviour that may change without notice.

Keys and secrets belong in server-side configuration, never in front-end code, and never in a repository. Confirm which credentials exist, who holds them, and what happens when one is rotated.

The realistic goal is not an application that never fails. It is an application that fails in a way somebody can see, understand and act on.

Ask what a user sees when an action fails, where that failure is recorded, and how anyone finds out. An application with no logs is a system nobody can support, including the team that built it.

Testing confirms that the paths you care about behave as intended. Verification is a different activity: understanding what is actually in the application — its structure, dependencies, configuration and changes — rather than confirming the screens respond.

This is the reasoning behind MessyProof, our own verification technology: it examines a codebase and reports what is there, so the state of a build can be inspected rather than assumed. A verification review reports detectable signals. It is not a security certification and it is not a guarantee of production readiness.

The cost of an undocumented application is not paid at launch. It is paid the first time it needs to change, when the person who built it is unavailable and nobody can explain the parts that are not obvious.

Documentation does not need to be long. It needs to cover how to run it, how to deploy it, what it depends on, which accounts and credentials exist, and what is deliberately unfinished.

An application that has launched still needs a named route for changes, failures and questions. If that route does not exist, the application becomes the informal responsibility of whoever asked for it.

Settle it before launch: who is contacted, through what channel, and what the arrangement covers.

None of this requires reading code. Each item is something you can ask for and be shown.