How to Make a Vibe-Coded App Production-Ready

Your vibe-coded app works. Here is what it takes to make it production-ready: a 2026 field guide for moving AI-built applications from POC to a system the business can depend on.

Why the review date matters: AI coding tools and their security models are changing quickly. Netwoven periodically reviews this guide against current OWASP, NIST, major coding-agent and Microsoft platform guidance.

This article follows Part 1: AI Pilot to Production — Why Enterprise AI Has a Production Problem.

You spent a weekend with a coding agent.

The interface looks good. Login works. The database is connected. Your first users like it.

Then someone asks: “Can we put this into production next week?”

The answer is not necessarily no. But “it works on my machine” is not yes either.

Building software has never been easier. Lovable, Bolt, Replit, Cursor, Claude Code and GitHub Copilot can take an idea to a working application in hours. Making that application something a business can safely depend on is a different job. In 2026 that job has more parts, not fewer, because the tool that wrote your app can also act on your systems.

The short answer

A vibe-coded application is production-ready when you can show evidence of confidence across three layers: Control the Build, Prove the Release and Govern the Runtime.

Layer	The question it answers
1. Control the Build	Do we know, and control, what the coding agent could read, change, run and connect to?
2. Prove the Release	Do we have independent evidence that this exact version is safe and fit to deploy?
3. Govern the Runtime	Can the business securely operate, observe, recover, scale and own it after go-live?

Key takeaway: Vibe coding changes how quickly you reach the POC. It does not change what production demands.

What is a vibe-coded app?

A vibe-coded app is software built mainly by describing what you want to an AI tool and iterating on what it produces. The builder states the outcome, the AI writes the implementation, and the builder tests, gives feedback and repeats.

In practice, vibe-coded apps come from two families of tools:

• AI app builders such as Lovable, Bolt, Replit and v0. They generate the full stack and usually host it too. They are fastest to a demo, and they make many infrastructure decisions on your behalf.
• AI coding agents such as Cursor, Claude Code, GitHub Copilot and Codex. They work inside a code repository and can edit files, run commands and use tools.

The tools will keep changing. The production obligations will not. Whatever built it, the deployed system still contains code, dependencies, identities, data flows, APIs, infrastructure, secrets and business logic.

The authoring method should not determine the production standard.

Why production readiness changed in 2026

Until recently, the main question about AI-assisted code was whether it was correct. That is no longer the whole problem, because today’s coding agents act. They run shell commands, install packages, call tools through MCP servers, edit build pipelines and use the developer’s credentials.

The security community has responded:

• OWASP’s Secure Coding with AI Cheat Sheet maps the new trust boundaries: repository content, MCP servers, rules files such as CLAUDE.md and AGENTS.md, CI/CD agents, and the agent’s own permissions.
• AWS published a control framework for AI coding agents in July 2026. It pairs author-time controls on what agents produce with build-time controls on what reaches production.
• GitHub’s Copilot cloud agent can push only to its own branch. It scans its changes with CodeQL, dependency checks and secret scanning, and it cannot approve or merge its own pull requests.

The practical implication: production readiness now starts with what the agent was allowed to do, not with the finished code.

What breaks when a vibe-coded app goes to production?

When we review a vibe-coded POC, these are the ten problems we look for first. Most are easy to miss in a demo and painful to discover in production.

1. Secrets in the wrong place. API keys in the client bundle, a committed .env file, or a model key callable from the browser.
2. Authorization in the UI only. The admin button is hidden, but the API behind it answers anyone. Common with hosted databases where row-level security was never switched on.
3. Endpoints that trust the client. The server accepts a user ID or role sent by the browser instead of deriving it from the session.
4. Packages nobody chose. Dependencies the agent added that are unmaintained, unnecessary, or do not exist and were registered by an attacker (“slopsquatting”).
5. No rate limits on paid calls. An LLM-backed endpoint with no throttling turns one curious user into a large invoice.
6. A schema with no history. Tables created by hand or by the agent, with no migrations to recreate or roll back the database.
7. The same logic written five times. Each prompt solved its problem fresh, so a business rule now lives in several places that drift apart.
8. Tests that prove nothing. The agent wrote the tests, then weakened them until they passed.
9. Platform lock-in nobody decided on. Hosting, auth and data are tied to the builder platform, with no deliberate exit path.
10. Logs, not observability. console.log statements, but no way to trace one failed request across services.

Every item on this list is fixable. The point is to find them before your users do.

For how problems like these play out in a real application, see the staffing case study after Layer 3.

First question: should this app go to production at all?

Not every vibe-coded app should go to production, and that is a good outcome, not a failure. When building is this cheap, organizations accumulate working apps that nobody owns, funds or measures.

Netwoven’s AI Pilot-to-Production Framework is explicit on this point: a successful demo is not evidence for production. Before any hardening work, the framework asks for an evidence-based decision with four possible outcomes.

