How to Check an AI-Built Project Before Launch

Check the product, not the fact that AI wrote the code

Before launch, a client often receives a URL, a few screenshots, and “everything is ready.” That is not enough for a project built with AI — but reading every line is not the answer either. You need evidence that the product follows the agreed workflow, handles failures, and remains maintainable after handover.

This checklist is written for a founder or product manager without deep engineering experience. It does not replace an independent security assessment for a critical service, but it helps separate a polished demo from launch readiness.

1. Define what “done” means

Start with a short table: user journey, expected result, input data, failure behavior, and acceptance criterion. “Build a dashboard” is too broad. “A client can sign in, see only their orders, open an order, and send a message” can be tested.

Also write down what is out of scope for the first version. Otherwise unfinished ideas start to look like bugs, and the delivery never ends.

2. Run the project in a clean environment

Ask for instructions that let a new person install dependencies, configure variables, and start the project without hidden steps known only to the original author. Check both local startup and a production-like build.

For a web application, use a separate Preview deployment. It gives you a live environment similar to Production before the real domain is switched. Vercel scopes Preview and Production separately, including their environment variables, so check both.

3. Test every role

Create test accounts for each role. Check sign-in, sign-out, account recovery, status changes, and direct URL access. Then try to open and change another user’s data.

The important question is not “does the app have authentication?” It is “does the server enforce permission for every action?” Payments, personal data, and high-impact workflows need stronger review, and sometimes an independent security specialist.

4. Check data and recovery

Ask where the database lives, how migrations are applied, who owns the account, and when the last backup was made. Ask to see a restore on a test copy instead of accepting “backups are configured” as proof.

Test risky actions: resubmitting a form, double-clicking a payment, deleting a record, cancelling an operation, and reopening a page after a failure. The data should stay consistent and the user should understand what happened.

5. Check secrets and external services

Secrets should not live in the repository, screenshots, client-side JavaScript, or uncontrolled chat messages. Make an inventory of external services: database, email, payments, file storage, analytics, Telegram, CRM, or other APIs.

For each service, record the account owner, environment, limits, key rotation process, and failure procedure. For critical integrations, test a timeout, an invalid key, and a quota limit — not just the successful response.

6. Run automated checks

The minimum depends on the project, but it often includes type checking, linting, a production build, and tests for the main user journeys. One green test does not prove readiness; no tests do not prove failure. What matters is knowing which risks were checked and which were consciously accepted.

Review the change history. A GitHub pull request brings together the description, checks, changed files, and review discussion. That is easier to verify than an archive of files with no explanation of what changed.

7. Use a separate security checklist

Do not stop at a password check or an antivirus scan. Review access control, input handling, file uploads, error messages, secrets, logs, and dependencies. OWASP ASVS provides a basis for testing web application security controls; a small MVP can use the relevant sections without claiming to satisfy the whole standard.

Payments, medical or financial data, personal information, and always-on services require a higher level of review. “The page opens” is not an adequate release criterion for those systems.

8. Simulate a failure and a rollback

Trigger one safe failure in a test environment: disable a test integration, use an invalid key, or stop a background job. Check what the user sees, what is logged, and who is notified.

Then ask the team to demonstrate how to restore the previous application version and recover data. If the answer is “we will figure it out when something happens,” the project is not ready for launch.

What evidence to request

Area	What should remain after the check
Journeys	A list of tested actions and acceptance criteria
Build	Startup commands, build result, and runtime versions
Data	Schema, migration, backup, and restore notes
Access	Accounts, roles, and owners without sending secrets in chat
Failures	Log location, alerts, and rollback procedure
Changes	Repository, commit history, and known technical debt

When can you launch?

Agree to launch when the main journeys work with test data, access rules are clear, secrets are outside the code, the build is repeatable, a backup has been restored successfully, and the rollback is written down. Classify remaining issues as blockers or work for the next stage.

For a new project, put these requirements into the brief from the start. You can describe the goal and acceptance criteria on VibeMarket’s project request page. If the project already exists, a separate audit stage helps you compare proposals for project support.

The short answer

A pre-launch review is not about blaming AI. It is about evidence: the product works in the right environment, access is restricted, data can be recovered, failures are visible, and another developer can continue the work. Without that evidence, readiness exists only as a promise.