Deploy an AI-built app: a pre-launch checklist

Quick answer: Before you deploy an AI-built app to real users, trace every exposed route to its data and permissions, then require evidence for secrets, dependencies, data migrations, backup restoration, failure handling and rollback. Put one owner, one observed result and one launch-stopping condition beside each critical control. A working local demo shows the happy path; the pre-launch decision depends on what happens when another user calls an API directly, a migration changes data, or a service fails.

Important constraint: A checklist is a release gate, not a security certificate. OWASP ASVS offers detailed control verification, the OWASP Top 10:2025 describes common risk classes, and NIST SSDF describes secure-development practices. None automatically establishes that a particular generated or hand-written app is safe. Tailor the checks to the data and promises of the app you are actually launching.

AI assistance can produce routes, database queries and deployment files faster than one person can review them. That changes the review workload, not the standard of evidence. The person operating the app still needs to know what is public, what each user may do, where secrets live, how data changes, and how to recover. Use the following worksheet for a small web app; adapt the exact commands and controls to your stack.

Draw the application boundary first

List every way information enters or leaves the app: public pages, authenticated API routes, admin functions, background jobs, file uploads, email or payment integrations, data stores and deployment configuration. For each, note which user role can reach it and which records it can read or change. A landing page, a scheduled export and an internal-looking API can have different risk despite living in one repository. Do not let a generated UI sitemap stand in for a route inventory; include endpoints that are callable without the UI.

Add an owner and a concrete proof next to each boundary. “Authentication added” is a weak entry. “Alice’s authenticated request for Bob’s record returns no Bob data and changes nothing” is an observable result. “Backup enabled” is weak; “a backup from the intended recovery point was restored into a separate environment and opened successfully” is stronger. Keep the evidence private and avoid placing customer data or credentials in the release record.

The hold column is intentionally specific. Lower-impact gaps can be assigned an owner and due date if the launch owner accepts them, but a missing result that undermines promised data protection or recoverability deserves a stop. Do not average a failed authorization check with six green checkboxes into a passing score.

Prove authorization at the server, not only in the UI

Imagine a two-user records app. Alice owns record 41, Bob owns record 42, and the page hides Bob’s record from Alice. That looks correct in a browser. Now send an authenticated request as Alice directly to GET /api/records/42. If the server returns Bob’s content, the hidden button did not provide authorization. OWASP’s Broken Access Control guidance calls for trusted server-side enforcement and deny-by-default behavior.

Test the ownership rule on read, update and delete operations, and on exports or background jobs that return records through another route. The exact denial status can depend on the app’s design; the essential result is that Alice cannot read or change Bob’s data. Repeat with a normal user calling an admin endpoint. If the rule fails, fix the server policy and run the same request again. A browser screenshot of the corrected page is still not evidence for the API path.

Make the permission cases repeatable. Create two ordinary test accounts and one admin account with known sample records. For each route, record the caller, target record owner, expected result and actual result. Include an unauthenticated caller, the record owner, another authenticated user and the admin role where relevant. Re-run the same cases after changes to routing, database policies or generated authorization helpers; a fix to one endpoint does not prove a second endpoint enforces the same rule. Keep the test records synthetic so the evidence can be reviewed without exposing customer information.

Input and output boundaries deserve their own sample. Submit unexpected text, missing fields and an oversized or malformed payload through the public route; confirm that server validation applies where the data is accepted and that error messages reveal neither internal details nor another user’s data. Check where untrusted text later appears in a page, email or export. Choose tests appropriate to the stack and data types rather than treating a generic scanner as complete coverage. ASVS is a useful source for expanding the control list beyond this short launch worksheet.

Account for secrets and dependencies in the deployed artifact

Inventory production credentials for the database, email, payments, storage and external APIs. Note which build or runtime can read each one and who can rotate it. Inspect source, repository history, deployment settings and diagnostic output for accidental exposure. OWASP’s secrets guidance covers storage, access and rotation; moving a hardcoded key into an environment variable is only one step and does not make that variable safe from every log, build or access path.

If an active secret has reached a repository or log, deleting the visible line alone leaves the credential usable and may leave copies in history or artifacts. Revoke or rotate it, change the deployed value, and investigate where it was used. GitHub’s secret-scanning documentation describes alerts for supported patterns, with availability and configuration differences. No alert is not evidence that every credential is absent; a manual inventory and scoped review still matter.

Record the manifest and lockfile used for the release. Review new dependencies and consequential advisories, especially packages that run in production or in the build that produces production code. GitHub’s dependency-review feature can help when configured, but its output is one input to a decision. If an alert appears, document whether the affected path is used and what update, replacement or mitigation the owner accepts. Do not use “scanner clean” as a claim about all source code or transitive behavior.

Rehearse a data change and a restore

Take a production-like copy of the schema and suitable non-live or properly protected data. Apply the proposed migration there. Check the rows and queries the new build needs, then check whether the previous application build can still operate against the changed schema. A code rollback and a data rollback are different actions: restoring an older container or deployment does not put a dropped column back. Django’s migration guide even documents operations that cannot be reversed. The principle applies beyond Django, though the exact migration mechanism belongs to your framework.

For a concrete rehearsal, suppose the records app changes the field Alice and Bob use to label a record. Create test records, run the migration on an isolated copy, and have both the new and prior build attempt the relevant read and write paths. If the migration removes a field the prior build still requires, a platform’s “roll back” button may restore code that cannot serve the existing data. Decide whether to stage the schema change compatibly, adjust the deployment sequence, or prepare a tested data recovery path before launch.

A restored database can also roll back newer user writes. Specify the acceptable recovery point and who can authorize that loss before the release, rather than assuming a snapshot is a harmless undo button. If the business cannot accept that gap, plan a migration and deployment sequence that avoids a destructive cutover, or delay the release until a suitable recovery method is proven. Write this decision beside the rollback trigger so an operator facing an incident knows whether to revert code, restore data, or hold traffic while the team investigates.

Next, restore a backup to an isolated destination and verify that the expected records and schema are usable. A completed backup command is not the same as a completed restore. PostgreSQL, for example, documents multiple backup and restore strategies, and pg_dump can produce an export; neither fact proves that this application’s backup includes every dependency or reaches the required recovery point. Record the backup’s scope, time, retention, restore duration and the person authorized to perform recovery. If the app promises to preserve user data and no usable restore exists, hold launch.

Observe failure handling and rollout readiness

Exercise a safe, expected error, such as a denied request or an unavailable noncritical integration. The user should receive a useful but nonrevealing response. The operator should receive enough diagnostic context to identify the failure, without dumping credentials or private records into the log. OWASP’s error-handling and logging guidance treat these as distinct design needs. Check that a consequential failure produces an alert that reaches a named owner, not merely a line no one reads.

Define readiness from the user’s perspective. A process can be running while the database is unavailable or a required migration has not finished. Kubernetes readiness probes are one example of gating traffic to a container; another host will have its own equivalent. Whatever the platform, verify how it decides a release can receive traffic and what smoke check confirms the real app path. Identify the previous working artifact and the trigger for reverting to it. Kubernetes documents deployment rollback, but that command does not undo database writes or guarantee the old code understands the new schema.

Close with a signed-off release record: what version and configuration were tested, which checks passed, which gaps remain, who owns each gap, and what would stop or revert the launch. A generated app is ready for public traffic only when its specific protections, data changes and recovery route have evidence acceptable to its owner. Completing the worksheet lowers uncertainty; it does not establish zero defects. The hosting hub covers infrastructure decisions that follow once the application boundary and operating responsibilities are clear.