Decision	When it fits a vibe-coded app
Promote	A named business owner, a frequent and material workflow, and a measurable target.
Redesign	The problem is real, but the generated architecture will not carry production load or controls.
Keep it small	It works well as a personal or team tool with non-sensitive data. Leave it there, deliberately.
Retire	It proved the idea. The value now lies in what you learned, not in the code.

Three questions usually settle it. Who owns the outcome? How often does the workflow run, and what does it cost today? What would you measure to know production was worth it?

If you’re a business builder, this is the handoff point

Vibe coding has turned product managers, analysts, architects, domain experts and founders into builders. That is a good thing. If you built something valuable, you completed product discovery faster and cheaper than any requirements document could.

But the work is changing now. If you can’t confidently review identity, authorization, dependencies, network boundaries, CI/CD or failure handling, bring in software, platform or security engineering at this point. That is not failure. It is the normal move from can we build it? to can we operate it responsibly?

You’ll make the handoff much faster if you bring:

• The repository, plus the platform project if you used an app builder.
• Who uses it today, how often, and for what.
• What data it touches, and where that data came from.
• Every external service, API key and integration you set up.
• What it must never do, such as which records it must never change.
• The prompts or decisions that shaped key behavior, if you still have them.

Layer 1: Control the Build, starting with an audit

If your app already exists, Layer 1 starts as an audit of how it was built. Our framework’s rule for existing pilots is simple: assess before you extend.

Audit what the agent could reach

A coding agent with terminal, network and credential access is a privileged actor. Find out what it had:

• Credentials. Were production keys, cloud credentials, SSH keys or signing keys present in the environment the agent worked in? If so, rotate them.
• Network and tools. Which MCP servers, APIs and external services could it call?
• Data. Did it see real customer or business data while building?

Review the files that steer the agent

Some repository files do not change the app; they change the agent. CLAUDE.md, AGENTS.md, .cursorrules, .github/copilot-instructions.md and MCP configuration all shape what future agent sessions will do. Treat edits to them like edits to security policy.

Give the same scrutiny to dependency manifests and lockfiles, install scripts, Dockerfiles, CI workflows, Terraform or Bicep, and deployment scripts.

Review the diff, not the summary

You asked the agent to “add a login button”. The diff may also contain a new library, a changed CI workflow and an edited configuration file. Agents make out-of-scope edits. Their summaries rarely mention them.

For each package the agent added, confirm three things: it exists on the official registry, it is actively maintained, and it is actually needed.

Going forward: bounded autonomy

Once the audit is done, set the rules for the next round of changes:

• Give the agent only the privileges the current task needs.
• Run it in a sandbox that separates filesystem access from network access.
• Keep production credentials out of the development environment entirely.
• Approve MCP servers and tools from an allowlist. Discover broadly, authorize narrowly.
• Do not auto-approve agent commands on unfamiliar repositories.

Layer 2: Prove the Release

A working app is evidence that it functions. It is not evidence that it is ready for production. One of our framework’s core principles is evidence over confidence: production quality is proven with tests, evaluations and review, not with demo impressions.

Can your team explain it without the agent?

Another competent engineer should be able to describe the components, the data flows, the external services, the identities used, where secrets are injected, how the database is migrated and what runs at build time. It does not need a 100-page specification. It does need to be understood.

If your team can’t explain the architecture without asking the coding agent, it isn’t ready for production.

Don’t let the author grade its own work

Suppose the agent writes a feature, then writes the tests. The tests fail, so it edits the tests, and everything turns green. Is the code correct? Maybe. But the evidence is not independent. Agents can weaken assertions or over-mock dependencies until tests confirm whatever was generated.

The agent that wrote the code should not define all the evidence that the code is correct.

Build a release evidence stack

Evidence type	What it answers	Examples
Deterministic gates	Questions with hard answers	Build passes, required tests pass, no known-vulnerable dependency, no secret in the repo, static analysis and IaC policy clean
Independent AI review	Questions scanners miss	Does it meet the requirement? Any out-of-scope edits? Was an authorization check weakened?
Human accountability	Consequential judgments	Architecture, security boundaries, money movement, regulated actions, sensitive data, exceptions to policy

AI review is a useful extra signal, not the deployment authority. Put human judgment where the consequences are, rather than asking someone to read every generated line.

Test beyond the happy path

• Authorization tests: can user A reach user B’s data by calling the API directly?
• Negative tests: malformed input, expired sessions, unavailable dependencies.
• Integration and end-to-end tests of the business journeys that matter.
• Performance tests: what happens when 10 users become 1,000?
• Recovery tests: what happens when a component fails?

If your app contains AI: add evaluation

