You can own your app. Can you leave your AI app builder?

Rédigé le 10/08/2026
Pierre-Laurent Medori

AI app builders have made starting an app almost free: describe it, and something clickable exists by dinner. The migration threads on r/nocode and r/lovable this summer are about the other end of the story, the part no demo shows. Here is what "you own your code" actually covers, what stays behind when you leave, and what owning your app should mean before you commit to a platform.


What does AI app builder lock-in actually look like?

The short version. Not what you would expect. The leading AI app builders genuinely let you export your code; as of August 2026, Lovable syncs to GitHub on every plan, including the free one, and its documentation states you are "never locked in". The lock-in lives elsewhere: in the managed backend your data sits in, in the hosting and authentication you would have to replace, in the AI editing loop that stays behind, and in the AI-written codebase you become solely responsible for the moment you walk. Owning the code was never the same thing as being able to leave.

Lock-in used to mean a simple thing: your work is trapped in a proprietary format, and the exit door is locked. AI app builders changed the shape of the problem. The door is open. The question is what fits through it.

An app is three different possessions wearing one name: the source code, the running system that serves real users, and the business the app carries. Export moves the first. It does not move the other two. The frustration running through this summer's migration threads comes from discovering that distinction late.


The migration threads tell the story better than any vendor

The first week of August 2026 put the question back on r/nocode. In a detailed post from August 4, a developer who handles these migrations describes moving a school-operations app, 189 database tables and 500 users, off Lovable's managed cloud and onto infrastructure the owner controls. The app worked. The problem was everything around it: the owner could not open his own database, could not hand the project to another developer, and could not answer basic security questions, because all of it lived inside the platform's managed backend. A commenter on the same thread, still on the platform, summed up daily life without direct database access: "you're asking a chatbot to be your psql."

The consultant's takeaway is the most useful sentence in the thread, and it applies to every platform, ours included: "if I needed to leave tomorrow, could I? Knowing the answer costs nothing. Finding out the hard way costs a lot."

The July threads on r/lovable are the backstory. One user, nine months and thousands of euros into a project, estimates that 30 to 40% of his spend went to fixing issues in the code the tool itself generated, writing that once a project gets complex, "Lovable loses its mind." A commenter on another thread describes sinking more than 3,000 credits into a single build and being stuck transitioning it to real production. A third user had 12 GB of data locked for four days by an automated moderation flag the vendor later acknowledged was a false positive; even after access was restored, the only export offered was downloading his tables one by one as CSV files, because the data lived in a hosted backend he had no direct access to.

Honesty requires the other side too. The same threads contain users who are staying put and see no reason to move ("Not moving from lovable .. why would I do that ?"), and they are not wrong: for validating an idea at prompt speed, these tools remain excellent. The pattern is not "the tools are bad." The pattern is that the pain concentrates at one precise moment: the day a prototype becomes a business and someone asks who actually holds it.


"You own your code" is true. It is not the same as "you can leave."

Lovable's export story is real, and it deserves to be stated precisely. As of August 2026, Lovable's documentation is explicit that you own the code you generate, and the company commits in writing to building the product so you are "never locked in"; its plan matrix lists Git sync, to GitHub or GitLab, on every plan, with a direct zip download on the paid ones. Bolt.new offers a full project download too, and Base44 exports code as a zip or syncs to GitHub on its Builder plan and above. On code portability, this generation of tools is genuinely open, and pretending otherwise would be false.

Now read what the export does not include, in the same docs. There is no one-click migration off Lovable Cloud, the built-in backend: leaving it means exporting your data and rebuilding the schema wherever you land. Hosting, custom domains, SSL and authentication are managed services that stay behind. So does the AI agent itself, the thing that wrote every line you now hold. When you stop using the platform, its documentation states plainly, infrastructure, deployment, databases, authentication, secrets and security compliance become your responsibility.

So what walks out the door with you? A React-based web codebase written at prompt speed, often by hundreds of prompts, and, as the threads above show, often never fully read by its owner. The export includes the source. It does not include a team that understands the source. The user who spent 30 to 40% of his budget fixing generated code was paying that tax with the AI still in the room. Alone, every fix costs developer hours instead of credits, and hours cost more.

The meter tells the same story. Lovable's plans measure usage in credits, from 100 per month at $25 on the entry paid tier as of August 2026, and complexity is what consumes them: every fix, every retry, every "try again" burns credits. Per the same documentation, when credits run out mid-cycle the editing loop is blocked and Cloud backend services can pause, though the published site stays up. Monthly credits also expire two months after they are issued, and rollover applies only while the subscription stays active. None of this is hidden; all of it points one way. The cost of staying grows with your app's complexity, and the cost of leaving does too.


Owning your app is three different things

Ask what "owning your app" means, layer by layer, and the comparison between an AI app builder and a platform like GoodBarber stops being one question with one answer. As of August 2026:

What you ownLovableGoodBarber
The source codeYours. Git sync on every plan; zip download on paid plans.Not provided. GoodBarber does not export source code; the engines are the platform's.
The running system (hosting, database, authentication, push)Platform-managed while you stay. If you leave: no one-click backend migration; you export data and rebuild.Platform-managed and included in the subscription, hosted in Europe. It is the platform's job, permanently.
The app in the storesWeb app. The store route is a PWA or wrapping the app with a tool like Capacitor, outside the platform.Native iOS (Swift) and Android (Kotlin) binaries under your brand in the App Store and Google Play, plus a PWA.
The business (brand, audience, customers, revenue)Yours.Yours: your brand, your subscriber base and push audience, your customer data, your e-commerce revenue at 0% GoodBarber commission (standard payment-processing fees apply).
Whoever fixes what breaksYou, in the exported code, or your credits, in the editor.GoodBarber, in the platform, as part of the subscription.

