When to Move Off a Vibe Coding Platform: Six Signals the Ceiling Has Arrived

This is the signal that matters most, and Lovable documents it themselves. Their deployment documentation states plainly: "you cannot export user passwords, so you need to trigger a password reset flow. We recommend you plan the migration before onboarding real users." Read that carefully. The vendor, in its own docs, is telling you that the cheap window for leaving closes when you get real accounts. It is not a licensing restriction and it is not the vendor being difficult. Password hashes are held by the authentication service, and moving to a different authentication service means every existing user has to set a new password. Base44 has the same problem in a different shape. User rows come out as CSV, but the private authentication record behind each user does not, which means existing users cannot log in with their current credentials after a move. That claim comes from EscapeBase44, a vendor that sells Base44 migrations, though it is consistent with Base44's own documentation of what the CSV export contains. The practical consequence is a forced password reset email to your entire user base on the day you cut over. For a hundred internal users that is an inconvenience. For two thousand consumer signups it is a churn event, and a meaningful share of them will simply never come back. If you are pre-launch and even considering owning your stack later, that decision is cheapest to make now.

Base44's developer documentation states that "Base44 site hosting currently supports Single Page Applications (SPAs) only." If your app needs server-side rendering, that is a hard wall, not a configuration you have missed. This catches content-driven products in particular. A single page application ships an empty shell and fills it in with JavaScript after load, which is fine for a dashboard behind a login and poor for anything that needs to be crawled, indexed or summarised by search engines and AI answer engines. If organic search is part of how you expect people to find the product, the hosting model is working against the business model. Lovable is less restrictive here but has its own boundary. Its docs describe generated apps as "standard Vite + React projects built on open-source technologies", which is genuinely portable at the frontend. The limit sits at the backend: Lovable's documentation states that "migration to plain PostgreSQL or other database providers would require implementing equivalent authentication, storage, and edge services and is not supported out of the box." Lovable to Supabase is a supported path. Lovable to anything else is your engineering problem. The test to apply is simple. Write down the next three things on your product roadmap. If any of them requires server-side rendering, a background worker, a non-Supabase database, or running inside your own cloud account, the platform is now setting your roadmap rather than serving it.

On credit-based platforms, fixing a bug and generating a feature draw from the same balance, so an app that has started fighting you gets more expensive to keep alive every month. This is a structural property of the pricing model, not a complaint about the tool. Every AI action on Lovable consumes credits, whether that action generates something new, edits something existing, or attempts to repair something broken. Secondary review sites report the Pro tier at around US$25 a month (roughly A$38 at July 2026 rates) with a hundred credits included, though those figures are aggregator-reported rather than confirmed against Lovable's own pricing page, so treat them as indicative. What you can measure without any pricing data is the ratio in your own project. Over your last month of work, what share of your prompts were adding something a user asked for, and what share were repairing something that used to work? Early in a project that ratio sits heavily on the building side. The characteristic sign of the ceiling is that it inverts. Agencies that sell rescue work consistently report the same underlying cause: generated data structures are inflexible, so small feature requests require rewriting large sections of autogenerated code, and prompt coherence degrades as the project grows. Those are practitioner observations from commercially interested sources rather than measured findings, but they match what the credit ratio shows, and the ratio is yours to check.

If an enterprise customer, an insurer, a funding round or an Australian privacy obligation is about to put your app under review, the published evidence on vibe-coded application security is not on your side. This is the signal most likely to arrive as a deadline rather than a decision. Escape scanned more than 5,600 publicly available vibe-coded applications in October 2025, covering roughly 4,000 Lovable apps and 159 Base44 apps among others. They found 2,038 highly critical vulnerabilities, more than 400 exposed secrets, and 175 distinct instances of exposed personally identifiable information including bank account data. More than fifty tables accepted unauthenticated writes, including tables named payments, orders and transactions. Escape's own caveat is important and worth repeating: they scanned passively to stay within ethical bounds, so the findings "reflect only a subset of exploitable issues." CVE-2025-48757 documents the specific mechanism. Missing or insufficient Postgres row-level security policies on Supabase databases used by Lovable projects allowed anyone to read entire tables by inspecting network traffic and substituting a query. Matt Palmer's disclosure found 303 vulnerable endpoints across 170 websites, from examining homepages alone. Palmer worked in developer relations at Replit, a Lovable competitor, and said so openly in his disclosure. Lovable disputes the CVE on the grounds that customers accept responsibility for their own application data, which is a legitimate disagreement about shared responsibility rather than a denial of the finding. The general number is Veracode's 2025 GenAI Code Security Report, published on 30 July 2025. Across 80 coding tasks and more than 100 large language models, models chose an insecure implementation 45% of the time when a secure option was available.

Platform documentation publishes hard numbers, and hitting them is the least ambiguous signal on this list because there is nothing to interpret. You either fit inside the limit or you do not. Lovable's documented constraints include a 5 GB cap on database exports and one export per 24 hours, a 10 MB ceiling on files Lovable itself can save or edit, and GitHub's own 100 MB per-file push limit sitting behind that. There is also a documented data-loss trap: download your export and your storage files before removing Cloud from a project, because exports saved to Cloud storage stop being accessible afterwards. Base44 publishes a 5,000 items per request limit, effective 27 November 2025, and a 30 day retention window on deleted records before they are permanently removed and cannot be restored. The export limits deserve specific attention, because they compound. A single 24-hour export cycle is fine when your database is small and you are rehearsing a migration. It becomes a genuine scheduling constraint when your dataset approaches the cap and every rehearsal costs a day. Migration difficulty and dataset size move together, and so does the cost of getting a rehearsal wrong. One more limit is worth knowing because it surprises people mid-migration. Lovable environment variables prefixed with VITE_ are embedded at build time rather than read at runtime, so changing configuration between environments means rebuilding rather than restarting.

