Vibe-Coded AI App Production Readiness Review

Vibe-Coded AI App Production Readiness Review

A vibe-coded AI app needs 4 possible production decisions after one evidence review: harden, replace components, partially rebuild, or rebuild.

Fast prototype creation is valuable, but prompt-led coding can hide account ownership, generated dependencies, untested migrations, permissive authentication, and deployment steps that live only on one machine. The production decision should preserve working value without carrying unknown risk into customer data or team operations.

This article gives you 4 acceptance decisions tied to one buyer outcome. It does not ask you to trust a demo, a vendor label, or a generic quality score. It asks for inspectable evidence, a failure boundary, and a named next action before the workflow reaches more users or gains more authority.

The decision utility

Use the table as a release contract. Choose the intended mode before the test run, keep the same evidence pack while fixes are made, and change the mode only when the failed condition is actually resolved. A different slide deck or a smoother demonstration is not new evidence.

How to run the acceptance review

Start with one workflow, one user group, one source boundary, and one consequence. Record the exact configuration being tested, then run the 4 decisions below against normal work and the failures that would matter most. Keep source material, expected outcomes, and observed results separate so a later change can be compared honestly.

Test 1: Establish code and account ownership

Production starts with the ability to access, change, build, deploy, and recover the product without the original browser session or individual account. Repository, cloud, database, model, email, domain, analytics, and secret ownership must belong to the business.

Pass when a second engineer can clone the repository, obtain approved access, build the app, deploy to a safe environment, and identify every external account. Record account owners and recovery methods without copying secrets into documents.

Rebuild or replace components when source history is missing, a critical service cannot transfer ownership, or deployment depends on an inaccessible personal account. Do not postpone ownership until after customer launch.

Test 2: Map generated code and dependencies

Generated code can be correct, unnecessary, duplicated, outdated, or copied into an architecture nobody intended. The review should explain each subsystem, dependency, license, build step, and external service in business terms.

Pass when the team can produce a dependency graph, identify direct and transitive packages, trace the entry points, and remove an unused dependency without breaking the build. High-risk or abandoned packages need a replacement decision.

Replace components when generated wrappers conceal a critical library or when several packages solve the same job. A clean inventory is more valuable than a cosmetic rewrite because it reveals the true operating surface.

Test 3: Trace data from input to deletion

AI prototypes frequently move user content through browser state, APIs, model providers, logs, object storage, vector stores, and analytics. Every path needs a purpose, retention rule, and deletion behavior.

Use representative data to trace collection, validation, transmission, storage, model use, logging, backup, export, and deletion. Pass when the product can answer where one record exists and remove it through the normal operating process.

Rebuild the affected path if sensitive fields reach uncontrolled logs, if tenant boundaries are unclear, or if deletion cannot be verified. Masking the interface does not repair an unknown data path.

Test 4: Replace placeholder authentication and authorization

A prototype login may prove a screen flow while leaving server actions, object access, administration, password recovery, session expiry, and tenant isolation incomplete. Authentication alone does not establish authorization.

Pass when every sensitive server action checks identity and object-level permission, sessions expire correctly, privilege changes take effect, and one customer cannot access another customer by changing an identifier.

Partial rebuild is appropriate when access control is scattered across client code or duplicated inconsistently. Centralize policy near the protected data and rerun the role matrix before adding features.

Test 5: Make AI behavior a testable contract

Prompts embedded in components are difficult to version, evaluate, and roll back. The app needs named inputs, outputs, refusal conditions, tool permissions, evidence requirements, and release tests for each AI feature.

Pass when prompt and model configuration changes are versioned, structured outputs validate, risky actions require the intended approval, and an unchanged evaluation set can compare releases.

Replace the AI component if behavior depends on hidden builder state or cannot be reproduced outside one tool. Preserve validated examples as the starting acceptance set for the new implementation.

Test 6: Test database migrations and recovery

Prototype databases often evolve through manual console edits or automatic schema changes. Production needs repeatable migrations, backups, restore evidence, and compatibility during deployment.

Pass when a clean environment can apply migrations in order, a backup can restore to a separate environment, and rollback or forward repair is defined for a failed release. Include realistic data volume and constraint cases.

Partial rebuild the persistence layer if schema history is unknowable or destructive changes cannot be rehearsed. Product logic can often survive while the data foundation is replaced carefully.

Test 7: Build a repeatable delivery path

A production build should not depend on remembered terminal commands. Source checks, tests, configuration validation, artifact creation, migration, deployment, smoke tests, and rollback need a repeatable path.

Pass when an authorized team member can release the same commit to a safe environment, identify the artifact, and restore the previous version without modifying source during the release.

Harden when the path is manual but understood. Rebuild only when the application cannot produce a stable artifact or the environment contains unknown changes outside source control.

Test 8: Observe customer and operator outcomes

Console output is not production observability. The team needs to see request failures, AI validation failures, dependency health, queue state, critical business actions, and data-path errors without logging private payloads.

Pass when alerts identify the affected feature, release, tenant-safe context, and operator action. A controlled failure should appear in the expected dashboard and reach the named operator.

Replace monitoring code that exposes sensitive content or produces noise without action. Good observability narrows diagnosis while respecting the same data boundaries as the product.