Facts, not verdicts, and the table cuts both ways. If a codebase a developer you hire can fork is a strategic requirement, an AI builder hands you that natively and GoodBarber does not. The two products are not hiding the same trade behind different marketing; they are making opposite trades in the open.


What you own with GoodBarber, and what we deliberately keep

GoodBarber does not sell you the code. We keep the machine: the Swift, Kotlin and PWA engines, the hosting, the database, the push infrastructure. That is not a limitation we hope you will not notice; it is the product. The subscription pays for the machine staying our problem, through OS updates, store policy changes and traffic spikes, for years. Apps built this way have been downloaded once every 4 seconds, for paying customers in 152 countries, on a platform that has been doing this since 2011.

What you own is everything the machine exists to produce. Your app, under your brand, in the App Store and Google Play as a real native binary. Your audience and the push channel to reach it. Your customer relationships and your prices, with 0% GoodBarber commission on mobile e-commerce sales. Your content, updated in real time without resubmitting to the stores. Your data, hosted exclusively in Europe. And you can still work by prompt: GoodBarber's AI layer, an MCP server plus 44 open-source Claude Skills, lets your AI assistant take on the app's daily work with you setting the policies and reviewing the results, which is a different job from building the app, and the one that actually lasts.

The economics follow the same logic. Plans are flat and public on the pricing page, with a 30-day free trial and no credit card: a native iOS and Android app runs €70/month for Content apps and €90/month for eCommerce apps, less on yearly billing, and a PWA-only tier starts at €36/month. Complexity does not raise the bill: debugging is not metered, because it is not your job. If you are weighing this against Lovable specifically, the feature-by-feature comparison goes through both platforms in detail.


So, can you leave GoodBarber?

You cannot take the engines or the source code with you: that is the same statement as "we do not sell the code," seen from the exit. The question deserves the same honesty we have applied to everyone else, so here is the rest of the answer. What you take is the business itself: your brand, your audience and its trust, your content, your product catalog (exportable via the Product Import/Export extension), your analytics history (CSV export), and a revenue stream GoodBarber never took a commission on.

Our real answer to the exit question is different in kind, though: we built the platform so the assets your business depends on are never the ones at stake. The layer you would fight to keep, the business, is yours on day one and stays yours. The layer we keep, the machine, is precisely the one you should not want to inherit. The migration stories above are all, in the end, about people inheriting a machine.

Run the consultant's test on us, on Lovable, on anyone: if I needed to leave tomorrow, could I, and what exactly would I be carrying? Any platform that resents the question is answering it.


The leave-tomorrow test, before you commit

Five questions to ask any app builder, AI or otherwise, while it still costs nothing:

  1. Can I open my own database today, without going through an AI or a dashboard?
  2. What exports exist, in what format, and does the backend travel or only the code?
  3. What happens to the price when the project gets complex? Flat plans absorb complexity; credit meters bill it.
  4. Is the mobile app a native binary in the stores, or a web app that still needs wrapping?
  5. If I stop paying tomorrow, what freezes first, and who do my users see it affect?

Start fast wherever starting fast is safe. Just run the test before the prototype becomes the business, because that is the day the answers get expensive.

And one more disclosure, because it is the kind we have demanded of everyone else in this article: moving to GoodBarber from an AI builder is a rebuild, not an import. You bring the idea, the content and the audience, and reconstruct the app in a structured back office. The 30-day free trial exists so you can find out exactly what that takes before it costs you anything.


FAQ

What is AI app builder lock-in?

With modern AI app builders, lock-in is rarely about code: as of August 2026, Lovable, Bolt.new and Base44 all offer code export. It is about everything the export does not carry: the managed backend holding your data, the hosting and authentication layer, the AI editing loop, and the working knowledge of an AI-generated codebase your team may never have fully read. You can leave with the source and still be unable to leave with the app.

Can you export your app from Lovable?

You can export the code: GitHub sync is available on every Lovable plan as of August 2026, and paid plans add a zip download. The backend is a different matter. Lovable's own documentation states there is no one-click migration off Lovable Cloud; you export your data and rebuild the schema wherever you land, then take over hosting, authentication, secrets and security yourself.

Is GoodBarber a Lovable alternative?

For different jobs. If you want a web prototype at prompt speed, or a codebase a developer can take over, Lovable does that natively and GoodBarber does not. If you want a native iOS and Android app in the stores, run for years through a structured back office, with hosting, database, push and payments included in a flat subscription, that is GoodBarber's job. We built the same app on both platforms to show the difference in practice.

Does GoodBarber let you export your source code?

No. GoodBarber does not provide source-code export; the compilation engines and infrastructure are the platform. What you own is the result and the business around it: your branded native app in the stores, your audience, your content, your product catalog (exportable via the Product Import/Export extension), your analytics (CSV export), and your e-commerce revenue at 0% GoodBarber commission.

What happens when your AI app builder credits run out?

On Lovable, per its documentation as of August 2026: the AI editing loop is blocked until credits are available, Cloud backend services can pause, and the published site stays live. Unused monthly credits roll over only while the subscription stays active, and expire two months after issue. The practical effect: the more complex your app, the more each fix costs, and pausing your subscription pauses your ability to change the app.

The prototype was the easy part. Owning what comes next is the point. Start your free 30-day trial: build your app, put your brand on it, and keep the machine our problem.