> ## Content Index > Fetch the complete content index at: https://aienabledpm.com/llms.txt > Use this file to discover other available public pages before exploring further. # Your Vibe-Coded App Works. Is It Ready for Customers? - URL: https://aienabledpm.com/vibe-coded-app-ready-for-customers/ - Published: 2026-10-22T16:30:07.000Z - Updated: 2026-10-22T18:10:59.000Z - Description: A field guide for deciding when a vibe-coded app can move from internal testing to real customers. - Author: Aviral Verma - Tags: AI, Product Management Suppose a small product team has a vibe-coded prototype: a document-submission app built with AI coding tools. The app collects contracts and security forms from new business customers. In the team's test environment, employees can complete the planned journey with sample data. One employee sends an invitation. Another acts as the customer contact, creates an account and uploads sample documents. The first employee requests a correction and approves the revised submission. No customer has used the app yet. Three customer companies are now ready to join a limited beta. That successful run leaves several release questions unanswered. Could someone open another company's document by changing its ID? Can the team restore a backup? Could an email timeout send the same invitation twice? Which version of the code is running? None of those checks has been completed. AI coding tools and managed platforms can shorten the path to a working vibe-coded app. A passing test, security scan or deployment tells the team something useful about one part of the system. It does not cover the full customer journey or the failures that could affect it. The missing checks leave the release decision unresolved. Before inviting customers, the team needs to run them, fix any defects they expose and rerun the affected checks. This is a hypothetical worked example. Its checks are specific to the document app. For another product, start with its promised customer journey and identify the failures that could interrupt or harm it. ## This week in AI News Three developments this week change how product teams buy models, delegate work and choose where to run it: - [OpenAI Models Are Coming to Google Cloud](https://aienabledpm.com/ai-news/openai-models-are-coming-to-google-cloud/). Google Cloud customers will gain a new way to buy OpenAI models, but the private preview leaves pricing, availability and some data controls to verify. - [Claude Duet Works in the Background, Then Asks](https://aienabledpm.com/ai-news/claude-duet-works-in-the-background-then-asks/). Anthropic’s proactive-agent preview prepares work in the background and waits for approval before consequential actions; missed events and unnecessary interruptions still need testing. - [Meta Opens Muse Spark. Hosting It Takes More.](https://aienabledpm.com/ai-news/meta-opens-muse-spark-hosting-it-takes-more/). Meta’s downloadable model adds deployment choice, alongside substantial hosting requirements and commercial-license conditions. ## What changes when customers get access Our [hosting guide](https://aienabledpm.com/deploying-the-stack-how-to-host-your-ai-prototype/) covered how to put a product online. Here, the decision is whether to let customers entrust confidential files to it. The proposed beta needs to keep each company's data separate, preserve review decisions and give customers a way to get help when something goes wrong. These responsibilities begin with the first customer, even if traffic stays low. An anonymous calculator might serve 10,000 people without storing anything important. Three companies uploading confidential contracts need different safeguards. Scale still affects technical choices, as our [systems-thinking guide](https://aienabledpm.com/beyond-prototyping-why-systems-thinking/) explains, but user count alone cannot tell this team whether its app is ready. ### The proposed beta > People at three named customer companies can accept invitations, create accounts and submit confidential documents. The operations team can request corrections and approve completed submissions. That is the journey the team needs to verify. Testing stays in a separate environment with sample data; customers receive access only to the beta environment after the release checks pass. ## Keep a record of the release decision A short release record gives the team a place to collect the evidence and decide whether to proceed. It should answer five questions: 1. Who gets access, and what can they do? 2. What would block release or pause the beta, and who makes that call? 3. Which safeguards come from the app, the team or a provider? 4. What evidence shows those safeguards work? 5. What remains unchecked, and who will complete it? For each required check, record the owner, evidence, date and result. Use **PASS**, **FAIL** or **NOT CHECKED**. A failed check needs a fix and another test; an unchecked one still needs evidence. Neither permits release. These results cannot be averaged into an overall score. Good monitoring cannot make up for broken access rules, and a successful restore cannot prevent duplicate emails. A smaller release is an option only if it still solves the promised customer problem. Removing uploads, corrections and approvals would leave this document app unable to do its job. ## Check each way the release can fail For this document app, six questions expose the gaps between a successful internal run and a customer-ready beta. They are a starting point for the worked example, not an exhaustive test plan for every product. ### Can every user access only the right data and actions? The login service can confirm who a user is. It may also return the user's company or role. That does not prove that every action in the app checks whether the user belongs to the right company. OWASP calls this broken object-level authorization. It happens when an API accepts a record ID without checking whether the caller is allowed to use that record ([OWASP API Security](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/?ref=aienabledpm.com)). Try the actions that should fail. Can a user accept someone else's invitation, change a company ID to open another company's records or continue using an old session after access is removed? Before release, run the same kind of tests on uploading, listing, downloading, replacing, approving and deleting files. Check direct file links too. File-storage settings need their own review. A file may be reachable through a storage link even when the app itself blocks access. OWASP recommends checking permission on every request and testing those checks directly ([OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization%5FCheat%5FSheet.html?ref=aienabledpm.com)). ### What happens when work is repeated or two people act at once? Repeated and simultaneous actions should not corrupt the app's records. Accepting the same invitation twice must not create two memberships, and retrying an email must not send a duplicate invitation. If one employee approves a submission while another is editing it, the older edit must not overwrite the approval. Enforce a rule such as one active membership with a database constraint where possible, and test that constraint directly. PostgreSQL supports unique indexes for this purpose, although rules that depend on wider application state may still need application code ([PostgreSQL constraints](https://www.postgresql.org/docs/18/ddl-constraints.html?ref=aienabledpm.com)). After a timeout, the app may not know whether the provider sent the invitation. Assign each invitation request a stable reference and save its state before calling the provider. Automatic retries are safe only if the provider can recognise a repeated request and avoid sending it again. Otherwise, compare the provider's record with the app's record and send the case to an operator if the result remains unclear. AWS describes the same problem for requests with side effects ([AWS Builders' Library](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?ref=aienabledpm.com)). The team can test its existing email flow before deciding whether to replace it. What matters for this beta is a recorded result showing what happens after a timeout and whether a retry creates a duplicate. ### What happens when a file is too large or another service slows down? Even with three companies, one oversized file can occupy upload capacity, a stalled email provider can hold jobs open and rapid retries can worsen an outage. AWS recommends setting time limits, retrying only suitable failures, waiting longer between attempts and stopping after a fixed number of tries. Otherwise, retries can make an outage worse ([AWS Builders' Library](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?ref=aienabledpm.com)). Set limits for file size, request time and database connections. Then test the expected beta traffic while making the email provider respond slowly. Watch request times, waiting jobs and retry attempts. The queue and retry count must stay within the limits the team sets for the beta. This beta needs enough capacity to contain those failures. It does not need infrastructure designed for mass traffic. ### How will the team notice a failure and recover? A healthy server response does not show that invitations, uploads and reviews are working. Monitor those customer actions as well as the server itself. Test the upload journey from the outside: start an upload, confirm that the app accepts the file, verify that it is attached to the right company and check that an employee can open it. Google SRE recommends alerts based on user impact and explains why an outside test catches failures that an internal system check can miss ([Monitoring Distributed Systems](https://sre.google/sre-book/monitoring-distributed-systems/?ref=aienabledpm.com)). Alert the team when invitation delivery, account activation or an upload fails, then verify that the alert reaches the assigned responder. The app should also record failed correction requests and approvals so the operations team can find stuck submissions. A recurring test upload can supplement monitoring. Checks in the test environment do not replace monitoring the customer-facing beta. NIST recommends practising recovery rather than assuming a backup will work ([NIST SP 800-34 Rev. 1](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final?ref=aienabledpm.com)). Restore one backup in the test environment. Confirm that the records and uploaded files return, each file is linked to the right company, only authorised users can open it and the app can still read it. Assign a response lead and give that person a short recovery checklist. It should cover restoring service, rolling back changes that can safely be rolled back and telling affected customers what happened. If uploads fail, pause document collection unless the team has already approved a fallback with equivalent access, retention and deletion controls. ### Can the team identify the deployed build and recover from a bad release? Record the source version and build deployed to the beta environment. After deployment, send an invitation, create an account, upload a file, request a correction and approve the completed submission. The team should also be able to pause new invitations or withdraw beta access if the release causes a problem. Rolling back code will not undo every database or outside-service change. Some database changes need a new fix instead. Write down what can be rolled back and what needs another change. ### Who owns each promise made to customers? Before release, assign an owner to each customer-facing commitment. For the document app, one person must approve the retention period for contracts and security forms. The team must document or configure deletion, test it with a sample submission and give the policy to beta customers. Someone must also handle failed invitations through a controlled resend or replacement flow that checks the recipient, expires the link and records the action. AI tools may help write the code even when no AI model runs inside the product. In that case, tests for attacks on a model or the quality of its answers do not apply. The team still needs to review AI-written code, check the software libraries it uses and run the same tests it would require for any other code. ## What would let this beta proceed? In the opening scenario, the team has not checked company separation, email retries, restoration or the deployed build. The beta should wait for those results. A successful internal run does not fill the gaps. One way to review the results is to group them by what they protect. For this beta, the release discussion would cover four areas. Each underlying check still needs its own owner and result. ### Access stays within the three companies Accepting an invitation twice must create only one membership. Users must not be able to read or change another company's records or files, and removing access must block existing sessions and direct file links. Invitation controls must restrict the beta to the three named companies. Adding more companies requires another release decision and a review of support capacity. ### Invitations, uploads and reviews survive the failure tests A simulated email timeout must not create a duplicate invitation. If the provider cannot reject repeated requests, the app must stop automatic retries and route uncertain cases to an operator. A slow provider must not make the queue or retry count grow without limit. An older edit must not erase a newer approval. Oversized or disallowed files must be rejected without tying up the service, and an allowed file must still upload afterwards. ### The team can detect failures and recover The named responder must receive the agreed alerts for failed invitations, account activations and uploads. The operations team must be able to find failed correction requests and approvals. A restore rehearsal must bring back the database and uploaded files together, with the correct company links and access rules intact. The team also needs a tested rollback procedure for changes that support rollback, plus a written plan for changes that would need a new fix. ### The deployed beta has an owner The release owner must identify the exact deployed build and complete the full journey on it: invitation, account creation, upload, correction and approval. The retention period and deletion method must be approved and shared with beta customers. The team must also test deletion on a sample submission. A named person must own incident communication and support, and the team must test the contact path customers will use. Once every required check passes, the team can open the intended beta. It should still monitor the live customer journey: passing the release checks does not mean future failures are impossible. ## Use managed services without leaving gaps Managed login, storage, databases and email can spare this team work it does not need to take on. The choice is reasonable when the service's configuration and written commitments meet the beta's requirements and the team has tested the resulting behaviour. The boundary varies by service, as [AWS's shared-responsibility guidance](https://aws.amazon.com/compliance/shared-responsibility-model/?ref=aienabledpm.com) explains. A hosted login service can manage passwords while the app enforces company boundaries. Automatic backups still need a restore test. A deployment service's build history helps only if the team can identify which build reached the beta. The release record should make those boundaries visible: what the provider covers, what the team configured and what the tests showed. Adding infrastructure would not resolve an untested access rule or an unrehearsed restore. For another vibe-coded product, start with the customer journey you intend to release. Identify what could go wrong, decide which failures must block customer access and collect evidence that the safeguards work. The document app's tests will not fit every product, but the release decision still needs answers that someone has checked.