Can I launch a vibe coded app?

You can launch a vibe coded app, but a successful deployment is not a launch decision. A URL, a working login and a payment button prove that the app runs under the conditions you tried. They do not prove that another customer cannot see the wrong record, that a failed payment can be recovered or that anyone will notice when an important email stops sending.

The right question is whether you have enough evidence for the type of release you are planning. A private demonstration needs very little. A controlled beta needs known users, close support and a way back. A public launch needs clear ownership, tested customer journeys, recovery and someone accountable after release.

The fact that an app was vibe coded does not decide the answer. AI assisted code can be fit for production, and conventionally written code can be a mess. The release decision should turn on the app, the data it holds and the evidence you have checked.

First decide what launch means

People use "launch" for three quite different events. Pick the one you are doing before you set the bar.

A beta is not a softer name for a public launch. If anyone can register, enter personal information and pay without speaking to you, the app is public in the ways that matter.

Being vibe coded is not the launch test

You do not need to prove whether every line came from Lovable, Bolt, Replit, Cursor, Claude Code or a developer. You need to prove that the result behaves properly.

If you inherited the app and do not know how it was built, Vibe Check can look for supported public builder fingerprints. Its result is attribution evidence, not a quality score. Our guide to spotting a vibe coded website explains why a missing fingerprint does not prove that people wrote the code by hand.

For the release itself, use a verification standard rather than a debate about authorship. OWASP ASVS provides requirements for checking web application security controls. You do not need to apply every requirement to a small internal tool, but the standard is a useful source for the controls your own launch gate should cover.

Use this launch gate

Treat each part below as a gate. A verbal assurance does not close it. Record the account, test, screenshot, log or person that supports the answer.

Ownership and control

• The business controls the domain, repository, hosting, database, email service and payment account used by the app.
• Recovery details for each critical account are current and stored somewhere the app cannot lock you out of.
• You know what happens if the builder account is suspended or the person who created the app leaves.
• You can export the source and data, or you have deliberately accepted and recorded the platform lock in.
• Billing alerts and renewal contacts go to a business controlled address.

An app is not ready for public customers if one freelancer's personal login is the only route to the database or domain.

Data and privacy

• You have listed the personal, financial and commercially sensitive information the app collects.
• Each field has a current purpose. The app does not collect extra information in case it becomes useful later.
• The privacy notice describes what the app really does, including the external services that receive information.
• Retention and deletion are defined and can be carried out.
• Production information is not copied into an AI prompt, test environment or support ticket without an approved reason and suitable controls.

The Australian Cyber Security Centre recommends that businesses create a register of personal data, limit what they collect and log access to it. That is useful launch work even when you need separate advice on whether the Privacy Act applies to your business.

Accounts and access

• Sign up, sign in, sign out and account recovery work as intended.
• Admin access is separate from an ordinary customer account and protected with multi factor authentication where the service supports it.
• A user can only read and change the records their role permits.
• Former staff and test users can be removed without damaging shared business access.
• Secrets and service credentials are not shipped to the browser when they belong on the server.

Broken access control usually needs an authenticated test. A public page that looks clean cannot prove that one signed in customer is isolated from another.

Recovery and rollback

• A recent backup exists for the information the business cannot recreate.
• Someone has restored that backup into a safe environment and confirmed that it works.
• The previous working release can be restored without rebuilding it from memory.
• DNS, hosting and database recovery do not depend on the failed app being available.
• Failed jobs and partial transactions can be found and corrected without editing production records blindly.

ACSC guidance says businesses should back up software and configuration as well as data, then test that restoration works. A green backup badge is useful. A completed restore test is evidence.

Monitoring and alerts

• Application errors reach a person who can act on them.
• Availability is checked from outside the hosting platform.
• Failed form submissions, emails, payments and background jobs are visible.
• Logs identify the event and account involved without recording passwords, tokens or unnecessary personal information.
• You have a routine for dependency updates and new vulnerability notices.

Monitoring is part of operating the app, not a task for the week after launch. Fast moving apps also need checks after changes. We cover that gap in our article on continuous testing for vibe coded apps.

Customer experience

• A person who did not build the app has completed every critical journey.
• The journeys work on a current mobile browser and desktop browser, with keyboard access and readable error messages.
• Forms prevent accidental duplicates and confirm whether information was accepted.
• Payments show the correct amount, currency, tax treatment and receipt before you invite customers to spend money.
• Empty states, unavailable services and expired links tell the user what happened and what to do next.
• The contact, privacy and support details shown in the app are current.

