How to Take a Vibe-Coded App to Production: Security, Testing, and Go-Live Checklist

A vibe-coded app can look finished long before it is ready for production. The screens load, the main workflow completes, and a few friendly testers can create accounts and save data. That is a real milestone, but it answers only one question: can the idea work under controlled conditions?

Production asks harder questions. What happens when a user submits the same form twice, a payment succeeds but the confirmation request times out, an API sends a delayed webhook, or an employee tries a URL meant for an administrator? Who owns the cloud account? Where are the backups? How will anyone know that yesterday's deployment broke password resets?

AI-generated code can be sound or fragile, just like code written by a conventional development team. Work created with Lovable, Bolt.new, Replit, an AI coding assistant, or a conventional development process can all contain strong decisions and weak ones. The useful standard is evidence. Before real customers, sensitive data, or revenue depend on the app, verify the controls and operating procedures that a prototype rarely needs.

This production readiness checklist shows what to examine, what to test, and what must be decided before go-live. If you want a second set of eyes, Honor Tech offers a focused vibe-coded app review that ranks findings by business risk and helps turn the results into a launch plan.

What does production-ready mean for a vibe-coded app?

A production-ready vibe-coded app does what users expect, prevents actions they are not allowed to take, protects important data, fails in a controlled way, and gives the operating team enough information to detect and recover from problems.

That definition is deliberately broader than "the app works." A prototype is usually evaluated through the path its creator intended. Production software is exposed to impatient users, old browsers, weak connections, automated traffic, vendor outages, expired credentials, unusual data, and business rules that were never written down.

Readiness also depends on consequence. A small internal scheduling tool does not need every control required by a public application that stores health information or takes payments. The review should match the data, users, integrations, legal obligations, and cost of failure. There is no single certification that makes every app safe to launch.

The OWASP Application Security Verification Standard is a useful source for security requirements. See owasp.org source The NIST Secure Software Development Framework is useful for the development practices around the code. See csrc.nist.gov source Neither replaces understanding the specific application and business process.

Start with a one-page operating brief

Before reviewing code, write down what the app is supposed to protect and who will depend on it. This short document prevents hours of reviewing the wrong risks.

Include:

Do not accept "the AI platform handles it" as the owner for any line. A platform may provide reliable infrastructure, but someone in the business still needs account access, billing control, recovery options, and enough documentation to move the application if circumstances change.

Production checks for Lovable, Bolt.new, and Replit apps

The same production principles apply across AI app builders, but the handoff can look different from a conventional repository. If you need to deploy a Lovable app safely, make a Bolt.new app production-ready, or perform a Replit app security review, begin by identifying which parts exist inside the builder and which parts the business controls directly.

Export or otherwise secure access to the source code, environment configuration, database schema, and deployment settings. Confirm that the business controls the custom domain, hosting account, database, file storage, deployment credentials, billing, and backups. Test that another qualified developer can obtain the code, install its dependencies, and understand how a release reaches production without relying on the original builder's personal account.

Also decide what would happen if the builder were unavailable or its product changed. That does not always require leaving the platform. It does require a usable copy of the business data, an understood source-code export path where the platform supports one, and a recovery plan for the services that matter. These ownership checks are part of productionizing an AI-built app, not paperwork to postpone until a vendor relationship ends.

Verify authentication and authorization separately

Authentication answers who a user is. Authorization answers what that user may see or do. Many early applications implement the first and leave gaps in the second.

Hiding an admin button does not protect the admin action. A determined user can call an API directly, edit a record identifier, or type a route into the address bar. Every protected server action should check the signed-in user and the permission required for that specific record or operation.

For multi-customer software, tenant isolation deserves its own test plan. A user from Company A should not be able to read, search, update, export, or infer the existence of Company B's data. If the application uses Supabase, review Row Level Security policies and test them with different roles. Do not assume a policy exists because the front end filters results correctly.

Test invitations, email verification, password reset, multifactor authentication if used, session expiration, logout, role changes, and removed accounts. If the app uses social login, check what happens when the provider returns an email address that already belongs to an existing account.

Access rules should be written in plain language before they are encoded. A simple matrix listing roles, records, and allowed actions gives reviewers something concrete to compare with the implementation.

Find every secret and separate every environment

API keys and service credentials often enter a prototype quickly. Before launch, identify every secret, where it is stored, who can read it, and what it allows.

Private secrets, server-side API keys, and service credentials do not belong in browser code, mobile bundles, repositories, screenshots, support tickets, or logs. A value is not protected merely because it sits in a file named .env. If that file was committed, copied into an image, shared in chat, or included in a deployment artifact, treat the credential as exposed and rotate it. Some client-side values, such as publishable keys, are intentionally public. They still need correct server-side authorization, limited permissions, and any origin or platform restrictions the provider supports.

Use separate development, staging, and production environments. They should have separate credentials and, where practical, separate databases and third-party resources. A test should not be able to email real customers, charge a real card, or overwrite production records.

