Is Vibe Coding Bad for Production? A Founder’s Launch Test

Vibe coding is not bad for proving a workflow. It is bad when generated code reaches production without an owner, enforceable access rules, repeatable deploys, and evidence that billing and recovery work. Launch only after those controls pass; otherwise harden the current build or move it into rescue.

The verdict: vibe coding is a build method, not a release standard

The useful question is not whether AI generated the code. It is whether someone can prove what the product does, who can do it, what happens when a dependency fails, and how the last safe version returns.

Vibe coding means building software through natural-language instructions while the tool generates and edits much of the implementation. It is excellent at making an idea concrete. An MVP is the smallest product that proves a core workflow with real users, so that speed has real value during discovery.

Production has a different standard. A polished screen proves that a happy path rendered once. It does not prove that one company cannot read another company's records, a repeated payment event cannot grant access twice, a failed deploy can roll back, or a future engineer can explain the system without replaying an old chat.

Consider a reference business research product. A workspace owner invites a colleague, the colleague uploads a document, the product produces an analysis, and the owner upgrades the workspace. The demo is convincing when that sequence works. The product is launchable only when the team can also prove that an outsider cannot fetch the document, a member cannot change the workspace plan, a failed analysis leaves a recoverable state, and a billing retry does not corrupt access.

Red Hat's February 2026 practitioner guidance says generated work is small enough to vibe when a unit or functional test can validate the output; otherwise it needs a specification. That is also the release boundary. If the core behavior cannot be stated and tested, it is not ready to carry customer risk.

If the product is still flexible, use the rewrite-debt prevention workflow before adding more features. The cheapest rescue is the one the scope prevents.

Decide between launch, harden, and rescue

Launch when the evidence is complete, harden when the architecture is legible but some controls are missing, and rescue when the team cannot safely explain, change, or operate the production-critical core.

The middle column matters. Generated code does not need an automatic rewrite. If the boundaries are understandable, the source is owned, and changes can be verified, targeted hardening is usually the better buy. Add the missing policies, tests, deployment controls, and operating evidence around the core workflow.

A rescue becomes rational when each patch changes the question instead of answering it. Imagine the reference product can upload and analyze documents, but workspace membership is checked in page components, database queries accept a workspace identifier from the browser, and the payment success page writes the active plan directly. Each surface may look fixable. Together they show that identity, data, and billing have no trustworthy boundary. Patching screens would preserve the wrong structure.

This is also why platform choice should be based on code control and handoff, not generation speed alone. The vibe-coding platform decision is useful before a build. After the build exists, evidence from the actual repository outranks the tool's feature list.

Prove ownership and rollback before you test features

Ownership comes first because no production problem is truly fixable if the company cannot reach the code, data, credentials, and deployment path.

Create an ownership map with a named company-controlled account for each critical asset:

• source repository and its default branch
• deployment project and production environment
• database, storage, and backup location
• authentication, email, and payment providers
• domain, DNS, and certificate controls
• secrets, API credentials, and rotation process
• error reporting, logs, and uptime alerts
• the operator who can deploy and the operator who can roll back

Do not accept a screen share as proof. Open each account from a company identity, confirm the role, and record the recovery method. Export the repository into a clean environment and make the application build. Then identify the exact version running in production and the last version known to be safe.

For the reference product, the ownership test is simple to state: a founder should be able to revoke the original builder's access, clone the repository, deploy a staging copy, rotate the analysis provider key, and restore the prior release without asking the builder to press a hidden button. A failed item is not necessarily a rescue signal, but an unexplained dependency is.

GitHub's branch-protection documentation shows what enforceable repository control looks like. GitHub branch protection can require pull request reviews, status checks, conversation resolution, signed commits, a linear history, a merge queue, and successful deployments before merging. GitHub branch protection disables force pushes and prevents branch deletion by default.

You do not need every available switch for an early product. Require review and a passing test on the core workflow, protect the production branch, and remove undocumented bypasses. The point is not process theatre. It is making an accidental prompt-driven edit unable to become a production release without visible evidence.

Separate login from authorization and prove data isolation

A working login is not a security boundary. Authentication proves who the user is; authorization decides which records and actions that identity may access.

Many generated products implement authentication through a provider, then treat the presence of a signed-in user as permission. A workspace product needs more. The server and database must verify that the signed-in user belongs to the requested workspace and holds the role required for the action. Hiding an admin button does not stop a direct request to the underlying endpoint.