Test 9: Exercise rollback and kill controls

A production team must be able to disable one risky AI feature, stop writes, or return to the prior release without taking the whole product offline.

Pass when a controlled test disables the feature, preserves user state, prevents new actions, and confirms the previous version still understands current data. Document who may trigger each control.

Partial rebuild if the AI feature is inseparable from core product paths. Isolation is often the difference between hardening a prototype and replacing its architecture.

Test 10: Prove team handover

The final test is whether the product can move from the original builder to a team that can operate it. Handover covers architecture, accounts, data, releases, incidents, model behavior, known debt, and next decisions.

Pass when another engineer and product owner can answer how the system works, deploy a change, investigate a failure, and identify the release boundary without coaching from the creator.

Treat failed handover as evidence, not embarrassment. It may justify targeted documentation and hardening, or expose foundations that should be rebuilt before the business becomes dependent on them.

Worked operating scenario

A founder has a working AI customer portal with early users. The interface and workflow logic are valuable, but authentication runs partly in client code and database changes were made manually. The sensible outcome is a partial rebuild of access and persistence while preserving validated screens, user language, and AI acceptance cases.

The scenario is deliberately narrow. It shows how a useful first release can preserve business value while limiting authority. Expansion should follow evidence from the same acceptance contract, not pressure to include more document types, teams, systems, or actions in the first milestone.

What the implementation brief must contain

The production review should inventory repositories, accounts, services, dependencies, licenses, environments, data paths, identities, roles, prompts, model settings, migrations, tests, delivery steps, monitoring, backups, rollback, and handover. Each finding should lead to one of the four disposition modes, an acceptance result, and a named next milestone.

Ask the delivery team to return the brief as an acceptance map rather than a feature catalogue. Each item should identify the expected evidence, the condition that blocks release, the person responsible for the decision, and the recovery path. This makes proposal comparison more concrete and makes handover possible later.

Connected decisions in the KUMO library

The ai code generation article covers a separate but connected decision. Use this adjacent decision when you need to choose the architecture before applying the acceptance boundary.

The custom software qa release checklist ai ready products 2026 article covers a separate but connected decision. Use this canonical when the question shifts from release evidence to the underlying data or operating foundation.

The software maintenance cost after launch year one budget article covers a separate but connected decision. Use this guide for the broader risk or delivery decision that should remain separate from this article.

The devops cloud cost optimization ai products 2026 article covers a separate but connected decision. Use this resource when the workflow moves from a controlled release into ongoing operation.

The agency to in house engineering handover checklist article covers a separate but connected decision. Use this final link for the next distinct buyer decision rather than extending this framework beyond its boundary.

What to do this week

Choose one real workflow and write the release mode you want. Then select representative work, boundary cases, and one failure that would cause the most business harm. Run the first evidence review before adding integrations or expanding scope.

Next, assign one person to own the operating result and another to challenge the evidence. The goal is not a committee. It is to prevent the builder from being the only person deciding whether the build passed. Record disagreements as missing acceptance criteria and resolve them in the contract.

Finally, rehearse the stop path. Disable the feature, preserve the permitted evidence, tell the affected user what happened, and restore service only after the release condition passes. A workflow that cannot stop safely is not ready to gain more authority.

A practical route from decision to build

KUMO builds production AI and custom software for growing businesses. The vibe coding to production service is the relevant route when this acceptance boundary needs to become a scoped implementation. The public case-study library example shows an example of KUMO delivery work without changing the decision criteria in this article.

If you want to turn the evidence map into a scoped first release, Map the first production-hardening milestone.

Primary sources used for this framework

CISA Secure by Design is an authoritative primary reference used to ground the controls, architecture, or evaluation approach described here.

NIST Secure Software Development Framework is an authoritative primary reference used to ground the controls, architecture, or evaluation approach described here.

OWASP Top 10 for LLM applications is an authoritative primary reference used to ground the controls, architecture, or evaluation approach described here.

GitHub dependency graph documentation is an authoritative primary reference used to ground the controls, architecture, or evaluation approach described here.

AWS Well-Architected Framework is an authoritative primary reference used to ground the controls, architecture, or evaluation approach described here.

Implementation decisions to resolve

Can a vibe-coded app be used in production?

Yes, when evidence shows the business owns the code and accounts, data paths are controlled, access is enforced, changes are tested, delivery is repeatable, and rollback and operation are proven. The creation method alone does not decide readiness.

When should a vibe-coded prototype be rebuilt?

Rebuild when ownership, tenant safety, data behavior, or core architecture cannot be established and targeted hardening would preserve unknown risk. Preserve validated workflows and user learning as requirements.

What should the first production-readiness checks cover?

Start with repository and account ownership, deployment reproducibility, data flow, and authorization. These determine whether the team can safely inspect and change everything else.

Is a security scan enough to approve production use?

No. Scans can find classes of defects, but readiness also requires product behavior, data, permissions, migrations, AI evaluations, operating evidence, dependency ownership, recovery, and handover.

What evidence should an engineering handover include?

Provide source and account access, architecture and data maps, environment setup, model and prompt versions, migrations, tests, release and rollback steps, monitoring, known debt, and acceptance decisions. Then have the receiving team exercise them.