Before deciding whether a vibe-coded MVP is ready for real customers, verify who owns it, how access is controlled, and how you will recover from a failure. A working demo is a useful beginning; readiness depends on the job it will do and the obligations you accept.
AI-assisted development can make experimentation accessible to more founders. It does not transfer responsibility to the tool that generated the code. If the application handles another person's information or changes something they depend on, someone still needs to understand what has been deployed.
This checklist is a starting point for product readiness. It is not a security audit or a replacement for qualified review where the consequences warrant it.
First, make sure you own the operating surface
List the repository, hosting account, domain, database, email service, authentication provider, payment provider if used, and any external model service. For each, record the authorized owner and how access is recovered.
Do not leave a production dependency inside a contractor's personal account simply because it made the prototype easier. Check that important credentials are stored appropriately and that secrets are not exposed in browser-delivered code, public repositories, or ordinary logs.
GitHub's responsible-use guidance describes limitations of generated suggestions and the need to evaluate them in context. Read the official documentation. The practical implication is to review the complete application behavior, including the parts that were easy to generate but difficult to understand.
Verify access with two different users
The presence of a login screen does not prove that records are isolated. Create appropriate test accounts and inspect the important boundaries. Can one account read another's records by changing a URL? Can an ordinary user perform an administrator action? What happens after access is revoked?
Test through the actual application and its supported interfaces. A button being hidden is not the same as a protected operation. Record what was checked, in which environment, and what remains unknown.
OWASP ASVS provides a structured set of web application security requirements. It can guide a qualified review and help you ask concrete questions. See the standard. Do not claim that a short checklist establishes full compliance with it.
If you cannot evaluate an important boundary, reduce the pilot's exposure and obtain help. Learning on disposable test data is different from learning through a customer's confidential files.
Walk the whole customer job
Pick one complete path: sign up, perform the main action, inspect the saved result, return later, and recover from a mistake. Test a failure, not only the successful route.
What happens when the network drops during submission? Does clicking twice create duplicates? Can the user tell whether a job finished? Does an empty state mean there are no records, or that retrieval failed? A small product can be honest about these distinctions without building an elaborate control center.
Make forms understandable and accessible. Use descriptive labels, visible validation, keyboard navigation, and error text that explains what the user can do next. A launch that requires the founder to narrate every screen is still carrying hidden usability debt.
A hypothetical example: a founder directory
Imagine an MVP where founders create a profile and request introductions. The happy path looks good, but a failed request is shown as success because the interface assumes that clicking the button means the server saved it.
Before launch, the founder verifies the actual saved result, adds an understandable failure message, and prevents a retry from creating duplicate introduction requests. They also check whether profile contact details are public or visible only to authorized participants.
This hypothetical example is deliberately ordinary. Production readiness often depends on small behavioral details that are easy to overlook when the generated page looks complete.
Plan recovery before making promises
Know which version is live, how to return to a known working version, and what happens to data if you do. Code rollback and data recovery are separate questions.
Keep a release note that records the change and any operational steps. Make a small, realistic recovery exercise part of readiness, using safe test conditions. If an update changes stored information, understand whether the previous application version can still interpret it.
Also write the support message you would send if the main workflow stopped. You should be able to explain the affected behavior and the available fallback without first reverse-engineering your own product.
Where caution becomes unnecessary delay
Not every experiment needs the same safeguards. A disposable calculator with no accounts, private inputs, or external actions carries a different responsibility from a customer operations tool.
Define a bounded launch: a small invited group, explicit limitations, appropriate data, and an owner for support. Avoid calling an unverified application production ready because the alternative seems to be never launching. There is a useful middle ground between an unattended public release and endless private polishing.
Your launch decision sheet
Before inviting the first group, write yes, no, or unknown beside each item:
- We control the essential accounts and recovery access.
- Sensitive credentials are not exposed to users.
- Access boundaries have been checked with separate accounts.
- The main workflow succeeds and fails understandably.
- Duplicate actions and uncertain results are handled deliberately.
- We can recover the important information and application version.
- The pilot scope and limitations are clear to participants.
- Someone owns support and the decision to stop the pilot.
Treat unknown as work to resolve, not a synonym for yes. Launch within the responsibility you can actually carry.