An AI-built app is ready for production only when you have evidence that it can survive more than the happy path.
Before real users, payments or sensitive data arrive, check seven things:
- Access control: can every user reach only the data and actions they are allowed to use?
- Data integrity: does the system stay correct when requests fail, repeat or arrive in an unexpected order?
- Payments and entitlements: can a payment be verified, retried and fulfilled without creating duplicates?
- Secrets and generated code: have you reviewed what the AI produced, what dependencies it added and what credentials the browser can see?
- Deployment and rollback: can you reproduce a release and reverse a bad one without guessing?
- Testing and monitoring: have you tested the flows real users will break, and will you know when production fails?
- Ownership: do you control the code, data, accounts, domain and knowledge needed to maintain the product after launch?
I use AI-assisted development tools to move from product specification to working software faster. That can include Lovable for rapid product building and Codex for repository work, debugging, refactoring, testing and review. But speed changes the implementation process; it does not remove the production bar.
The useful question is not “Was this app built with AI?”
It is “What evidence do we have that this system will behave correctly when real life stops following the prompt?”
1. Check access control beyond the interface
A hidden button is not authorization.
If an admin link disappears for a normal user, that improves the interface. It does not prove that the normal user cannot call the underlying endpoint, open a protected route directly or read another customer’s records.
For every important resource, write down:
- Who can read it?
- Who can create it?
- Who can change it?
- Who can delete or archive it?
- Which actions require an owner, admin, manager or specific account relationship?
- What must a logged-out user never see?
Then test the denied cases, not only the successful ones.
If you use Supabase, this is where Row Level Security matters. Supabase’s current documentation recommends securing exposed tables with RLS, setting grants deliberately, writing policies per operation and testing both allowed and denied database operations. It explicitly notes that until those tests pass, you do not know whether the policies behave as intended. See the Supabase Row Level Security documentation.
A practical role test might look like this:
| Test | Expected result |
|---|---|
| Logged-out visitor requests a private record | Denied |
| User A requests User B’s record | Denied |
| Manager requests a record within their assigned scope | Allowed |
| Manager requests a record outside their scope | Denied |
| Admin performs an explicitly privileged action | Allowed and auditable |
This is one of the places where AI-generated apps can look complete while still being structurally unfinished. The UI may understand the role. The database may not.
2. Check what happens to data when something goes wrong
Production users double-click buttons. Networks time out. Background jobs retry. Two requests can arrive at almost the same time. A migration can fail halfway through. A user can close a tab after submitting a form but before seeing confirmation.
Your data model needs answers for those situations.
Before launch, identify the facts that must always remain true.
For a bookkeeping product, that might mean a payment cannot silently disappear from the ledger.
For a property product, one tenancy should not end up with two conflicting “current” states.
For a SaaS product, the same invitation should not create multiple memberships.
Those rules should not live only in a prompt, component or frontend condition. Where appropriate, enforce them with database constraints, transactions, uniqueness rules, explicit state transitions and server-side validation.
Then ask a recovery question:
If the database is damaged or a deployment writes bad data, what can we restore, and how far back?
Supabase’s production checklist recommends reviewing backups and recovery options before production, including Point-in-Time Recovery where a lower recovery-point objective is required. It also recommends testing schema changes through controlled deployment workflows rather than relying on manual production pushes. See the Supabase production checklist.
A backup you have never thought through is better than no backup, but it is not the same as a recovery plan.
3. Check payments, webhooks and duplicate fulfilment
A successful-looking checkout screen is not the source of truth for money.
If the product accepts payments, subscriptions, wallet funding, credits or paid entitlements, test the system around asynchronous events and retries.
The core questions are:
- How does the server verify a payment?
- What happens if the webhook arrives twice?
- What happens if the user refreshes the success page?
- What happens if the provider retries an event later?
- Can the same transaction grant value twice?
- What changes when a payment is refunded or reversed?
- Can an entitlement exist without a verified payment state?
Stripe’s webhook documentation requires verifying webhook signatures and recommends acknowledging events quickly before slower processing. See the Stripe webhooks documentation.
For Nigerian products, Paystack documents the same underlying operational reality: webhook endpoints should verify event origin, failed webhook deliveries are retried, and transaction verification should happen from your server. Paystack also warns developers delivering digital value to confirm that value has not already been delivered for a transaction, especially when webhooks are also used. See Paystack webhooks and Paystack payment verification.
The production rule is simple:
A retried event should not create a second business outcome.
If one verified payment buys one subscription, one booking or one credit allocation, your system should be able to receive the same signal again without granting it twice.
4. Check secrets, dependencies and the code AI generated
Generated code is still code you are shipping.
Review at least:
- API keys and service credentials.
- Environment variables exposed to the browser.
- Database service-role or administrator credentials.
- Third-party packages the AI introduced.
- Server endpoints that trust client-provided roles, prices or identifiers.
- Input validation and file uploads.
- CORS and rate-limiting rules where relevant.
- Debug logs containing sensitive information.
- Dependencies that are abandoned, unnecessary or unfamiliar.
Do not assume that because an AI tool configured an integration, it configured the trust boundary correctly.
AI can also help with this review. I use coding agents to inspect repositories, trace behavior, run tests, find inconsistencies and propose targeted changes. OpenAI’s current Codex product material emphasizes code review and testing, while Codex Security can build a repository-specific threat model, validate suspected vulnerabilities in an isolated environment and propose patches for human review. That last part matters: the documented workflow still puts proposed fixes through human review rather than silently treating an AI patch as approved production code. See Codex and Codex Security.
Use AI as another reviewer. Do not use it as the reason review is unnecessary.
5. Check that deployment is boring and reversible
A good production deployment should feel less exciting than the demo.
You should know:
- Which repository and branch are the source of truth.
- Which commit is currently live.
- Which environment variables production uses.
- How database migrations reach production.
- Which checks run before deployment.
- How to roll back the application.
- What happens if the application rolls back but a database migration does not.
- Who can deploy.
- Where the domain and DNS are controlled.
This is one reason I prefer connecting AI-assisted builds to normal version-control and deployment workflows once the product becomes serious.
Lovable’s current GitHub documentation says projects can be exported and two-way synced with GitHub for backup, collaboration and deployment. It also documents workflows such as reviewing changes, working locally, testing on branches and deploying outside Lovable. See Lovable’s GitHub integration documentation.
GitHub environments can add deployment branch restrictions, environment-specific secrets and protection rules. See GitHub’s deployment environment documentation.
The important part is not that every startup needs an enterprise CI/CD platform on day one.
It is that you should be able to answer “what changed?” and “how do we undo it?” before a production incident forces the question.
6. Check the user journeys that AI demos usually skip
Do not finish testing when the main button works.
Take the one journey that creates the product’s value and deliberately make it uncomfortable.
Try:
- A new account with no data.
- An expired session.
- A second user trying to access the first user’s records.
- Bad or incomplete form input.
- A duplicate click.
- Slow mobile data.
- A payment that fails.
- A webhook that repeats.
- An external API that is unavailable.
- A file that is too large or the wrong type.
- A small phone screen.
- Keyboard-only navigation on important flows.
- Going back, refreshing or reopening the browser halfway through a process.
Then make failures observable.
At minimum, decide where you will see:
- Application errors.
- Failed API requests.
- Authentication problems.
- Payment/webhook failures.
- Background job failures.
- Important administrative changes.
A production failure you can see and trace is easier to fix than one your customers have to screenshot for you.
Tests and monitoring also create a useful boundary for AI-assisted work: an agent can make a change quickly, but the acceptance criteria remain external to the agent. The change still has to pass the behavior you defined.
7. Check who owns the product after launch
This is the check founders often leave until the app is already important.
Ask who controls:
- The GitHub repository.
- The database project.
- The hosting account.
- The payment gateway.
- The email provider.
- The domain registrar and DNS.
- Analytics and monitoring.
- Production secrets.
- Backups.
- Billing.
- Documentation.
Then ask the harder question:
If the person or tool that built this disappears tomorrow, can someone competent understand and operate the product?
Ownership is not only legal ownership of source code. It is operational control.
Lovable’s GitHub sync is useful here because it supports keeping the code in a conventional repository and working on it outside the builder. That does not automatically make the architecture good, but it reduces the risk that the product exists only inside one interface or one person’s account.
Document at least:
- How to run the app.
- How to deploy it.
- Required environment variables.
- Major external services.
- Database migration process.
- Critical scheduled jobs or webhooks.
- The product’s important business rules.
- Known risks or temporary shortcuts.
The goal is not documentation for its own sake. It is making the next fix possible.
A simple go/no-go checklist
Before launch, I would want evidence for each of these:
| Area | Evidence I would want before “go” |
|---|---|
| Access | Role and permission tests prove both allowed and denied actions |
| Data | Critical invariants, migrations and recovery path are understood |
| Payments | Server verification, signature checks and duplicate-event handling are tested |
| Security | Secrets, dependencies, inputs and privileged endpoints have been reviewed |
| Deployment | Source of truth, environment separation, deploy checks and rollback are known |
| Reliability | Critical journeys have been tested under failure and production errors are observable |
| Ownership | Code, data, domain, accounts and operational knowledge are under deliberate control |
You do not need a giant engineering organisation to pass these checks.
You do need someone willing to make the release decision based on evidence instead of the excitement of seeing the first version work.
When I would bring in deeper engineering review
The production bar should rise with consequence.
I would be much more cautious when an AI-built product handles:
- Private customer or employee records.
- Money, balances, invoices, receipts or entitlements.
- Multi-tenant data where one customer must never see another customer’s records.
- Healthcare, identity, legal or other sensitive information.
- Complex role and permission systems.
- Important business operations that cannot tolerate silent data loss.
- Automated actions with real financial or operational consequences.
- A codebase nobody on the team can explain.
In those cases, “the AI says it is fixed” is not enough acceptance evidence.
The way I use AI-assisted development
I do not see AI-assisted development as a shortcut around engineering. I see it as a way to compress parts of execution.
I can use Lovable to get a product flow working quickly, then use GitHub and Codex to inspect, refactor, test, troubleshoot and harden the repository. But the important questions remain human questions:
- What should the product actually do?
- Which business rules must never break?
- Who should have access to what?
- What is the source of truth?
- What failure is acceptable?
- What must be tested before release?
- When is the product genuinely good enough to ship?
That is the difference between generating an app and taking responsibility for a product.
If you are still choosing a tool for the first MVP, read my Lovable vs Bubble vs Webflow vs WordPress guide. If the bigger question is budget, see my MVP development cost guide.
If you already have an AI-built MVP and need to decide whether to ship it, harden it, refactor it or rebuild parts of it, see my MVP development service or contact me.