Give service accounts only the permissions they need. Record how to rotate each credential and which deployment or integration will be affected. Also verify that the business, not an individual contractor or former employee, controls the recovery email and billing for each production account.

Protect data with rules the database can enforce

The application interface is not the last line of defense. Important data rules should also exist close to the data.

Use database constraints for required values, unique identifiers, valid relationships, and other rules the database can reliably enforce. Use transactions when several writes must either all succeed or all fail. Decide how the system will handle two users updating the same record at the same time.

Review every migration as a production change. A migration that works on an empty development database may lock a large production table, fail on older data, or leave the application incompatible during a rolling deployment. Rehearse risky changes against a realistic copy of the data with sensitive values removed or protected.

Backups count only if they can be restored. Confirm what is backed up, how often, how long copies are retained, who can initiate a restore, and how the restored data will be validated. Run a restore test before launch for an application where lost data would matter.

Logs need the same care as the main database. Do not record passwords, authentication tokens, payment details, private documents, or complete personal records simply because logs feel temporary. Define retention and access for logs, exports, file storage, analytics, and support tools.

For applications that store personal data, document how retention, deletion, and privacy requests will work. Protect backups with encryption and access controls that are separate from ordinary production access where the platform supports it. A compromised production credential should not automatically give an attacker the ability to remove every recovery copy.

Test what happens outside the happy path

Happy-path tests show that a feature can work. Production tests should show how it behaves when timing, input, permissions, or dependencies are wrong.

Build tests around the journeys the business cannot afford to lose, such as registration, checkout, document submission, approval, scheduling, or account recovery. For each journey, try:

Payment and message-driven workflows need special attention. A network timeout does not prove that the external action failed. The app may need to query the provider, use an idempotency key, or wait for an authoritative event before retrying. Otherwise a reasonable recovery attempt can create duplicate charges, orders, notifications, or records.

Automated tests are valuable, especially for permissions and business rules, but they are not the entire answer. Someone who understands the real work should run representative scenarios in a staging environment. That person will notice confusing states and missing exceptions that a generated test may reproduce without questioning.

Review the generated code and its dependencies

An AI-generated code audit should establish what the application contains before judging whether it is maintainable.

Create an inventory of frameworks, packages, hosted services, SDKs, and copied components. Confirm that dependencies are still maintained, compatible with their licenses, locked to repeatable versions, and free of known critical vulnerabilities that affect how they are used. Remove packages and sample routes that the application no longer needs.

Look for duplicated business rules, inconsistent error handling, large components that mix several responsibilities, and generated comments that no longer match the code. Pay particular attention to code that authorizes users, constructs database queries, handles files, calls a shell or system process, renders user-supplied content, or moves money. An AI app security audit should check for query injection, cross-site scripting, output encoding, unsafe CORS rules, and cross-site request forgery protection when cookie-based authentication is used. Review TLS, secure cookie settings, security headers, rate limits, brute-force protection, and file-upload validation. Applications that accept files may also need content-type checks, size limits, isolated storage, and malware scanning.

Prioritize code the production team can understand and change safely. The team needs to know where critical decisions live, how to change them without surprising side effects, and how to tell whether a change broke something. Tests and short, accurate documentation are often more useful than a broad rewrite for style.

Make deployment repeatable and rollback believable

A production deployment should come from a known source revision through a documented process. Avoid making unrecorded changes in a hosting dashboard after the build. Those changes are difficult to reproduce during a recovery and easy to lose during the next release.

Use a continuous integration process to build the same artifact, run the agreed checks, and record what was released. Protect the production branch and production credentials. Run a small set of smoke tests after deployment to confirm that the site loads, users can sign in, and the most important workflow reaches its expected result.

Write down the rollback procedure before go-live. "Redeploy the old version" is incomplete if the new release has already changed the database or sent events to another system. Check whether migrations are backward compatible and identify changes that cannot safely be reversed. When production data has already changed, a controlled roll-forward fix can be safer than restoring an incompatible application version. For higher-risk releases, a feature flag or staged rollout may limit exposure while the team watches real behavior.

Honor Tech's go-live support covers release planning, cutover, verification, rollback preparation, and the first hours of production operation when a team needs hands-on help.

Add monitoring that tells a person what failed

Uptime alone is not enough. A server can return a successful page while signups fail, outgoing messages stop, or a background job quietly falls behind.

Monitor the journeys that matter. Track application errors, failed jobs, integration responses, unusual latency, database capacity, and business events such as completed orders or approved requests. A sudden drop to zero can be as important as a spike in errors.

Every alert needs an owner, a useful threshold, and an action. If an alert wakes someone, it should say which environment failed, when it began, what changed recently, and where to look next. Test that a broken monitoring check or failed backup creates a signal of its own. If no one will act on an alert, improve it or remove it.

