What could you make with Lovable without choosing a separate backend?
Imagine a designer who wants clients to submit a brief, attach a PDF and return later to see its status. Lovable can build those screens, and Lovable Cloud can handle the accounts, files and saved records they depend on. The backend is the part doing that work out of sight.
You could start with a form and a confirmation, then add accounts when clients need to come back. If all you need is an email when a brief comes in, that’s a smaller app. Decide what clients need to do next before asking for a portal.
What should you put in the first request for a client portal?
Describe what the client should get at the end: “Let a client submit a project brief and see a confirmation with the project name. Keep the brief after they close the page. Use sample information while we try it.”
Try it in the preview, the working copy you see while editing. Make sure it uses disposable data and won’t send anything to real clients. Close it and come back. If the brief has vanished, ask whether the page was showing examples or actually saving the form. Add uploads or progress updates after you can find the brief again.
Where does Lovable keep private briefs and files?
With Lovable Cloud, the database holds the brief and file storage holds the PDF. Sign-in identifies the client. You still need access rules to say which client can read which brief or download which file.
Try using two accounts. Sign in as the second client and ask the app for the first client’s file. It should refuse to give them the file or a new download link. A link that was already created for the first client may keep working for whoever holds it until it expires; check how your app issues and shares those links.
Also inspect what Lovable can change without asking. Its permission settings cover supported operations, and some changes to data are allowed automatically by default. Review those before connecting anything you can’t afford to lose.
Can customers see your next edit as soon as you make it?
No. Publish puts a version at a web address. Use Publish changes when you want customers to get a later edit. A paid plan is required to connect your own domain, such as yourbusiness.com.
Before you submit anything at the published address, check which records, emails and files it can touch. Try a sample brief in a test project you control. A page can still load after the services behind it pause for insufficient credits, so check whether the whole task works. Also check Lovable’s inactivity rules before relying on a Free project as a permanent address.
Why might a finished Lovable app still use credits?
Think about what the app does on behalf of clients. Saving a brief, storing PDFs and generating an AI summary inside the app can use different resources than asking Lovable to change the form.
Lovable shows Build and Run separately in usage details, but both draw from the same credit balance. Check how much each uses for the things you plan to offer. An old grant or a one-time credit can make a small test look cheaper than running the app next month.
| Type of usage | What it means | What to check |
|---|---|---|
| Build credits | Lovable working on your requests inside the editor. | The plan allowance, what resets and which features require a paid plan. |
| Cloud and in-app AI | Your customers using the app’s data, storage or AI features. | Which services draw from the balance, and any usage limit or alert you can set. |
| Outside accounts | Other services you connect to the app. | Whether the provider charges you directly for a domain, email or another service. |
On a small screen, scroll the table sideways to read every column.
What should you try before asking clients to upload real files?
Submit a made-up brief, try an interrupted upload and try resubmitting after a failure. The app should show which brief was saved and make clear whether the file arrived. A success message that appears before anything is saved can leave both sides thinking the other has the brief.
Check what you can restore if a bad change removes files. Confirm that keys used to connect services aren’t sent to a client’s browser. Work with disposable files until those checks pass.
If you sync to GitHub, what stays behind in Lovable?
GitHub gives you a separate home for the code and its change history. Lovable’s sync creates a new repository, a collection of project files, rather than linking directly to any existing one. Disconnecting stops the sync and leaves that repository in place.
A full move also needs a database export, copies of the original PDFs and configuration for sign-in, service credentials and scheduled work. Some account settings don’t come in the database export. Try the new setup with sample files and a test sign-in before you remove the original backend.
Can you move the pages first and keep Lovable Cloud?
Yes. You can host the code elsewhere while keeping Lovable Cloud for the work behind it. That leaves the Cloud usage and the data where they already are. It can make sense when you need control of the website host but don’t want to move customer records yet.
Check which kind of host the exported app needs. A host that only sends finished files to a browser can’t run code your app expects to run on a server. If you take over the backend too, plan who will handle updates, failures and restoring information after an accident.
Where can you learn the next steps?
- Check your app before inviting usersUse separate accounts and failed requests to check access, saved results and recovery.