Production readiness check for AI-built apps

Access

Can someone get at your data without signing in?

Done when: Someone who did not build the application has tried it - including going around the sign-in screen, straight to the addresses the application calls in the background. Without signing in, no data comes out.
Open when: There is a sign-in page. Whether the data behind it is protected too, nobody has checked.
Why it matters: AI tools often build a sign-in page but no check behind it. Anyone who knows the right address then gets at the data without a password.

Does everyone see only what they are allowed to see?

Done when: There are roles, and the application checks them on every request - not just by hiding buttons. Someone has tried with two different accounts whether other people’s records can be reached.
Open when: Everyone sees everything, or the restrictions exist only in the interface.
Why it matters: A hidden button protects nothing. Otherwise anyone who changes a number in the address bar sees another customer’s order.

Are passwords or access keys written into the code?

Done when: The keys to the database, payment service or AI service sit on the server only - not in the code the browser loads, and not in earlier versions of the code.
Open when: Nobody knows for sure, or the keys are written straight into the program.
Why it matters: Whatever reaches the browser, any visitor can read. An AI service key sitting there gets used at your expense.

What happens to accounts when someone leaves the company?

Done when: Everyone has their own account - in the application, in the tool it was built with and with the services it runs on. There is a fixed procedure for who locks which accounts.
Open when: Several people share one account, or the accounts are tied to a private email address.
Why it matters: The most common open account belongs to an employee who left two years ago.

Do you know where your customers’ data goes?

Done when: It is written down which outside services receive data - database, server, AI service, email delivery - and where they are based. Your data protection officer knows the list.
Open when: The application sends text to an AI service, but nobody has checked what it contains and where it ends up.
Why it matters: Which services the application uses may well have been decided by the tool, not by you.

When did you last actually restore a backup?

Done when: There is a backup outside the service the application runs on as well, and it has been restored with the real data.
Open when: The provider probably makes backups, but nothing has ever been restored.
Why it matters: A backup that has never been tested is an assumption, not a safeguard.

Let’s discuss your requirements. Book a call →

Is a change tried out before everyone works with it?

Done when: There is a test version with its own data. Changes go there first, and someone checks the key workflows before they reach the real application.
Open when: Changes are made directly in the application everyone works with.
Why it matters: Tell the AI to “rework this” and it often changes more than you asked for. Without a test version, you only notice in daily work.

Can you get back to yesterday’s version?

Done when: Every change is saved, and an earlier version can be restored - of the program and of the data.
Open when: There is only the current version, or going back means asking the AI to undo everything.
Why it matters: When something stops working after a change, the quickest way back is the version that ran before.

When something goes wrong - who notices, and when?

Done when: The application reports errors itself, to an address someone reads.
Open when: It gets noticed when someone complains.
Why it matters: The most expensive error is not the loud one, but the one that runs unnoticed for three months.

Who keeps an eye on the running costs?

Done when: It is known which services bill monthly and on which card. For the services that bill by usage, there is a cap or a warning.
Open when: The bills go to a private credit card, or nobody knows what happens with twice as many users.
Why it matters: AI services bill by usage. A fault in the program or outside access shows up on the bill first.

Does anyone understand how the application is built?

Done when: At least one person can explain where each piece of data lives and how the parts fit together - without asking the AI.
Open when: The application grew out of many instructions to the AI, and nobody has read the code - not even whoever built it.
Why it matters: As long as everything runs, it goes unnoticed. At the first error the AI cannot fix by itself, it shows.

If someone else had to carry on building tomorrow - what would they find?

Done when: The code is in a place the company has access to, and it can be taken out of the tool it was built with. It is written down which services it depends on and what they cost.
Open when: The code sits in an employee’s personal account or only inside the tool, and nobody has tried to get it out.
Why it matters: This point decides whether an application is an asset or a liability.