For products built on Supabase, the vendor's own production guidance is direct. Supabase's production checklist says to enable row level security, or RLS, on all tables. Supabase says tables without RLS enabled and reasonable policies allow any client to access and modify their data. RLS is a database rule that evaluates which rows a request may read or change, so it keeps the decision next to the data rather than trusting the interface.

Run the access test as a matrix, not as a tour through the screens:

1. 1

   Map actors to resources

   List each human role and service process beside the records and actions it needs. If the sentence says "all signed-in users," inspect it again. Most business products need a workspace, ownership, or record-level condition.

2. 2

   Test the denied path directly

   Use a real low-privilege account and call the endpoint with another workspace's identifier. Repeat the test against reads, updates, file access, invitations, and administrative actions. A disabled button is not evidence.

3. 3

   Inspect privileged credentials

   Confirm that elevated secrets exist only in server-controlled environments, are absent from browser bundles and logs, and can be rotated without rebuilding the product's identity model.

4. 4

   Turn the result into acceptance criteria

   Write the passing and failing behavior beside the release candidate. The OWASP Application Security Verification Standard provides a basis for testing web application technical security controls and a list of requirements for secure development. ASVS 5.0.0 is the latest stable version. OWASP says ASVS can be used during procurement as a basis for specifying application security verification requirements in contracts.

The payoff is commercial as much as technical. A founder can show an investor, buyer, security reviewer, or incoming engineer what access is intended and the evidence that enforces it. "The builder handles auth" cannot carry that conversation. A tested policy can.

Treat billing as a state machine, not a success screen

Billing is launchable when access follows verified server-side events and remains correct when those events repeat, arrive late, or arrive in a different order.

A state machine is a defined set of product states and the allowed transitions between them. For a subscription product, the states might be trial, active, payment issue, canceled, and ended. The interface displays the current state, but it does not get to invent it.

Stripe's webhook guidance documents the failure conditions a real integration must handle. Stripe says webhook endpoints might occasionally receive the same event more than once. Stripe recommends logging processed event IDs and not processing an already logged event again. Stripe signs every webhook event in the Stripe-Signature header and says to verify the signature before acting on the event.

Stripe attempts live-mode event delivery for up to three days with exponential backoff. Stripe does not guarantee that events arrive in the order they were generated. A billing path that only works when a single event arrives immediately is a demo path.

Use the reference workspace upgrade as a worked test:

• Complete a purchase and confirm that the server, not the browser success page, grants the paid entitlement. An entitlement is the feature access attached to the account's billing state.
• Deliver the same valid event again. The recorded event identifier should stop the plan change from applying twice.
• Delay an event while the user refreshes, signs out, and returns. The workspace should show a pending state or reconcile against the billing source, not guess.
• Apply cancellation and payment recovery in an unexpected sequence. The final product state should follow the authoritative billing record and allowed transitions.
• Send a request with an invalid signature. It should change nothing and leave enough evidence for an operator to investigate.

The test is not "can we charge a card?" The test is "can we reconstruct why this workspace has this access?" If the answer depends on a UI redirect, a manual database edit, or an operator's memory, harden the billing path before launch.

Make deploys, failures, and recovery observable

A launchable product has a known release, a safe place to test it, visible failure evidence, and a rehearsed path back.

Staging is a non-customer environment that mirrors the important parts of production. It is where a release candidate should prove the core workflow with production-like configuration and synthetic data. It does not need the same scale, but it must exercise the same identity, data, billing, and deployment boundaries.

Supabase's production checklist recommends load testing, preferably in a staging environment. Load testing means applying expected concurrent activity and watching whether latency, errors, or resource limits break the workflow. For the reference product, the valuable test is not anonymous traffic to the home page. It is concurrent document uploads, analysis jobs, and result retrieval under the limits the launch expects.

Build a release evidence packet that a founder can inspect without reading the entire codebase:

• the release commit and the person who approved it
• a passing automated test for the core user workflow
• a list of production services, owners, and current credentials
• error records that connect a user-visible failure to a server-side event
• a backup status and a restore note for critical data
• the rollback action, the person authorized to run it, and the signal that triggers it

Continuous integration, often called CI, is the automated path that builds and tests a code change before it merges. Use it to make the core workflow a release gate. Broad test counts are less useful than a small set of tests tied to real business risk: access isolation, state transitions, billing, and recovery.

