Custom software. Lovable to production
The app you built in Lovable, ready to run a business on.
Lovable gets a working app on the screen fast. Running a company on it is a different job. We move the app into accounts in your company's name, close the security gaps prototypes usually ship with, and set it up so the next change can't quietly break the last one.
The problem
Why do Lovable apps stall before production?
Because the part Lovable makes easy was never the hard part. A prototype has to work once, for the person who built it. A system a business runs on has to keep working for everyone, with real customer data in it, while somebody keeps changing it.
That gap shows up the same way every time. Each new prompt fixes one thing and quietly moves another, and there are no tests to catch it. Nobody is sure who can see which records. The app lives in a builder's or a freelancer's account, and the one person who understands it is the one who prompted it into existence.
None of that means the app was a mistake. It means it worked well enough to matter, and now it needs what any production system needs.
What we check first
What does a Lovable app need before a business depends on it?
The same six things, every time, and you get the findings in writing.
Secrets
API keys, passwords and tokens found anywhere in the code get moved into a secrets store, and any that were exposed get replaced with new ones.
Database access rules
Every table gets row-level access rules, so the database itself refuses to hand one user another user's records, whatever the screens ask for.
Server functions
Each function that touches data or money checks who is calling it before it does anything.
Ownership
Code repository, database, hosting, domain and email, each in your company's name. Not the builder's, not a freelancer's, not ours.
Backups
Automatic backups switched on and checked, so a bad day has a way back.
Tests and a second environment
Tests on the parts the business depends on, and a separate copy to try changes in, so the next change cannot quietly break the last one.
From the record
What did we find the last time?
A client came to us with an app a previous vendor had built in Lovable. It worked, and the business had come to rely on it. Moving it into accounts in the client's own name, we found API keys written straight into the code instead of being kept as secrets. They were found and fixed as part of the move, and the app now runs on infrastructure the client owns.
Our own tooling works the same way. It refuses to accept a secret pasted into a chat and tells the developer to replace the key instead, because a key that has been pasted somewhere has to be treated as seen.
When not to
When should you leave it in Lovable?
When nothing depends on it yet. If the app is still proving an idea, keep prompting and find out whether the idea holds. Hardening something nobody uses is money spent too early.
This is also work for companies, not side projects. If your team is under 20 people, we're probably not the right fit, and the training guides cover what you can safely do yourself. If the app does something a system you already own could do, we'll say so before we suggest building anything.
Questions
What people ask about taking a Lovable app to production
Security first, because that's the question that matters most here.
Is our Lovable app secure?
Possibly, but nobody can tell from the screens. The gaps we find most often sit underneath them. Database tables with no row-level access rules, so a signed-in user can read rows that belong to someone else. API keys and other secrets written into the code instead of kept in a secrets store. Server functions that do their work without checking who asked. Each of those gets checked before anything else happens, and you get the list in writing whether or not you go ahead with us.
Do you rewrite the app from scratch?
Not by default. Most of what Lovable generates is ordinary React on the front and Supabase underneath, which any capable developer can read and work on. We keep what holds up, fix what doesn't, and rewrite only the parts that can't be made safe or maintainable. If the honest answer is that a rebuild costs less than the repairs, you'll hear that on the first call rather than halfway through.
What does moving off Lovable Cloud involve?
Lovable Cloud runs your database, user accounts, file storage and server functions on infrastructure under Lovable's account. Moving it means standing up a Supabase project in your company's name and bringing all of that across. The tables and their data, the user accounts, the stored files, the server functions and the secrets they use. The aim is that your users sign in the next morning with the same password and never notice the move.
Our freelancer or previous vendor built it in their account. Can you get it out?
Usually, and the first step is always the same. Get admin access to everything the app runs on, which is the Lovable project, the code repository, the database and the domain. Code can be exported or transferred, and a Supabase project can be moved to another organization. Where the account holder won't cooperate it gets harder but rarely impossible, because whoever controls the domain and the data can rebuild around them.
Can we keep prototyping in Lovable afterwards?
Yes, for new ideas. The production system lives in your own repository and accounts, and changes to it go through review and tests before they reach your users. Prototype the next screen wherever is fastest, then bring it into the real system the same careful way.
What does it cost?
It's scoped after we've looked at the code, so there's no figure to publish here. What moves it is how much the app does, how many systems it talks to, how much data has to come across, and what the security review turns up. You get a written scope naming every piece of work before anything is signed.
Who maintains it afterwards?
Whoever you choose. The code is written and documented so any capable developer can pick it up, and every account it runs on is in your company's name with us invited in as administrators you can remove. An optional support plan is there if you want us to stay close. Nothing about the setup ties you to us.
What do you need from us to start?
Read access to the Lovable project and the code repository, a list of who uses the app and for what, and twenty minutes with whoever knows which parts the business depends on. From that we can tell you what you have, what's at risk, and what the move involves.
What is your Lovable app doing for the business?
Book a strategy call, or send a short note about the app, who uses it, and what worries you about it.