Test the awkward paths as well as the happy path. Cancel a payment. Use an expired reset link. Enter the wrong email address. Switch networks halfway through a form. A polished home screen tells you very little about these states.

Support and change control

• One person owns the release decision and another named route exists if that person is unavailable.
• Users know where to report a problem and when they can expect a response.
• Hosting, database, email and payment provider support details are recorded outside the app.
• Changes can be traced to a release, reviewed and reversed.
• The team has agreed which defects stop a release and which can wait.

Do not launch on Friday afternoon if the only person who understands the app is going offline for the weekend. That is an operating decision, not a technical one.

Choose launch, beta or pause

The gate should end in a decision that another person can understand.

A few small visual defects may be acceptable in a beta. Unknown access rules or an untested restore are not. The severity comes from what can happen, not how unfinished the screen looks.

What Vibe Scan can check before launch

Vibe Scan is the sensible first automated check for a public app. It retrieves the submitted public URL, its response material and up to eight JavaScript files declared on the same origin. It can also request the site HTTP root to check HTTPS enforcement, inspect the first declared source map it can retrieve and open a TLS connection to read certificate details. It then inspects the public evidence for selected secret patterns, browser side security signals, headers, cookies, transport and detectable library versions.

The report also tells you when bot protection, unavailable assets or analysis limits reduced coverage. That matters because an incomplete scan should not be read as a clean result.

Vibe Scan does not execute the app, sign in, submit forms, make a payment or actively probe application routes in its public mode. It cannot inspect your source repository, private infrastructure, database access rules, business logic, backup restoration or the separation between two customer accounts. Those limits are why it belongs near the start of the launch gate rather than at the end.

If the automated result needs interpretation, request the free app readiness assessment. A person reviews the public experience, responsive behaviour, accessibility, public form structure and error states that do not require a submission, performance, search visibility, public security signals and visible architecture. It is still a review of the public surface. It does not turn into source code access or a test of private account boundaries.

When the decision depends on code, authenticated workflows or infrastructure, use a vibe code audit. If the blockers are already known and the app needs repair rather than another report, fix the app.

Copy this launch record

Keep one record with the release. It does not need to become a policy document.

APP LAUNCH RECORD

Application
Public URL
Release owner
Support owner
Release type  [ demonstration / controlled beta / public launch ]
Decision      [ launch / beta / pause ]
Decision date
Next review date

EVIDENCE CHECKED
[ ] Business controls the critical accounts
[ ] Data collected, purpose and retention are recorded
[ ] Account roles and customer separation have been tested
[ ] Backup restoration has been completed
[ ] Rollback has been tested
[ ] Errors, failed jobs and availability reach an owner
[ ] Critical customer journeys pass on mobile and desktop
[ ] Support route and response owner are confirmed
[ ] Public scan completed and its coverage limits were reviewed

BLOCKING ISSUES


KNOWN LIMITS ACCEPTED FOR THIS RELEASE


ROLLBACK TRIGGER


APPROVED BY

Update the record when a release changes authentication, data handling, payments, infrastructure or a critical customer journey. Keeping the old evidence beside the new release only creates false confidence.

Questions before release

Can I launch an app built with Lovable, Bolt or Replit?

Yes, provided the released app has evidence behind the controls that matter for its users and data. The builder does not decide whether the app is ready. The implementation and operating arrangements do.

Does a quiet Vibe Scan mean the app is safe?

No. It means the automated scan did not find a problem in the public signals it checked. Access between signed in users, server side behaviour, source code and private infrastructure remain outside that result.

Can I launch a beta without a code audit?

Sometimes. Restrict access to named users, limit the information and consequences involved, stay close to users and record the unanswered questions. A beta that anyone can join, pay for and trust with personal information is a public release in practice.

When does a vibe coded app need a deeper audit?

Use a deeper audit when the release decision depends on customer isolation, administrator permissions, payment logic, sensitive information, private infrastructure or code you cannot explain. Those questions cannot be settled from a public page alone.

The practical answer

Yes, you can launch a vibe coded app. Launch it as a controlled beta when the core journey works but the operating evidence is still thin. Make it public when the customer facing risks have been checked and someone owns the result. Pause when control, access or recovery is still an assumption.

Start with Vibe Scan if the app is already available at a public URL. Use the result as one piece of the launch record, then close the private and operational gates that no public scanner can see.