An illustrative failure makes the standard concrete. Suppose the analysis provider times out after a document upload. The user should see a recoverable status, the job should not remain falsely complete, the failure should appear in operator evidence, and a retry should not create duplicate records. If the only response is "prompt the builder to fix it," the product lacks an operating model.

Run the audit without turning it into a rewrite project

The fastest useful audit freezes feature work, tests the core workflow, and ends with a release decision plus a bounded remediation scope.

1. 1

   Name the next business milestone

   Choose the event the product must survive: a private pilot, paid onboarding, a public launch, a diligence review, or a handoff to an internal engineer. The milestone sets the required evidence.

2. 2

   Freeze the release candidate

   Tag the exact code and configuration under review. Stop adding features while the evidence is gathered, or every result becomes stale before the decision is made.

3. 3

   Trace the core workflow

   Follow one user outcome across interface, server, database, third-party services, billing, and operator evidence. Record who owns each boundary and how a failure returns to a safe state.

4. 4

   Run allowed and denied cases

   Test the happy path, cross-workspace access, low-privilege actions, duplicate billing events, dependency timeouts, a failed deploy, and a data restore. Save the result, not just a verbal assurance.

5. 5

   Classify each finding

   Use three buckets: release blocker, bounded hardening, or later improvement. A release blocker threatens identity, money, data, recovery, or ownership. A later improvement does not prevent the next milestone from being safe and supportable.

6. 6

   Rerun and decide

   Fix the bounded set, rerun the same evidence in staging, then choose launch, harden again, or rescue. Do not approve launch because the backlog looks smaller.

The audit output should fit on a decision page:

This keeps the scope commercial. The buyer can see what must change before the milestone, what can wait, and what cannot be priced safely without a deeper forensic read.

Choose rescue when the current system cannot be made legible

Choose rescue when the production-critical core cannot be isolated and hardened without repeatedly destabilizing the product.

Strong rescue signals include:

• the live system cannot be reproduced from the owned repository
• roles and data access are enforced differently across screens, endpoints, and database queries
• billing state cannot be reconciled from trusted server-side evidence
• schema changes have no repeatable migration path
• a small change repeatedly breaks unrelated parts of the core workflow
• secrets or privileged operations cannot be separated from the client-facing application
• no engineer can define a safe rollback or data recovery path
• the company cannot grant a new senior engineer complete, revocable access to the system

Do not confuse a long codebase with a rescue case. A plain, imperfect repository with clear boundaries is often hardenable. The decisive issue is legibility: can a senior builder trace the critical path, state its invariants, verify a change, and deploy it safely?

DVNC's MVP Rescue starts with a forensic codebase read, keeps what works, and rewrites the production-critical core. DVNC's MVP Rescue scope includes auth, payments, the data model, tests, CI, clean deploys, and full code ownership in the buyer's GitHub. The point is a surgical rescue, not rebuild-shaming or feature expansion.

Return to the reference product. Its analysis interface and prompt work may be worth keeping. If workspace access, billing, and deployment are entangled, those foundations may need a controlled rewrite behind the working experience. That creates a stable core without paying to rediscover the product value the demo already proved.

The right verdict is deliberately unsentimental. Launch what has evidence. Harden what has sound boundaries. Rescue what cannot be made safe and legible through bounded fixes.

Frequently asked questions

Why did vibe coding fail?

Vibe coding usually fails at the production boundary, not at the first demo. Missing authorization, unclear state transitions, untested failure paths, and weak ownership make each new change less predictable until the core workflow cannot be trusted.

What are the dangers of vibe coding?

The main dangers are unverified access rules, exposed privileged credentials, incorrect billing state, regressions, unrecoverable data, and a codebase nobody can safely operate. Treat generated output as work to verify, not as evidence that the product is ready.

Is vibe coding dead?

No. It remains useful for exploration, prototypes, and bounded implementation. The handoff into production needs specifications, review, tests, deployment controls, and a named owner.

Is vibe coding bad for beginners?

It is useful for learning and making ideas concrete. It becomes risky when a beginner cannot inspect the generated behavior but still connects it to real identities, money, or sensitive data. Keep the early work isolated, then bring in review before production risk appears.

Scope the Rescue

Get a forensic read, keep what works, and rewrite only the production-critical core with clean ownership and handoff.