The reason to act on a signal early is that most of these costs are step functions rather than gradual slopes. The table below sets out what acting today costs against what the same work costs once the threshold has passed. | Signal | Cost of acting now | Cost of acting later | |---|---|---| | No real users yet | Rebuild auth against a clean user table, no external communication needed | Forced password reset for every user, plus the churn from people who never complete it | | Hosting model does not fit | Choose a rendering approach before you have written the pages | Rewrite the routing and rendering layer of a live app while it serves traffic | | Debugging is outspending building | Migrate a codebase you still understand | Migrate a codebase whose generated sections nobody, including the AI, can explain | | Security review is coming | Fix row-level security and rotate secrets on your own schedule | Fix them under a customer deadline, or after disclosure | | Dataset near the export cap | One clean export, room to rehearse the cutover twice | Export scheduling becomes the critical path, one attempt per 24 hours | | Files and automations in production | Rewrite a handful of storage URLs, rebuild two or three jobs | Trace every file reference and reconstruct undocumented automations from observed behaviour | The pattern across every row is the same. The work itself does not get harder. What changes is that it stops being reversible, because there is now a live user depending on the thing you are changing. This is also why "we will migrate when we outgrow it" tends not to survive contact with reality. By the time growth makes the case obvious, growth has also made the migration several times more expensive.

No independently measured breaking point exists for any of these platforms, and you should be suspicious of anyone who quotes you one. We looked specifically for a published user count, request rate or data volume at which vibe-coded apps stop working, and found none. What does exist is a large volume of content asserting thresholds, almost all of it published by agencies that sell rescue and migration work. Their claimed timelines follow the same shape: three to five days for a straightforward Lovable to Next.js migration with an experienced developer, two to three weeks without that experience. Those numbers come from companies selling exactly that service, and should be read as marketing rather than benchmarks. One widely repeated claim about traffic declines across these platforms traces to a single social media post with no stated methodology and no analytics source. We do not repeat it here for that reason. This matters for how you make the decision. Because there is no threshold number, the signals in this guide are all qualitative and all checkable against your own project. That is a feature. "Do we have real users with real passwords" is a question you can answer definitively today. "Are we approaching the scale where this breaks" is not, and anyone offering to answer it for you is guessing or selling. Our own position, stated as opinion rather than finding: the platform choice matters far less than whether you can leave it on your own timetable. An app on Lovable with a clean Supabase schema and rotated secrets is in a better position than an app on owned infrastructure that nobody has audited.

One signal firing is a prompt to run an architecture review, not a prompt to start rewriting. Two or more firing at once is usually the point where the review turns into a plan with a date attached. The first concrete step is an inventory, and it is work you can do yourself in an afternoon. List every platform primitive the app actually depends on: each authentication provider, each storage bucket and its access policy, each scheduled job or automation, each third-party integration and its credentials, each backend function. This list is the real scope of any future migration, and it is almost always longer than founders expect. Second, check your export path before you need it, not on the day you need it. Run the export. Confirm what actually came out. The gap between what a platform's export produces and what your app requires to run is the entire migration, and it is much better discovered during a rehearsal than during a cutover. Third, separate the security question from the migration question. A vulnerable app moved to new infrastructure is still a vulnerable app in a new location. Row-level security policies, secrets sitting in client-side bundles and functions callable with a public key should be fixed where the app currently lives. If you decide to move, the sequencing matters as much as the destination. Auth first, security audit before anything moves, monitoring before cutover. We cover that order and the reasoning behind it in the migration architecture guide, and the platform-specific mechanics in the Lovable and Base44 guides.

Is there a user count at which I have to migrate? No published, independently measured threshold exists for any of these platforms. Every specific number circulating traces back to an agency selling migration work. The useful threshold is not a count at all, it is whether you have real user accounts with real passwords, because Lovable's own documentation confirms passwords cannot be exported and every user will need to reset. Does Lovable actually recommend migrating early? Its documentation states: "We recommend you plan the migration before onboarding real users." That is about the password export limit specifically, not a suggestion to leave the platform. Lovable's stated position is that you are never locked in and can export code, migrate data and self-host at any time, which is a more open posture than most competitors. Why is Base44 a harder case than Lovable? Base44's exported frontend still calls Base44 servers for every database read and every login through its SDK, and the CLI eject command creates a new Base44 backend with an empty database rather than freeing you from the platform. Lovable generates a standard Vite and React project on a Supabase-compatible backend, so the portable path is documented. Can I stay on the platform and just fix the security issues? Often yes, and that is frequently the right first move. Row-level security policies, exposed secrets in client bundles and publicly callable functions can all be corrected in place. Escape's October 2025 scan found 2,038 highly critical vulnerabilities across 5,600 applications, and the majority of those are configuration problems rather than platform problems. What if I have already onboarded users and missed the cheap window? You plan for the reset rather than trying to avoid it. That means timing the cutover for a low-traffic period, writing the reset email before migration day rather than during it, and warning users in advance so the email reads as expected rather than as a phishing attempt. The cost is real but it is a one-off.