# The Vibe Code Risk Check: 8 Signs Your AI-Built System May Not Be Ready for What's Next A 5-minute self-check for founders who shipped fast and now need to know what's underneath. Canonical HTML: https://viberealitycheck.com/learn/8-signs Author: George Rios Publisher: George Rios Consulting LLC Updated: 2026-09-15 Content version: 1.0 / quiz v1 / scoring v1 Vibe Reality Check is a free eight-question self-assessment for founders with AI-built software. It covers credentials, environment separation, access controls, personal data, outage detection, handoffs, backups, and load readiness. Your answers produce a prioritized checklist of reported gaps and areas to verify. It does not scan your application or certify that it is secure, compliant, or ready to scale. You shipped in weeks what used to take a team months. But shipping is only the beginning of depending on a system. Before a customer asks hard questions, traffic increases, or something breaks, it helps to know where the weak spots and unanswered questions are. Start with these eight areas. ## Nobody can tell you where your secrets live. API keys and credentials may be spread across code, hosting settings, local files, and old messages. If no one knows what exists or who can use it, controlling access becomes guesswork. **Ask yourself:** Can you identify every production API key and credential, confirm it is stored outside source code, and explain who can access it? **Why it matters:** Untracked credentials make it difficult to control access or respond when a key is exposed. **Next step:** Inventory production credentials, their storage locations, owners, and permissions. Have a qualified maintainer assess any suspected exposure and rotate affected credentials with a plan for dependent services. **Evidence to look for:** A credential inventory and documented storage, access, and rotation procedures. Never paste secret values into this site. ## Testing and production share more than they should. A separate test URL can still point at the live database. Understand where a test or accidental deploy could touch real customers. **Ask yourself:** Are development and testing isolated from production data and production credentials? **Why it matters:** A test or mistaken deployment may affect real customer records or live services. **Next step:** Map which databases, keys, and services each environment uses. Establish isolated test resources and a documented production deployment process. **Evidence to look for:** An environment map showing separate data and credentials and how changes reach production. ## Access controls have never been deliberately tested. A login screen and hidden menu items do not establish that each user can access only the right records and actions. Those boundaries need testing. **Ask yourself:** Has someone deliberately tested that users cannot access another customer's data or actions outside their permissions? **Why it matters:** An application can appear to work while allowing unintended access to customer data or actions. **Next step:** Ask a qualified developer to test role and customer boundaries using controlled test accounts and synthetic data, and verify that the server enforces permissions. **Evidence to look for:** Documented authorization tests across roles and customer boundaries. ## Personal data has no clear owner or lifecycle. Your system may hold names, emails, or more sensitive records without a clear account of their purpose, retention, and handling. Start by documenting what actually exists. **Ask yourself:** Can you explain what personal data you hold, why you hold it, how long you keep it, and which privacy requirements your team has assessed? **Why it matters:** Unclear data practices make customer questions, deletion requests, and privacy reviews harder to handle. **Next step:** Create a data inventory covering purpose, location, access, retention, deletion, and external providers. Have the appropriate advisor assess the requirements relevant to your business. **Evidence to look for:** A data inventory, retention rules, a request-handling process, and a record of the requirements assessed. ## Customers are your outage alert. If a broken workflow remains invisible until someone complains, you lose both response time and useful evidence. Decide what should trigger an alert and who owns the response. **Ask yourself:** Would the right person receive an alert about a meaningful outage and have enough logs to investigate it? **Why it matters:** Failures may continue unnoticed, and recovery may take longer without useful evidence. **Next step:** Define important failure signals, route alerts to a named owner, and exercise one controlled failure to confirm the alert and investigation path. **Evidence to look for:** A tested alert, useful redacted logs, an owner, and a short incident runbook. ## One person is the operating manual. When setup, architecture, and deployment exist only in the builder's head, routine changes become a dependency on that person's availability. A practical handoff rehearsal reveals what documentation is missing. **Ask yourself:** Could another qualified developer use your documentation to run the system and safely ship a fix if the main builder were unavailable? **Why it matters:** Routine changes and incident response may depend on one person's availability. **Next step:** Create a concise system map and operating guide, then ask another developer to rehearse a setup and deployment using the documentation. **Evidence to look for:** A current README, architecture diagram, access process, and successful handoff rehearsal. ## Your backup strategy ends at “it's in the cloud.” A backup setting is reassuring, but recovery is a process. Restore into an isolated environment and verify that the data and critical workflows are usable. **Ask yourself:** Have you successfully restored a recent backup into an isolated environment and checked that the recovered data is usable? **Why it matters:** You may discover recovery limitations only after data is lost or damaged. **Next step:** Inventory critical data stores, agree on acceptable data loss and recovery time, and rehearse a restore away from production. **Evidence to look for:** A dated restore record, validation checks, measured recovery time, and a recovery owner. ## Growth is an untested assumption. An application that feels fast today may behave differently with more concurrent work, more records, or an external service limit. Use a realistic workload to learn what constrains it first. **Ask yourself:** Have you tested a realistic workload at three times your current peak demand and identified the first bottleneck? **Why it matters:** More users may expose slow queries, exhausted connections, service limits, or unexpected spending. **Next step:** Define a representative workload and run an authorized test in an appropriate isolated environment. Measure errors, response times, resource limits, and cost; document the limiting component. **Evidence to look for:** A workload definition, test results, known bottlenecks, and a capacity improvement plan. The useful next step is understanding which gaps need attention first. Take the free check for a personalized starting point, then use the checklist with your team. If you want help mapping the system and prioritizing the work, a 30-day architecture discovery with George Rios is a place to start. Yes = 0; No and Not sure = 1. Unknowns remain distinct from reported gaps. [How the scoring works](https://viberealitycheck.com/assessment-notes). [Take the free risk check](https://viberealitycheck.com/check) · [Talk with George](https://cal.com/georgerios/30min) ## Assessment limitations These results reflect your answers. They do not establish that your system is secure, compliant, or ready for a particular load. Sponsored by George Rios Consulting LLC [georgerios.com](https://georgerios.com) · [Privacy](https://viberealitycheck.com/privacy) · [How this check works](https://viberealitycheck.com/assessment-notes)