In traditional software, code changes behavior. In AI systems, behavior can change even when the code doesn’t, because models, prompts, tools and knowledge change. For these apps, CI/CD becomes CI/CD plus evaluation: a representative golden dataset, tool-call tests, safety tests and quality thresholds that block a release when they fail.

Make the build reproducible

Another engineer should be able to clone the repo, build, migrate the database, provision infrastructure and deploy without reconstructing your history from memory. That means source control, pinned dependencies, separate environments, migrations, injected secrets, CI/CD and a tested rollback.

Two decisions, not one

Our framework separates two release decisions that vibe-coded projects often merge. Is this release fit? is answered by engineering, QA, security and operations. Should it go to these users now? is answered by the business owner, who accepts the residual risk. A green pipeline answers the first question only.

Layer 3: Govern the Runtime

Passing the release gates gets an app into production. Five disciplines keep it healthy there.

Identity: who is allowed to do what?

A POC asks whether the user can log in. Production asks whether this identity may perform this action on this resource. Authentication is not authorization. A hidden button is not authorization. A service account with broad database access is not made safe by a narrow UI.

For every consequential action, you should be able to trace the chain: user → application → service identity → external system → resource changed → the authorization decision that allowed it.

Resilience: design the unhappy path

A POC proves what happens when everything works. Production defines what happens when something doesn’t. What if the model API times out? The database is briefly unavailable? A third-party API returns HTTP 429? The user clicks twice? A queue redelivers a message?

The answers are timeouts, bounded retries, idempotency, circuit breakers and graceful degradation. These are minimum requirements, not enterprise extras.

Observability: logs are not enough

You need structured logs, metrics, traces, health checks, audit events, alerts and dashboards, tied together by one correlation ID per request. For AI features, also track model and tool calls, tokens, latency, fallbacks and cost.

The 2:17 PM test: if a user reports a failed transaction at 2:17 PM, can you trace that request through every service and dependency it touched?

Economics: cost per outcome, not cost per token

A demo handles hundreds of requests; production may handle millions. Measure cost per successful business transaction, and ask whether every step really needs a model.

Our framework’s principle is: deterministic where required, probabilistic where valuable. In one production agent we built for a semiconductor enterprise, about 85% of requests are resolved deterministically, without a model call. The model handles only the requests that need reasoning or language understanding, which keeps cost per transaction predictable as volume grows.

An AI app that works technically but cannot run economically is not production-ready.

Ownership: who gets paged six months from now?

Dependencies, models, threats and business rules all change after go-live. The most common way a vibe-coded app fails is not a breach. It is orphaning: the original builder moves on and nobody owns it.

Before launch, name who owns the business outcome, the code, dependency patching, incident response, change approval, AI evaluation failures and cloud cost. Name who can turn it off, and who decides when to retire it.

Who owns this six months after the original builder moves on?

Case study: from vibe-coded staffing demo to production

The demo took a few days. For this application, production was scoped at roughly 12 to 16 weeks – not as a general benchmark, but because of the production controls the real workflow required. The example is drawn from an application we are taking to production now.

A delivery organization asked an AI coding tool to read its resource-planning spreadsheet, match people to projects by skill and availability, recommend allocations and show utilization. Within days it had a convincing POC: a React dashboard, a Python backend, spreadsheet upload and AI-generated staffing suggestions. With clean sample data and one user, the workflow looked complete.

Then real operations arrived:

1. Two managers approve the same engineer, both working from yesterday’s availability.
2. A project slips, and its new end date is not yet known.
3. The commercial-rate field was blank for 199 of 221 active project rows. Treating those blanks as zero would make every downstream margin calculation unreliable.
4. An approved allocation fails halfway through its handoff to the resource-management system of record.

A production design has to handle all four. It keeps unknown values unknown, rechecks capacity and authority at the moment of approval, and prevents double-booking. It also distinguishes an allocation that was approved from one that was actually applied and verified downstream. AI interprets a manager’s request; deterministic rules and authorized people control what happens next.

The path keeps the useful POC and hardens it in four stages:

1. Trustworthy inputs (the production decision). Reconcile the workbook, name the authoritative sources, agree calendars and allocation rules, and settle who can approve what.
2. A safe workflow (Layers 2 and 3). Add server-side permissions, transactional capacity checks, approval history, duplicate-safe commands and recoverable handoffs. Test simultaneous approvals, stale data, revoked access and partial failures.
3. Operable on Azure. Static hosting for the React front end, a modular Python Function App, Azure SQL, Azure Storage, Microsoft Foundry for inference, Entra ID and monitoring. Add repeatable deployment, durable processing, alerts, rollback and tested recovery.
4. Proven against real work (Layer 2’s two decisions). Run alongside the existing weekly process for at least three cycles, reconcile recommendations with what was actually applied, then make an explicit go/no-go decision with a named support owner.

