I don't think an app built by AI is properly handed over just because there's a download button. Until somebody else can keep it running, you've got the files and an unresolved question about the business.
AI app builders such as Lovable and Bolt let you turn a description into software, rather than starting by writing the code yourself. That's a useful change for a founder with a small, specific problem. My objection isn't to making the first version easier. It's to treating the first version as the end of the difficult bit.
The demonstration I'd find more convincing isn't another app appearing from a clever prompt. It's a different person taking charge of it without needing the original builder to explain where everything lives.
Less applause, admittedly. Nobody's standing on a conference stage saying, "And now, watch Margaret reset a customer's password after we've changed providers."
I'd quite like to see Margaret's demo.
The download isn't the whole app
Lovable gives you ownership of the apps, code and content you create, subject to third-party rights. It also lets you keep the code in a separate repository, essentially a controlled store of the source files, through its sync tools. That's a meaningful route out, not just a reassuring sentence in a sales pitch.
But the code export doesn't include the records in your database or the files in storage. Those move separately. The services handling sign-ins, uploaded documents and AI features also need to be kept, reconfigured or replaced when you move.
That's the distinction I'd put in front of a non-technical founder. Owning the instructions for the machine isn't the same as having every working part in your possession.
Bolt offers a downloadable project too. Its documentation also makes a useful distinction about duplicating a project inside Bolt: with a Bolt database, the copy gets the database's structure, but not the data itself. That's a duplication rule, not a claim that Bolt prevents you moving your data. It does illustrate why the word "copy" deserves a follow-up question.
Imagine a simple quoting app for a supplier. A customer enters their requirements, uploads a drawing and returns later to check the quote. Moving the attractive page is only part of the job. The customer still needs to sign in, the drawing needs to be there, and the quote needs to survive.
If those bits don't come with it, you've successfully relocated the shop window. The shop is having a more complicated morning.
Who benefits when nobody wants to move?
I assume "you can leave whenever you like" is the version somebody paid for. The useful question is what leaving actually involves.
Call me cynical, but a company selling the builder, hosting and connected services has a perfectly ordinary commercial interest in keeping them together. Lovable's guide makes the billing boundary explicit: exporting code or changing a domain doesn't cancel anything. Services you continue using can continue costing you money.
That isn't evidence of a trap. It's evidence that a download and a cancellation are different events. I'd rather a supplier spell that out than pretend the exit consists of pressing a large friendly button.
There's genuine value in paying somebody to handle the machinery. Lovable's ownership guide lists what becomes your responsibility when you leave its managed setup, including operating the infrastructure, backups, access controls and external integrations.
Congratulations, you own the code. You're now head of IT. You can complain to the managing director, but he's already on hold with the hosting company.
My judgement is that convenience is worth paying for when you understand what you're buying. It becomes expensive when you mistake the absence of visible maintenance for the absence of maintenance.
Show me the handover
I don't think a founder needs to learn software engineering to judge this. The useful test is a small handover exercise, not a certificate in sounding technical during meetings.
For an app that's becoming important to the business, I'd want a competent person other than its original builder to run a separate copy, using safely chosen test data. Can a user sign in? Can they retrieve a record, change it and upload a file? Which services still depend on the original provider? Who controls the accounts, and who's responsible when something breaks?
These aren't exotic demands. Lovable's own migration guide includes testing sign-in, reading and writing data, and uploads before switching traffic. The sensible test is already in the instructions. It just lacks the cinematic appeal of watching a chatbot produce a dashboard.
Nor does passing it mean you should move. Staying with a managed platform can be the entirely sensible choice. I'd simply distinguish choosing to stay from discovering that nobody can explain how to leave.
My guess is there's room for a useful business in independent handovers: checking what an AI-built app depends on, proving it can run elsewhere and making the responsibilities understandable. Not another presentation about how quickly software can appear. Someone willing to find out whether it can survive its creator's absence.
The impressive demo builds the app. The valuable handover proves the business can live without the demo.
Who's going to make that boring bit a good business?