Record a release identifier with errors so the team can connect a new failure to a deployment. Keep a short runbook for likely incidents, including expired credentials, a blocked email provider, a full storage account, failed database connections, and a third-party outage. Include containment steps such as revoking a compromised credential, disabling a risky integration, or temporarily pausing a workflow.

After launch, ongoing application support and maintenance should include dependency updates, monitoring review, backup checks, incident response, and small changes required by browsers or connected services. Production ownership should be explicit, even when the original builder remains involved.

Set recovery expectations in business language

Ask two plain questions. How long can the app be unavailable? How much recent data could the business afford to lose?

The answers guide architecture, backup frequency, and response planning. A team that can tolerate a day of downtime may not need the same infrastructure as a service that handles live customer transactions. Match the recovery plan to the business. A team promising fast recovery needs the systems and people to deliver it.

Test at least one meaningful recovery path. Restore a backup, replace a failed credential, or rebuild the production environment from the documented configuration. Note how long it took and what manual knowledge was required. A recovery plan that depends on one person remembering an undocumented step is not a dependable plan.

Check performance, quotas, and the first real cloud bill

AI app builders make it easy to combine hosted databases, serverless functions, storage, email, maps, payments, and model APIs. Each service has its own quotas, timeout behavior, pricing, and failure modes.

Estimate ordinary use and a credible peak. Test the slowest important queries and pages with representative data, not an empty database. When traffic, latency, or resource limits matter, run a load or concurrency test that can expose connection-pool, queue, and rate-limit failures. Check pagination, file limits, connection limits, background job duration, API rate limits, and what happens when a quota is reached.

Set billing alerts before launch. Review which features can create cost in a loop, such as retries, image processing, scheduled jobs, or repeated model calls. A performance test should also look for waste. Fast code that sends five unnecessary paid API calls per request can still become an expensive production problem.

Vibe-coded app go-live checklist

Use this checklist as a release gate. Some items may not apply, but each skipped item should be an informed decision rather than an assumption.

Fix, refactor, or rebuild?

Finding problems does not mean the whole app should be discarded. Many vibe-coded applications can reach production through focused repairs, stronger access controls, additional tests, and a repeatable deployment process.

Choose based on evidence. Start with the highest-consequence workflows and boundaries. A weak administrative permission check may be urgent but straightforward to fix. A data model that mixes every customer's records without reliable ownership may require deeper work. A rewrite has its own schedule, migration, and regression risks, so it should solve a specific problem that safer remediation cannot.

If the product needs capabilities the current foundation cannot support, custom software development can replace or extend selected parts in stages. If several business systems are involved, plan the systems integration work and failure recovery as part of the production scope.

What to bring to an independent production review

A reviewer can work faster and give better advice when the basic evidence is available. Gather:

Ask the reviewer to rank findings by consequence, evidence, recommended action, and whether each one blocks launch. The results should distinguish urgent production risk, sensible near-term improvement, and optional cleanup.

Honor Tech publishes software consulting pricing so you can understand the current hourly rates before requesting work. The size of a production-readiness effort still depends on the application, access, evidence already available, and the depth of remediation required.

Frequently asked questions

Can a vibe-coded app be production-ready?

Yes. The way code was produced does not decide whether the finished system is ready. Production readiness depends on its access controls, data integrity, testing, deployment, monitoring, recovery, ownership, and fitness for the risk it carries. Those qualities need to be verified rather than assumed.

How long does it take to make an AI-built app production-ready?

A focused internal tool with a small codebase may need only a short review and a limited set of fixes. A public application with payments, multiple user roles, sensitive data, or several integrations may require a larger remediation and testing phase. Start with a bounded review that identifies launch blockers and estimates the work from evidence.

Does every vibe-coded app need a penetration test?

No. The appropriate security work depends on exposure and consequence. Code review, dependency review, configuration checks, access-control tests, and threat-focused testing may address the main risks for a low-impact application. An internet-facing product that handles sensitive data, valuable transactions, or strict compliance obligations may justify an independent penetration test in addition to those controls. A penetration test is time-bounded and does not replace secure configuration, access-control testing, dependency updates, backups, monitoring, or rollback planning.

Can Honor Tech review the app and also fix it?

Yes. A review can stand on its own, or Honor Tech can separately scope remediation, testing, deployment, integration, and ongoing support based on the findings. Keeping the assessment clear and risk-ranked makes it easier to decide which work is necessary before launch and which improvements can follow later.

Treat launch as an operating decision

Taking a vibe-coded app to production is less about polishing the demo and more about accepting responsibility for the system. Someone must own access, data, deployment, costs, alerts, recovery, and support after the original burst of building is over.

The prototype created something worth protecting. A disciplined production pass gives the team a safer foundation for relying on it and turns a promising application into something customers and employees can depend on.

If you want an independent assessment, start with the vibe-coded app review. If the findings show that the app is close, go-live support can help turn the remaining work into a controlled release. You can also request a project review and share the builder, current environment, target users, and intended launch date.