Back to blog
    Vibe Coding
    Cursor
    Lovable
    Bolt
    Replit
    Inteligencia Artificial
    Lanzamiento

    Vibe coding: what to do when your AI-built app gets stuck before launch

    You built something with Cursor, Lovable or Bolt and it almost works. Almost. Here's an honest map for spotting where you're stuck and how to break through.

    9 min
    Carlos Canelón
    Vibe coding: what to do when your AI-built app gets stuck before launch

    The pattern that keeps repeating

    Every week I talk to someone stuck in the same place. The story has variations, but the curve is always similar:

    1. You started building with Cursor, Lovable, Bolt, Replit or a mix of AI and hand-pasted code
    2. Within 48 hours you had something that looked like a product
    3. Each new prompt broke something that used to work
    4. The deploy to production revealed problems that never showed up locally
    5. You've been spinning in circles for three weeks and you don't know whether to patch, refactor or burn it down

    If you recognize yourself, you're not alone. This is called vibe coding: building fast on intuition and prompts, without a clear technical map. It works really well until you hit the final 20%.


    The four typical blockers

    1. The prompt loop

    You ask for a small change, the assistant rewrites parts you didn't ask it to touch. You fix that, another bug pops up somewhere else. The feeling is moving forward and backward at the same time.

    Why it happens: Models don't have a global view of your code. When they "help," they sometimes replace logic that already worked with a generic version that breaks real use cases.

    How to escape:

    • Use version control obsessively (git commit every time something works)
    • Reduce the scope of every prompt: "only change this file, don't touch the rest"
    • When the assistant rewrites without being asked, roll back with git reset before accepting

    2. The critical pieces almost work

    Login, payments, emails, third-party integrations, database permissions. They look ready in the demo. In production, with a real user, they break.

    Why it happens: These systems have details AI doesn't handle well by default:

    • Auth: state checks, token expiration, httpOnly and secure cookies, redirect handling
    • Stripe: webhook signature verification, test/live mode handling, duplicate event handling
    • Email: SPF/DKIM/DMARC, transactional vs marketing distinction, bounce handling
    • DB: row-level security, indexes, reversible migrations

    How to escape: These pieces don't get vibe-coded. They need human review with expert eyes. They're the final 20% that hurts the most.

    3. The deploy that works locally but breaks in production

    Misconfigured environment variables, build pipelines that don't replicate the local environment, dependencies behaving differently in serverless, cold-start times.

    Why it happens: Vercel, Render, Railway, Supabase and Firebase environments have subtly different behavior from local development. The AI assistant doesn't see them.

    How to escape:

    • Read the provider's actual logs, don't assume
    • Compare environment variables line by line between local and production
    • If you use Next.js: cleanly separate server-side from client-side
    • Deploy early and often, don't pile up changes without validating in production

    4. The "this isn't maintainable anymore" feeling

    The code grew fast, there are huge files, duplicated logic, inconsistent names, and you no longer understand what each part does. Every change scares you.

    Why it happens: AI optimizes for "make it work now," not "make it readable in 3 months." If you don't impose order, order doesn't appear.

    How to escape:

    • Don't rewrite everything, refactor in layers: first names and file structure, then logic
    • Add tests for the critical flows (auth, payments) before touching anything else
    • If it's too broken, honestly decide what's worth saving and what to replace

    Honest decisions: patch, refactor or rebuild

    There's no universal answer, but these are the criteria I use:

    Patch when:

    • The bug is local and isolated
    • The rest of the code is reasonably healthy
    • The product is already in production with users

    Refactor when:

    • There are 2 or 3 problem areas but the main idea works
    • You have time and aren't yet in production with many users
    • You spot a clear pattern that, repeated well, fixes most of it

    Rebuild from scratch only when:

    • The base stack is incompatible with what you need (e.g., building a multi-tenant SaaS on Firebase without thinking through auth from the start)
    • The code is unintelligible even to you
    • You'll spend more time fixing it than rebuilding cleanly

    Most stuck projects I see don't need a rebuild. They need a couple of weeks of expert hands unblocking specific pieces.


    What DOES work about vibe coding

    I don't want this to sound like an anti-AI rant. The reality is that building with Cursor, Lovable or Bolt gives you a superpower: brutal initial speed.

    What works:

    • Validating a product idea in days, not weeks
    • Building prototypes to get early feedback
    • Standing up landing pages, internal dashboards and non-critical tools
    • Staying in flow without fighting boilerplate

    What does NOT fully work:

    • Shipping to production with payments, sensitive data or many users without human review
    • Maintaining the code long-term without someone who understands what's underneath
    • Solving integration, deploy or security bugs purely by prompting

    The key is knowing where AI accelerates and where AI hides technical debt.


    If you're at this point right now

    If you've been stuck for weeks, requesting changes and watching each one bring a new one, consider these three options:

    Option 1: try again on your own Apply the advice above, commit to git discipline, reduce prompt scope, and give it 1-2 more weeks. Sometimes you just need to change the methodology.

    Option 2: ask for a quick review Have someone experienced look at your code for an hour and tell you objectively where you are, what can be saved and what should be replaced. A well-done review saves months.

    Option 3: work side by side with a senior dev Especially useful if your app is close to launch but the critical pieces (auth, payments, deploy) won't quite close. It's not delegating the project: it's having someone next to you while you stay in the driver's seat.

    For that third option I have a dedicated site: rescuevibe.dev. It's specifically built for builders who shipped something with AI and need senior dev help to get to production. Honest diagnosis first, focused sprint after if it's worth taking forward.


    Conclusion

    Getting stuck on an AI-built app isn't a sign you're doing something wrong. It's a sign you reached the point where vibe coding falls short and you need a different level of technical rigor.

    The good news: that final 20% that hurts so much has clear paths. You just have to recognize where you are, what specific blocker has you stopped, and what kind of help you need (if you need it).

    Your app can reach production. The question isn't whether it's possible, it's what's the shortest, most honest route to make it happen.

    Want to apply this to your business?

    Let's talk about how I can help you turn these ideas into results for your project.

    Share this article