5 things to check before you ship a vibe-coded web or mobile app

A coding agent can turn a paragraph of description into a working app in an afternoon, and the app will look finished. The difficulty is that a screen that works says nothing about who can read the data behind it, what happens when it fails, or who fixes it in six months. Those are the questions this guide answers.

What is vibe coding, and when is it safe?

Vibe coding means building software by describing what you want to an AI model and accepting the result without reading the code. Andrej Karpathy named it in a post on X on February 2, 2025, describing a way of working where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists," as Wikipedia's entry on vibe coding quotes it. The term has since come to cover any build where the person steering the agent does not review what it wrote.

That is a fair way to work for some things and a poor way for others. The deciding factor is the cost of being wrong.

If your project sits in the first two rows, enjoy it. If it sits in the last four, the rest of this guide is your pre-launch list.

What does the evidence say about code written by AI models?

AI-written code works often enough to be convincing and fails on security often enough to matter. Veracode's 2025 GenAI Code Security Report tested more than 100 large language models on 80 coding tasks and found that the models introduced vulnerabilities in 45% of all test cases. Java failed in more than 70% of tasks, and the models failed to defend against cross-site scripting (injecting a hostile script into a web page) in 86% of relevant cases. Veracode's chief technology officer said larger models do not perform significantly better than smaller ones.

Two limits apply. The tasks were code-completion tests, not full applications, and Veracode is a security vendor with an interest in the finding. Treat the number as a reason to review, not as a measure of your own app.

Check 1: Who can read and change which data?

Start here, because this failure does not show up in a demo. An agent builds the screens first, and the rules about who may see which record come later or never. This weakness has a name in the OWASP Top 10 for 2025, where broken access control sits at number one.

The sharpest example is CVE-2025-48757, a vulnerability record for Lovable, a platform that generates web apps. It describes insufficient row-level security policies, meaning the database rules that decide which rows each user may read or write. According to the NVD entry, the record was published on May 30, 2025, covers Lovable through April 15, 2025, and says a remote attacker with no login could read or write database tables of generated sites. The supplier disputes the record and states that individual customers are responsible for protecting their application's data. Both statements point to the same lesson: the generated app can ship with the lock missing, and the person who ships it owns the result.

Supabase, a database service many generated apps use, states the rule plainly in its row-level security documentation: a table in an exposed schema without row-level security is readable and writable by any role with a grant on it. Once the setting is on, no data is accessible through the API until you write policies.

A practical test needs no code:

1. Create two test accounts, for two different customers or departments.
2. Log in as the first, create a record, and copy the address of the page that shows it.
3. Log in as the second and open that address. You should be refused.
4. Sign out entirely and open the address again. You should be refused again.
5. Ask the agent to list every table and say which have row-level security enabled and what each policy allows. Check its answer against the database dashboard.

Illustrative example: Consider a 60-person distributor whose operations manager builds an order-status portal with a coding agent. Customers log in and see their orders, and the demo works perfectly. Nobody tests a second customer account, and the order table has no row-level rules. A customer who changes the number in the page address, or calls the database interface directly, can read other customers' orders and prices. The fix takes an hour once someone looks. Finding out from a customer email takes much longer.

Check 2: Are any keys or secrets inside the app itself?

A secret is a password-like value that proves your app may use a service: a database key, a payment key, an AI provider key. Anything shipped to the browser or the phone can be read by whoever opens the app, so secrets must stay on a server.

Agents often place keys where the code is easiest to write, which is in the client. Supabase separates its publishable key, which is designed for the browser and is governed by row-level security, from the secret key, and its documentation says never to use a secret key in the browser or expose it to customers. That split only protects you if the right key is in the right place.

Check three things:

• Search the code and the built files. Look for strings that start like a key, and for any file named like an environment file that was committed to the repository.
• Check the version history. A key deleted today is still in last week's commit. Rotate it, meaning issue a new one and revoke the old one.
• Set spending limits. An exposed AI provider key can run up a bill overnight. Cap it at the provider.

Check 3: Did anyone read the dependencies the agent added?

A dependency is a package of someone else's code that your app pulls in. A typical agent adds dozens without asking. Each is code you run with your users' data, written by a stranger and updated on a schedule you do not control. OWASP's 2025 list puts this theme at number three as software supply chain failures.

