There is something wonderful about describing a problem and watching an app take shape. A process that lived in someone's head becomes a screen people can use. An awkward spreadsheet becomes a shared workflow. Someone who understands the work can finally build the tool they have been imagining.
Being able to whisper an app into existence is worth celebrating.
Then comes an equally useful question: what will it take to bring that app into a production network, where real people use real information and depend on the result?
Before a vibe-coded app enters production, map its data flows, verify authentication and authorization, limit its network and system access, review its code and configuration, test failure scenarios, and establish backups, monitoring, and an owner. The depth of that work should match what the app can access and how much disruption a failure could cause.
Our earlier article, Vibe-Coded Apps at Work: What to Check Before You Rely on One, introduced the main questions. This follow-up walks through the practical work behind those checks.
Estimated reading time: 8–10 minutes.
What makes a vibe-coded app ready for production?
Vibe coding uses natural-language instructions and AI coding tools to create and revise software. Whatever tool produced the code, production readiness means having evidence that the app can handle its intended work, protect its information, and be maintained and recovered.
For this walkthrough, imagine a small company has built an internal request app. Employees submit requests, attach documents, and check progress. Managers approve requests, and the app sends email updates. The prototype works beautifully.
That simple description already involves identities, permissions, file storage, a database, and an email service. Bringing it into production means understanding and managing those connections. A cloud-hosted app connected to company accounts and data deserves the same attention as one running inside the office.
1. Define the job and name an owner
Write a short description of what the app does, who will use it, and what happens if it fails. Establish its boundaries: our request app records approvals, for example, but does not automatically move money or change payroll.
Name a business owner who decides whether the workflow is correct and a technical owner who can maintain it. In a small organization, one person may fill both roles, with outside help where needed.
Make sure the company controls the repository, hosting, domain, and service accounts. If the builder goes on vacation, someone else should be able to find the source, stop the app, and get help. Start documenting that handoff while the application is still small.
2. Create a data map before connecting business systems
A data map explains what information enters the app, where it travels, where it is stored, and who can access it. Include destinations that are easy to overlook: logs, backups, analytics, email, file storage, and any external AI services.
For the request app, trace a real submission:
- An employee signs in and enters a request in the browser.
- The application checks permissions and saves the request in its database.
- An attachment goes into private file storage.
- The email service receives the recipient address and notification content.
- Logs record the operation, and backups retain copies of stored information.
For each destination, record the data involved, the account or service controlling access, how long it is retained, and how it is deleted. Pay attention to places where data moves between systems with different access rules. OWASP's threat modeling guidance uses data flows and these trust boundaries to help identify where protection is needed.
The map often reveals simple improvements. An email may only need a notification and a protected link, rather than the full request and attachment. A test environment may only need invented sample records.
An app built with AI does not necessarily use AI when it runs. If it does send information to a model, add that provider and its data handling settings to the map.
3. Verify authentication: who is signing in?
Authentication establishes a user's identity. For a company application, using the organization's existing identity provider and single sign-on usually makes account management easier. Use established authentication libraries and services, with multifactor authentication appropriate to the app, especially for privileged users.
Check the whole account lifecycle: invitation, sign-in, recovery, session expiration, and removal. Confirm what happens to active sessions when an employee leaves or an account is disabled. A successful login demonstration does not answer those questions.
The application must validate identity on the server or trusted backend. A browser flag saying someone is logged in cannot establish identity by itself. OWASP's authentication guidance covers safeguards including secure recovery, multifactor authentication, and protection against repeated login attempts.
4. Verify authorization: what can each user do?
Authorization determines what an identified user may see or change. Our request app needs specific rules: employees can see their own requests; managers can approve requests assigned to their team; only designated administrators can change access settings.
Enforce those rules on every relevant backend request, including file downloads, exports, and administrative actions. Hiding an Approve button is useful interface design, but someone may still call the underlying endpoint directly.
Test with two ordinary accounts and an administrator. Can one employee retrieve another employee's attachment by changing an identifier in a URL? Can a manager approve a request outside their team? Does a revoked permission take effect?
Give users and service accounts only the access they need, and deny access when no rule explicitly allows it. These principles are central to OWASP's authorization guidance.
5. Give the app a defined place on the network
Document which connections the application needs: users reaching its web interface, the backend reaching its database, and the notification service sending email. Allow those specific paths and restrict unnecessary access.
Avoid putting a prototype on a broadly trusted server or giving it unrestricted access to internal systems just to make an integration work. Keep databases and management interfaces away from public access unless there is a deliberate, protected design for exposing them. Use encrypted connections and restrict administrative access.
For our request app, a narrowly scoped integration account might read a staff directory. It should not inherit the builder's ability to administer the entire company environment.
Use separate development, test, and production environments, with separate credentials and data. Bring whoever manages the network or cloud environment into this decision before launch; they need to understand the app's connections and how to disconnect it if necessary.
6. Review the code, dependencies, and security settings
Arrange a review by someone able to explain the application and its security-sensitive behavior. AI can help examine code, but its own reassurance is not evidence that the application is secure. OWASP's secure coding with AI guidance emphasizes reviewing generated changes and independently validating important security behavior.
The review should cover server-side input validation, safe database queries, protection against script injection, and appropriate safeguards for sessions and browser requests. For file uploads, check allowed types, size limits, storage permissions, and safe handling of potentially hostile files. Remove debug routes, demo accounts, and permissive development settings.
Inventory the packages the app uses, check their provenance and known vulnerabilities, and identify who will keep them updated. Automated scans help locate problems; someone still needs to assess and fix the findings.
Keep API keys and passwords out of browser code, source files, prompts, and logs. Use the hosting platform's protected secret storage with limited access. If a secret has been exposed, revoke or rotate it; deleting the visible copy does not invalidate it. OWASP's secrets management guidance explains the lifecycle behind storing, accessing, and rotating credentials.
7. Test the workflow when things go wrong
Start with the business outcome: can a request be submitted, reviewed, approved, and retrieved correctly? Then test realistic interruptions.
What happens when someone double-clicks Submit? When two managers edit the same record? When an upload fails halfway through? When the email provider is unavailable after the database has already saved the request?
The application should give users a clear result without silently losing work or creating duplicate actions. Test expected traffic and file sizes, too. A page that feels fast with five sample records may behave differently with months of activity.
Keep repeatable tests for important workflows and access restrictions. Use a staging environment that resembles production, with safe sample data. Have someone other than the builder try the app: they will often use it in ways the original prompts never considered.
8. Prove that you can recover and roll back
Decide how much data the business could afford to lose and how long it could tolerate an outage. Use those answers to set backup frequency and recovery expectations.
Back up the database and uploaded files, and document how to recreate the application's configuration. Test a restore into a separate environment and verify that the recovered records and attachments actually work together. A backup job reporting success is only part of the evidence.
Keep a known working release and a documented rollback procedure. Database changes deserve special attention: reverting application code may not undo a changed table or restore deleted data. Before releasing an update, understand how you would recover if that update changes stored information incorrectly.
9. Make operation and launch part of the build
Capture enough information to investigate failures and important actions: who changed an approval, when an integration failed, and whether a scheduled job completed. Protect the logs themselves and avoid recording passwords, tokens, or unnecessary document contents. OWASP's logging guidance covers both useful security events and information that should be excluded.
Assign someone to receive and act on alerts. Watch availability, errors, storage, and service usage. Set spending alerts or limits where available so an unexpected loop or traffic spike does not quietly become a large bill.
Start with a small group and a limited workflow. Keep a fallback process during the pilot, collect feedback, and expand once the app behaves reliably. Record known limitations and decide who can approve future releases. Production readiness continues as the software, its dependencies, and the business change.
A practical checklist before the first production release
For a useful launch review, bring evidence for each of these items:
- Purpose and ownership: a defined workflow, named owners, and company-controlled accounts.
- Data map: documented storage, integrations, external destinations, retention, and deletion.
- Identity and permissions: tested sign-in, account removal, and access rules for records and actions.
- Network placement: approved connections, restricted management access, and separate environments.
- Security review: reviewed code and dependencies, protected secrets, and resolved launch-blocking findings.
- Workflow testing: verified normal operation, misuse cases, and likely failures.
- Recovery: a demonstrated restore and a workable release rollback plan.
- Operations: actionable monitoring, a support path, and a limited initial rollout.
Scale the review to the app. A lunch-order calculator and an application that updates financial records need different levels of scrutiny. Any unresolved issue needs a named owner and a clear decision about whether launch can proceed.
Can a vibe-coded app become dependable business software?
Yes. AI-assisted development can make useful software accessible to more people, especially the people closest to a frustrating process. The path to production is to give that software the engineering attention, access boundaries, and operating support its job requires.
You do not have to lose the excitement of creating something quickly. Keep the momentum, then build the confidence that other people can depend on what you made.
If you have a working prototype and need help with that next step, Astrenic's AI-Built App Readiness service can help review the application and plan its path to production. Tell us what you built.