You built an app using Lovable, Bolt, Replit, Cursor, or another AI coding tool and started getting real users. Now problems keep showing up. You fix one issue with AI, another feature stops working, and after a few rounds of prompts, you are searching, “my vibe coded app is broken.”
Nine symptoms, sorted by where to start
Hover or tap a symptom to see what it usually is and the first step.
You probably do not need to start over. A login, payment, or deployment problem might only need a specific fix. If bugs keep returning or one change keeps breaking another feature, the problem may go deeper into the code, security, or architecture.
Before making more changes, back up the code and database. Then find out what is actually broken, check for security issues, and decide which parts need to be fixed, refactored, or replaced.
This guide covers that process, from diagnosing the app and closing security gaps to deciding whether to repair or rebuild it. It also covers the cost of fixing a vibe-coded app and how to keep using AI without risking the working version.
Why Vibe-Coded Apps Break Once Real Users Arrive
When you develop an app with artificial intelligence, you usually work on one feature at a time. You configure the login, add payments, connect the database, and move on. You test each feature as you build it. The app looks fine, so you launch it.
Real users start doing things you did not test. A wrong number is entered. A payment fails halfway through. A session expires. Several users try to update data at the same time. Bugs that were hard to find in development become apparent in production.
More users also mean more data and more requests. In initial testing, a slow database query may not be a problem. It becomes a problem as traffic increases. It can be made worse by missing indexes and inefficient queries.
There's the code, too. You might have tried changing the same feature multiple times using AI. New code is added, old code remains, and similar logic is in different files. Then you modify one of those files, and another feature stops working.
Without tests and error tracking, you often find these problems after users report them. It was a first version of the app. Now it requires checks and code changes for a real product.
What to Do Before You Change Anything
Before you try another fix, protect the version you have now. More changes can make it harder to find the original problem.
- Stop prompting the AI to make changes. Do not keep adding fixes while you are still trying to understand the problem. Each new change gives you more code to check.
- Save a copy of everything. Push the current code to Git and export a copy of the project if your builder supports it. Back up the database and any important uploaded files before changing the code or data.
- Restore the last working version if users are affected. If you have a stable version that worked before the problem started, roll back to it when it is safe to do so. Tell users about the issue if it is affecting login, payments, data, or another important part of the app.
- Check whether the problem is outside your code. Check the builder's status page and review your account, usage, and credit limits. A platform outage or exhausted usage limit can look like a problem in your app.
- Replace exposed secrets. If an API key, database password, or other private credential was placed in public code or a repository, revoke it and create a new one. Removing the value from the latest file is not enough if the old credential has already been exposed.
Not sure what you're looking at? Book a free 30-minute call.
Diagnose the Problem: Match the Symptom to the Fix
Start with the problem you can see. Some issues come from a wrong setting or missing key. Others need a closer look at the code, database, or security setup.
| What you see | What it usually is | Quick fix or needs a code review |
|---|---|---|
| The app works in preview but fails after going live | Missing environment variables, hard-coded URLs, or different production settings | Check the settings first. Compare the preview and production environment variables and URLs. If they are correct, review the code. |
| One user can see another user's data | Missing or incorrect Supabase Row Level Security policies, Firebase Security Rules, or authorization checks | Needs an urgent security review. Check who has access to each data type. |
| Customers cannot log in or keep getting logged out | Auth settings, session configuration, redirect URLs, cookies, or token refresh problems | Check the auth settings first. If the settings are correct, review the login and session code. |
| Payments start but do not complete | Wrong Stripe keys, test/live mode problems, failed webhooks, or errors in the payment flow | Check Stripe settings and webhook logs first. Review the payment code if Stripe sends the event, but the app doesn't process it. |
| The app becomes slow as traffic or data grows | Slow or unindexed database queries, repeated API requests, or missing caching where the same data is requested often | Needs a performance review. Find the slow query or request before changing the code. |
| A feature works for some users but fails for others | Permission rules, missing data, different account states, or code that expects every user to have the same data | Check the affected accounts first. Review the code and data if there is no clear account-level cause. |
| Every AI edit breaks something else | No automated tests, duplicated logic, or code that is too tightly connected | Needs a code review. Find the shared code and add tests before making more changes. |
| The same bug keeps coming back | The previous change fixed the visible problem but not its cause, or there is no test to catch the bug when it returns | Needs a code review and a regression test. |
| The app works, but nobody wants to change it | Technical debt: the code is hard to understand, important parts depend on each other, and there are few tests or clear notes | Needs a technical review. Some parts may need refactoring before you add more features. |
The Security Holes to Close First
Security problems need attention before you add more features. Start with the parts that control access to your data, APIs, and external services. Here are the main security problems to check first. A professional fix usually follows these five steps.
Five steps of a professional fix
Hover or tap a step to see what it covers.
Exposed API Keys and Secrets in Front-End Code or Repositories
Private API keys, database passwords, and access tokens do not belong in frontend code. Anyone using the app can inspect the code sent to their browser.
Keep private credentials on the server. If a private key was exposed in a public repository or frontend code, replace it with a new one. Removing the key from the code does not stop someone from using the old value.
Some keys are meant to be public. Supabase publishable keys are used in front-end data access with Row Level Security to control access to data. Supabase states that its secret and service-role keys must not be exposed because they have elevated access and bypass RLS.
Firebase API keys used for Firebase services are also public by design. They identify the Firebase project; they do not authorize access to its data. Firebase uses Security Rules, IAM, and App Check for access and protection.
Missing Database Access Controls in Supabase and Firebase
A logged-in user should only reach the data they are allowed to use. Supabase uses Row Level Security (RLS) to control access to rows in database tables exposed through its Data API. You set policies for what different users can read, create, update, or delete. For instance, a customer looking at orders should only see the orders they are allowed to see.
Supabase secret and service-role keys have higher access and bypass RLS. Use them only in trusted backend code.
Firebase uses Security Rules to protect Firestore, Realtime Database, and Cloud Storage. Open rules used during development should not remain in production. Firebase also provides App Check to help block requests from unauthorized clients.
Test these rules with different user accounts before launch. Hiding data in the interface does not protect the data itself.
API Endpoints Without Proper Authorization
Being logged in does not give a user permission to perform every action in the app. The server still needs to check what that user is allowed to do.
Consider an API that returns an order by ID. Changing the ID in the request should not give a customer access to someone else's order. The server needs to check that the user has permission to access that order. OWASP calls this Broken Object Level Authorization (BOLA) and lists it as the first risk in its 2023 API Security Top 10.
Missing Input Validation and Sanitization
Do not rely only on form rules. Someone can send a request directly to your API without using the form.
Check incoming data on the server. Confirm the expected type, format, length, and range where they apply. File uploads also need rules for the files your app accepts.
User input needs the right protection for where it goes next. Use parameterized queries for database queries and safe output encoding when displaying user content as HTML. Do not try to solve every input problem with one general sanitization function.
Outdated Dependencies and Known Security Vulnerabilities
Most apps use third-party packages for authentication, payments, database access, and the user interface. Security problems can occur in specific versions of these packages.
Check the versions your app uses against known security advisories. JavaScript projects can use npm audit to find known vulnerabilities in installed dependencies.
Do not update every package just because a newer version exists. Start with known security problems. Test the app after an important dependency update because a new version may also change how existing code works.
How a Professional Vibe-Coded App Fix Works
Fixing a vibe-coded app starts with understanding the code you already have. A developer first finds what is broken, what is unsafe, and what is still good enough to keep. The work then moves from the most urgent problems to the code and setup needed for future releases.
Step 1: Code and Security Audit
The first step is to review the code, database, authentication, APIs, dependencies, and production setup. The developer looks for security gaps, broken logic, duplicated code, weak database rules, and areas where one change is likely to affect another.
The founder should get a clear list of findings, ranked by severity. Each area should also have a recommendation: keep it, refactor it, or replace it. This gives the team a repair plan before development starts.
This matches the Discover and Architect part of CodingCrafts' process, where the team reviews the existing system, technical constraints, and architecture before deciding what work comes next.
Step 2: Stabilize
The next job is to stop the problems that put users or data at risk. Replace exposed secrets, fix authentication issues, and tighten database access rules.
Error logging and uptime monitoring if they are missing. These tools show when the app fails and give developers information they can use to trace the problem.
Step 3: Refactor the Riskiest Code and Add Tests
Once the app is stable, developers work on the code that causes the most problems. They may split large functions, remove duplicated logic, or clean up code shared by several features.
Tests are added around the flows the business depends on, such as sign-up, login, payments, and other main actions. Regression tests check that a change has not broken something that already worked. CI runs these checks when new code is pushed or prepared for release.
This work fits the Build stage of our process, where development happens in short iterations with testing and regular review.
Step 4: Set Up Real Production Infrastructure
The app needs a safe place to test changes before customers receive them. Staging and production should be separate, with their own settings and secrets.
Set up the deployment process so releases follow the same steps each time. Backups give the team a recovery point, while a rollback process lets them return to a known working release if a deployment causes a serious problem.
GitHub, for example, supports separate staging and production environments, environment-specific secrets, deployment history, and protection rules before a release goes live.
Step 5: Handover
This is not the end of the process of work. The founder team must have enough information to operate and modify the app after the project ends.
The handover should include the codebase, architecture, deployment process, environments, backups, monitoring, and common production tasks. Runbooks provide the team with clear procedures for tasks like deploying a release, responding to an outage, or rolling back a bad deployment.
This connects with Ship & Scale in CodingCrafts' process. The application returns to production with monitoring, documentation, runbooks, and a clear handover, providing a stronger foundation for the next release.
Fix, Refactor, or Rebuild: Which Approach Is Right for Your Vibe-Coded App?
If a feature breaks, it doesn't necessarily mean you should rebuild the whole app. The decision depends on how deep the issue goes. Review the code, data model, security, tests, and required app changes.
| Option | Choose it when | Typical scope |
|---|---|---|
| Fix | One or two problems are causing trouble, but the rest of the app works as expected. | Repair the affected feature or configuration. This could mean fixing login, a payment flow, an API connection, a database query, or a deployment setting. |
| Refactor and harden | The app has real users and the main features work. The data model still makes sense, but the code is difficult to change, or there are few tests and security checks. | Keep the working parts. Clean up risky code, remove duplication, add tests, tighten security, and improve logging and deployment. |
| Partial or full rebuild | The main architecture or data model is causing problems, the current stack no longer fits what the product needs, or major security and compliance requirements would require large changes across the existing system. | Rebuild the affected layer or, when the problems run through most of the system, rebuild the application on a better foundation. |
Do a full rebuild after a technical review, not after the first serious bug. The Codebase may be crap, but the features still work, the Data Model is usable, and the Integrations are worthwhile. Companies that fix vibe-coded apps report a similar pattern: most projects require fixes or partial refactoring, but a complete rebuild is usually reserved for more serious underlying issues.
There is also a closer look at compliance. HIPAA does not require one specific technology stack. For organizations covered by the HIPAA Security Rule, the system needs appropriate safeguards for electronic protected health information, such as access controls, audit controls, authentication, and transmission security. A rebuild becomes relevant when it is not possible to meet those requirements without significant changes to the system when following the current design.
SOC 2 also does not require an app to use a specific framework or architecture. A SOC 2 audit examines controls applicable to specific areas, such as security, availability, processing integrity, confidentiality, or privacy. If the existing system cannot support the controls the company needs, parts of the system may need to be redesigned.
The code review should help you to understand which of the three routes fits the app. A simple way to think about the decision is:
Fix, refactor, or rebuild?
Hover or tap a route to see when to choose it and the typical scope.
How Much Does It Cost to Fix a Vibe-Coded App?
The cost depends on what is wrong with the app and how much of the existing code is still usable. A deployment failure or API failure is a smaller problem to solve than an authentication failure, database failure, payment failure, and unstable code throughout the entire application.
For context, Clutch reports that most custom software development projects under review run from $10,000 to $49,999, with an average project cost of about $132,480. These numbers apply to any software development project, not just repairs to vibe-coded apps, and cannot be used as a price window for this type of work.
If the issue is limited to a small number of areas, the repair project will cost much less. The price rises when developers need to review and change several parts of the application.
The main cost factors are:
- Condition of the existing code. A developer first needs to understand what the AI-generated code is doing. Duplicated logic, large files, unused code, and tightly connected features add more work.
- Number of problems. One broken integration takes less time to repair than problems spread across authentication, payments, APIs, and the database.
- Security work. Exposed secrets, weak database rules, missing authorization checks, and vulnerable dependencies need review and fixing before the app returns to production.
- Database changes. The work becomes more sensitive when the app already stores customer accounts, orders, transactions, or other production data. Developers need to protect that data while making changes.
- Third-party integrations. Stripe, Supabase, Firebase, CRMs, email services, and other connected systems need separate testing when the repair affects them.
- Missing tests. If there are no automated tests, developers need to understand the existing behavior and add tests around important flows before making larger changes.
- Production setup. Staging, monitoring, backups, deployment workflows, and rollback procedures add more work when the existing project lacks them.
- Security or compliance requirements. Products that work with sensitive or regulated data need stronger access controls, logging, security checks, and documentation.
It also helps to separate the technical audit from the repair itself. The audit provides a list of problematic areas in the app, which code can be retained, and what can be refactored or replaced. The development estimate then comes from those findings.
A small repair might only require changes to one feature or integration. A bigger project may require security fixes, code refactoring, tests, database work, and production setup. The cost starts to creep closer to a partial or full rebuild when most of the architecture needs to change.
Once a code and security audit has been conducted, set the full budget. This gives you a clearer vision and prevents you from spending money to rebuild components of your App that already work.
Finding the Right Developer to Fix Your Vibe-Coded App
An app developed with Lovable or Bolt does not require a developer to know the language. They need to understand the app's code and the services behind it.
Begin with a working codebase. The developer should check it before telling you to rebuild. They need to demonstrate how it is broken, how it is causing the problem, and what stays.
Check their experience with your stack. If the app involves React, Next.js, Supabase, Firebase, and Stripe, they need to be familiar with these tools and how they're used. For instance, a login problem might come from authentication settings or session logic. Payment issues may stem from the Stripe integration or the webhook code. These problems can not be solved by changing the interface.
They should also check the parts of the app that control data access. This includes authentication, user permissions, database rules, API access, secrets, and dependencies. OWASP's code review guidance covers these areas as part of a security review.
Testing is another thing to ask about. If there are no tests, the developer should add them around important flows before making major changes to the app. Good places to start include login, sign-up, payments, and vital data updates. Tests can show that a new modification causes something that was working to stop functioning. NIST's Secure Software Development Framework also recommends testing software and adding tests for previously found problems.
Developers should not make modifications directly from their machines to the live app. Discuss with them where and how changes will be tested and reviewed before release. GitHub features protected branches, automated checks, and pull request reviews to facilitate merging code into the repository's main branch.
When hiring a developer, ask:
- Will you review the current code before deciding what needs to be rebuilt?
- Have you worked with the technologies used in this app?
- How will you check authentication, permissions, database access, and secrets?
- Which parts of the app need tests before you start changing them?
- Where will you test changes before they go live?
- What documentation will I get when the work is finished?
If somebody tells you to rebuild the entire app without checking the code first, be careful. The same applies if their plan is simply to keep prompting an AI tool until the errors disappear. They should be able to explain the problem in the existing code and what they plan to change.
How to Keep Vibe Coding Without Breaking Production Again
You do not have to stop using artificial intelligence after your app is fixed. You require a more secure method to deploy AI-generated changes to production.
Avoid making all the changes in the live version. Create a separate Git branch for the feature or fix you are working on. If the change causes an issue, your production code is still available.
Test the change before merging it. Automated tests should focus on the application's essential areas, including login, sign-up, payments, permissions, and key data updates. These tests identify features that no longer function when AI changes the existing code.
On GitHub, you can protect the main branch by requiring reviews and status checks before merging pull requests.
Use staging or preview for the next check. Open the app there and see the actual flow. For example, a page may load fine, but the login, payment, webhook, or database update operations triggered from the page may fail.
Handle database changes with care. Avoid using an AI tool to make unmanaged changes to the production database. If you use migrations to manage your project's database schema, keep those changes in migration files and test them before deployment. Supabase recommends this workflow for teams using migrations. Supabase Branching also offers individual environments where teams can experiment with database or configuration changes before implementing them in production.
Some changes require more scrutiny than others. Authentication, user permissions, payments, database migrations, API access, and infrastructure can significantly affect critical parts of the application. Review the generated code and test the complete flow before releasing these changes.
Once the update is live, check what happens in production. Error tracking, logs, and uptime monitoring help detect failures that testing missed.
A safer workflow for AI-assisted changes
Hover or tap a step for details.
Vibe coding remains a rapid means to create and modify features. The difference is that artificial intelligence generates or modifies the code, while your development process determines if it is ready for production.
CodingCrafts’ Approach to Fixing Vibe-Coded Apps
At CodingCrafts, we start with the app you already have. Our engineers review the code, architecture, database, integrations, security, and production setup before deciding what needs to change.
We do not assume the whole app needs to be rebuilt. If the core product works, we keep what makes sense and focus on the problem areas. That could mean fixing a specific feature, refactoring unstable code, improving security, adding tests, or changing part of the architecture.
The work follows the same process we use for existing software projects. We first identify the problems, plan the technical changes, make and test them, and prepare the app for production. Code review, testing, monitoring, documentation, and handover are part of that work.
You also keep ownership of the code and documentation. When the project is handed over, your team has the information it needs to understand the app and continue working on it.
If your vibe-coded app keeps breaking or you are not sure whether to fix or rebuild it, contact us. We can review the existing app, identify the problems, and help you decide what to do next.
Is Your Vibe-Coded App Breaking in Production?
CodingCrafts starts with the app you have: we review the code, database, integrations, and security, then fix, refactor, or rebuild only what needs it. You keep the code and the documentation.