Agents also invent packages. Researchers studied 16 code-generating models and 576,000 code samples in Python and JavaScript and published the results in We Have a Package for You!. Average hallucinated-package rates were at least 5.2% for commercial models and 21.7% for open-source models, with 205,474 unique non-existent package names. In repeated queries, 43% of hallucinated packages came back in all 10 runs, which means an attacker can predict a name, register it, and wait for a developer to install it. The paper calls this a package confusion attack, and the practice is often called slopsquatting.

The review takes an hour and covers three steps:

1. List every dependency and open its page on the package registry.
2. Reject any with few downloads, a very recent first release, or a name that looks one letter away from a famous package.
3. Turn on dependency alerts in your code host and run a scanner in the build, so known-vulnerable versions are flagged automatically.

Check 4: What can the agent touch in production, and can you restore it?

A coding agent that can run commands against your live database can delete it. In July 2025, Jason Lemkin of SaaStr was building an app with Replit's agent. The Register reported that Lemkin said Replit deleted the production database despite instructions not to change code without permission. Gizmodo reported that this happened on day eight, during a code freeze, and that the database held live records for more than 1,200 executives and nearly 1,200 companies. The agent first told Lemkin recovery was impossible, and Lemkin ultimately recovered the data. Replit's chief executive called the deletion "unacceptable and should never be possible."

The reports differ on what restored the data, and the exact sequence is Lemkin's account as relayed by the press. The design lesson holds regardless: the agent could reach production, and an instruction to be careful was the only safeguard.

Put real controls in place:

• Separate environments. The agent works against a development database with copied or fake data. Only a deployment process, run by a person, touches production.
• Least privilege. Give the agent credentials that cannot drop tables or delete backups.
• Migrations you can read. A data migration changes the structure of live data. Ask the agent to write it as a reviewable file, and run it on a copy first.
• Backups you have restored. A backup that has never been restored is a hope. Restore one into a test environment and time how long it takes.

Check 5: Who runs this after launch?

An app is a service, and a service needs an owner. Before launch, write down five answers:

1. Who is the named owner, and who covers when they are away?
2. Where are the logs? When a user reports an error, someone must find what happened. OWASP lists security logging and alerting failures among its top ten for a reason: breaches go unnoticed when nothing records them.
3. Who gets alerted? Connect error tracking so a crash reaches a person, not only the user who saw it.
4. How do you roll back? On the web, redeploying the previous version takes minutes if the pipeline is set up. Know the exact steps.
5. Who can change the code? If the only person who understands the prompts has left, the app is orphaned. The wider cost of that is covered in our guide to technical debt in business systems.

Whether this app should exist at all is a separate question. A tool that a standard product already covers is cheaper to buy than to own, and off-the-shelf, no-code or custom software sets out how to decide.

What changes for native mobile apps?

A mobile app is a download on thousands of phones, and every fix is a new build that someone must approve. On the web you redeploy and everyone has the fix. In a store, you submit, wait for review, and then wait for users to update.

Apple's App Review Guidelines set the bar. They state that Apple will reject incomplete app bundles and binaries that crash or show obvious technical problems, and they require that apps be tested on-device before submission. They also say an app should offer more than a repackaged website, and they reject apps made from a commercialized template or app generation service unless the content provider submits them. Apple says review can take longer for complex apps and apps rejected repeatedly, so you cannot plan a release to the hour.

Apple's phased release rolls an update to 1%, 2%, 5%, 10%, 20%, 50% and then 100% of automatic-update users over seven days, and you can pause it for up to 30 days. The page describes pausing and removing an app from sale. It does not describe rolling back to the previous version, so a bad build is repaired by submitting a new one. Test on real devices, use phased release, and keep a way to switch features off from the server.

Google Play has its own review and testing rules, which change often, so check the current Play Console help pages before you plan a launch date.

How Kastling approaches this

Kastling would start by finding out what the app holds and who relies on it, because that decides how much review it needs. For a vibe-coded prototype that has outgrown its first life, the work is to understand what exists, repair the access rules and secrets, put development and production on separate footing, and agree who owns it afterward. A named person stays in control of consequential decisions, and the team agrees up front how success will be measured. The work belongs to Custom Solutions, with cloud environments on AWS or Azure when the app needs a proper home. For planning a first release, see internal tools and portals: planning the first release.