The 12–16 week envelope covers the full scope with a small team: a product owner who knows resource management, a technical lead, frontend and backend engineers, and shared QA and DevOps. It is a planning range, not a promise. A narrower, supervised pilot could move faster, with its reduced scope stated plainly.

Vibe coding compressed the journey to a convincing demo. The production effort goes into proving that the same application behaves safely with real data, concurrent decisions, failures and accountability.

Moving a vibe-coded app to Azure

Apps from AI builder platforms often need to leave the platform that created them, to reach enterprise identity, private data or compliance requirements. For Microsoft-centric organizations, the usual mapping is:

Production concern	Typical in a vibe-coded POC	Production target on Azure
Hosting	Platform preview URL or one container	Azure Container Apps or App Service, with separate dev, test and prod environments
Identity	Platform or hosted-database auth	Microsoft Entra ID for staff; Entra External ID for customers
Secrets	.env files and pasted keys	Azure Key Vault, accessed through managed identity
Data	Hosted Postgres or SQLite, changed by hand	Azure Database for PostgreSQL or Azure SQL, with versioned migrations and backups
API boundary	Browser calls services directly	Azure API Management where a managed API policy boundary is warranted, with throttling and policy controls
Build and release	“Publish” button	GitHub Actions or Azure DevOps, with code, dependency and secret scanning – for example, GitHub Advanced Security
Observability	console.log	Application Insights and Azure Monitor, with correlation IDs
Security posture	None	Microsoft Defender for Cloud
Network	Public by default	Private endpoints and VNet integration where data is sensitive

Cloud or on-premises?

The production standard is the same in both. What changes is who provides each control. Managed cloud services take on part of the work for runtime, scaling, patching and availability. On-premises gives you more direct control and more direct responsibility.

So the useful question is not “Azure or on-prem?” It is: for each production responsibility, who owns the control, and how is it proven?

Govern by consequence, not by hype

The opposite mistake is just as common: applying the strictest process to every AI-built app. That does not scale, and it pushes builders back to shadow IT.

Scale the rigor to the consequence. Our framework uses four risk tiers:

Tier	Example vibe-coded app	Minimum assurance
Low	Read-only internal tool on non-sensitive data	Access control, dependency and secret scanning, basic monitoring, a named owner
Moderate	Team app with confidential data, or reversible updates to business records	Design review, threat model, automated release gates, human confirmation on actions, active operations
High	Customer-facing, or makes financial, HR, legal or compliance changes	Independent security review, adversarial testing, strong approvals, detailed audit, controlled rollout, executive risk acceptance
Restricted	Irreversible or safety-critical actions with no human in the loop	Not under the default path. Needs specialist governance and explicit executive authorization.

The tier sets the speed. Low-risk apps get a fast lane; consequential apps earn their controls.

Taken together, the three assurance layers provide a practical way to assess whether a working application is ready to become a dependable business system. At Netwoven, we use these layers as the Netwoven Production Assurance Model.

Is your vibe-coded app production-ready? A 10-question scorecard

The graphic below offers a quick 10-check view of readiness. For a deeper assessment, score each question from 0 to 4 using the maturity scale below:

0 = absent · 1 = ad hoc · 2 = partially defined · 3 = implemented · 4 = measured and operating

#	Question	Layer
1	Can another engineer explain the architecture, dependencies and data flows without asking the coding agent?	Build
2	Has the agent’s access to files, network, tools and credentials been audited, and is it bounded going forward?	Build
3	Have changes to agent instructions, MCP config, CI/CD, dependencies and build scripts been reviewed explicitly?	Build
4	Do deterministic tests and security gates validate each release independently of the agent?	Release
5	Has someone other than the code-generating agent reviewed the critical logic and risk boundaries?	Release
6	Are identity and authorization enforced server-side, with least privilege?	Runtime
7	Does the app handle dependency failures, retries and duplicate actions deliberately?	Runtime
8	Can you trace a single request end to end, well enough to diagnose an incident?	Runtime
9	Is cost per successful transaction understood at production volume?	Runtime
10	Is a named owner accountable for operation, security, change and eventual retirement?	Runtime

How to read it: treat any question scored 0 or 1 as a blocker, whatever the total. Questions 2, 6 and 10 matter most; a weak score on any one of them outweighs strength elsewhere.

If several answers are low, you didn’t build the wrong app. You built a successful POC, and now the production engineering begins.

Vibe coding changes the starting line, not the finish line

Coding agents are among the most significant changes to software development in years. Teams validate ideas faster. Domain experts build directly. Small teams ship what used to need far more people. None of that should be slowed down unnecessarily.

The aim is not to make AI-assisted development behave like 2019. It is to update production engineering for 2026.

Production assurance is the discipline of controlling how AI creates software, independently proving what is released, and governing the deployed system throughout its operating life.

However your app was built, the final question is the same: can the business safely depend on it? If the answer is “not yet”, that does not lessen what you built. It tells you what work comes next.