AI-Built App Production-Readiness Checklist
An AI-built app is production-ready when you can explain what must remain true, verify those rules across every critical flow, detect failures, and recover without guessing. “The demo works” is useful evidence about the idea. It is not evidence that the system is safe for customers, payments, or sensitive data.
Use this production-readiness checklist before launch, before a major customer arrives, or whenever an AI coding agent has made enough changes that nobody can confidently describe the whole system.
1. List the critical user journeys
Start with the product, not the repository. Write down the flows that create value or material risk:
- Create an account and verify identity
- Join or create the correct organization
- Complete the product’s core job
- Upgrade, pay, cancel, refund, and regain access
- Invite a teammate and assign a role
- Export or delete data
- Recover from a failed external service
For each journey, name the successful result and the failures that must not happen. “A user can view a dashboard” is incomplete. “A signed-in member can view only the dashboard for organizations they belong to” is a rule you can test.
If the team cannot agree on the rules, the app is not ready for a code-only audit. It first needs a small amount of product and domain modeling.
2. Enforce authorization on the server
Authentication answers who the user is. Authorization answers what that user may do. Hiding an admin button, redirecting in the browser, or checking a role only in a React component is not authorization.
Verify that every sensitive read and write is protected at a server or database boundary. Test with at least:
- A signed-out user
- A normal user
- A user from another organization or tenant
- An admin
- A disabled or removed user
Try requests directly rather than relying only on the interface. A polished screen can conceal an endpoint that accepts the same operation without the expected check.
3. Prove tenant and row isolation
Multi-user products need explicit ownership rules. Every customer-owned record should have a defensible path from the current identity to the permitted row.
For Supabase applications, Row Level Security is a key database boundary. Supabase’s own guidance explains that RLS and grants work together, and that exposed tables need both configured deliberately. Read the official Supabase Row Level Security guide.
Test isolation with two real test accounts. Create data as account A, then attempt to read, update, and delete it as account B. Repeat the test for storage objects, views, functions, and admin operations—not just the obvious tables.
4. Separate public configuration from secrets
Anything shipped to a browser should be treated as public. Search the source, build output, logs, commit history, and deployment configuration for:
- Database administrator or service keys
- Payment provider secrets
- Email provider keys
- Private AI provider keys
- Cloud storage credentials
- Internal tokens embedded in URLs
When a privileged key may have been exposed, removing it from the latest file is not enough. Rotate it, review access logs, and determine whether the exposure requires incident handling.
Supabase explicitly warns that secret and legacy service_role keys bypass RLS and must remain in backend components. Its API key documentation distinguishes publishable browser keys from elevated server-side keys.
5. Make payments a verified state machine
A redirect to a “success” page does not prove payment. The browser can close, retry, lie, or arrive before the payment provider finishes processing.
For each billing event, verify:
- The server checks the webhook signature
- Duplicate events do not create duplicate entitlements or orders
- Events can arrive out of order
- A retry after partial failure is safe
- Refunds, chargebacks, cancellations, and failed renewals update access correctly
- Money received and product access can be reconciled
Stripe documents why webhook signatures should be verified using the raw request body and endpoint secret in its official signature guide. Treat payment processing as asynchronous, repeatable state transitions rather than one successful frontend request.
6. Put constraints in the database
Generated interfaces often validate inputs beautifully while the database accepts states the product cannot handle. Important invariants should survive a broken UI, a retry, a background job, and a future integration.
Look for appropriate:
- Unique constraints
- Foreign keys and deletion behavior
- Non-null requirements
- Check constraints
- Transactions around multi-step changes
- Idempotency keys for repeatable operations
- Explicit timestamps and audit fields where needed
Then test migration behavior against a copy of realistic data. A migration that works on an empty development database may fail after customers have created inconsistent records.
7. Exercise dependency and integration failures
Every external dependency will eventually be slow, rate-limited, unavailable, or inconsistent. For each important API, answer:
- What is the timeout?
- Which errors are safe to retry?
- Can a retry duplicate work?
- What does the customer see?
- Is partial progress stored safely?
- How does an operator resume or repair the job?
Do not retry everything. Some failures are permanent, some operations are not idempotent, and uncontrolled retries can turn a provider incident into your own outage.
8. Make deployments repeatable
Write down how a commit becomes production software. The answer should cover:
- Build and type checks
- Required environment variables
- Database migrations
- Background workers and schedules
- Domains and callback URLs
- Health checks
- Rollback or forward-fix strategy
- Who can deploy
Run the process from a clean environment. If production depends on files, packages, or manual actions present only in the original builder workspace, the deploy path is not ready.
9. Add observability around business failures
An uptime check can say the homepage is healthy while every checkout fails. Monitor technical and product signals:
- Server errors and rejected jobs
- Payment webhook failures
- Authentication and invitation failures
- Queue depth and repeated retries
- Third-party latency and rate limits
- A drop in successful completion of the core product flow
Logs should contain enough context to trace a request or job without recording passwords, access tokens, full payment data, or unnecessary personal information.
10. Verify backups by restoring one
“Backups enabled” is not the same as recoverable. Record:
- What is backed up
- How frequently
- How long copies are retained
- Who can access them
- The expected data-loss window
- The expected recovery time
Restore into a safe environment and verify that the application can use the result. Include object storage, uploaded files, configuration, and external records where they are necessary to reconstruct customer state.
11. Test the flows that can materially hurt someone
You do not need a huge test suite before launch. You need a small suite that protects the business invariants.
Prioritize tests that prove:
- One customer cannot access another customer’s data
- Only permitted roles can perform privileged actions
- A payment event grants access exactly once
- A failed multi-step operation does not leave corrupt partial state
- A database migration preserves real records
- The production build starts with the documented configuration
Unit tests help with contained rules. Integration and end-to-end tests are better for boundaries where generated systems often fail.
12. Name an engineering owner
Production systems need someone accountable for:
- Reviewing high-risk changes
- Responding to alerts and incidents
- Rotating keys and updating dependencies
- Approving migrations
- Maintaining the product rules and architecture
- Deciding when the AI tool is making progress and when it is adding patches
That owner can be an internal engineer, a fractional technical lead, or an external product engineering partner. The important part is that accountability does not belong to a chat session.
NIST’s Secure Software Development Framework is outcome-based: practices should align with business requirements, risk tolerance, and resources. A five-user internal tool and a healthcare product do not need identical processes, but both need deliberate ownership of their real risks.
A practical launch decision
Classify each checklist area as:
- Verified: Evidence shows the requirement holds.
- Known gap: The issue is understood, bounded, and accepted or scheduled.
- Unknown: Nobody has tested or traced it.
Unknowns around authorization, customer data, payments, secrets, destructive operations, or recovery are launch blockers. Unknowns around less critical polish may be reasonable post-launch work.
If you want an independent second set of eyes, begin with an AI app production-readiness review. If the review finds material gaps, a focused AI app hardening sprint can fix them in business-risk order.