AI app builder
How to use
Lovable.
Turning a product brief or interface reference into a working web application, iterating visually, connecting a backend, and synchronizing editable code to GitHub.
Lovable is a full-stack AI application builder. Turning a product brief or interface reference into a working web application, iterating visually, connecting a backend, and synchronizing editable code to GitHub. This guide covers the whole path in one place: official access, a first session that produces something reviewable, the checks that make output trustworthy, and the permissions worth limiting before you connect real work.
AI should make the work easier to inspect. If the workflow removes the source, the owner, or the review step, redesign the workflow.
Access & setup
Find, install, and sign in to Lovable
Get into the official Lovable experience with the right account and a setup you understand.
- 01
Start at https://lovable.dev/ and confirm the domain before entering account or payment information.
- 02
Availability: Browser-based development platform with published previews and GitHub synchronization.
- 03
Create a Lovable account in a modern browser. GitHub, backend, domain, and third-party service connections require separate accounts and permissions.
- 04
Sign in with the account you intend to keep using, then review plan, data, notification, and permission settings.
- 05
Run one low-risk test task before connecting sensitive files, repositories, or workspace data.
- Use official download pages.
- Review permissions during setup.
- Keep installers and applications updated.
First session
Your first useful Lovable session
Learn the interaction loop using a small task with a clear outcome.
- 01
Create one project and write a brief covering user, core flow, data, visual direction, and what is explicitly out of scope.
- 02
Use Plan mode for the architecture before asking the agent to build.
- 03
Test the generated preview on desktop and mobile with the actual primary flow.
- 04
Connect GitHub and external services only after reviewing permissions and understanding the generated code.
- State the outcome before the background.
- Provide the real source material.
- Review the result before expanding the task.
Quality control
Check the quality of Lovable output
Turn generated code into a change you would put your name on in review.
- 01
Restate the intended behaviour and the acceptance criteria before reading a single generated line.
- 02
Read the diff rather than the chat summary; the summary describes intent, the diff describes what actually changed.
- 03
Run the test suite, then write a test that would fail if the change were wrong, and confirm it passes for the right reason.
- 04
Check the edges the model tends to skip: error paths, null and empty cases, concurrency, and migration or rollback behaviour.
- 05
Trace every new dependency, network call, and file write, and confirm each one is genuinely required.
- Review the diff, never the description of the diff.
- A passing test suite proves the tests pass, not that the change is correct.
- Keep changes small enough that a human can actually review them.
Privacy & permissions
Use Lovable safely
Give the tool enough repository access to help, and no more than that.
- 01
Decide what the tool may read and what it may write before connecting a repository.
- 02
Scope tokens and integrations to the narrowest repository, branch, and permission set that still works.
- 03
Keep secrets out of the context window: use environment variables and secret stores, never inline credentials.
- 04
Require review before generated code touches authentication, payments, permissions, migrations, or deletion paths.
- 05
Audit what the integration retained after the session, and revoke access that is no longer needed.
- A working preview is not proof of production readiness. Review authentication, authorization, data handling, dependencies, accessibility, error paths, and deployment settings before launch.
- Follow your organisation's approved-use policy.
- Never treat fluent output as authorization to act.
Core workflows
Step-by-step ways to use Lovable for the work it does best.
Each workflow below has its own outcome, steps and review checkpoints.
Translate a product brief into a small, testable application instead of an unbounded feature list.
↓ 02 WorkflowMove a Lovable project toward productionConnect code and services carefully, then review the areas a polished preview does not prove.
↓Workflow 01
Build a focused first product in Lovable
Translate a product brief into a small, testable application instead of an unbounded feature list.
Outcome: Publish a coherent prototype with one complete primary flow.
- 01
Define the user, problem, main flow, data, visual direction, and explicit exclusions.
- 02
Use Plan mode and challenge unclear architecture or assumptions before building.
- 03
Ask for the smallest end-to-end version of the primary flow.
- 04
Test it with realistic content on desktop and mobile, including empty and error states.
- 05
Review code and deployment settings before publishing a shareable version.
What good use looks like
- One flow before many features.
- Use realistic data early.
- Re-publish after verified changes.
Workflow 02
Move a Lovable project toward production
Connect code and services carefully, then review the areas a polished preview does not prove.
Outcome: Create a production-readiness plan grounded in the generated application.
- 01
Connect GitHub and establish which direction changes will synchronize.
- 02
Inventory authentication, authorization, database, storage, email, payments, and external APIs.
- 03
Review secrets, row-level access, validation, rate limits, and destructive actions.
- 04
Add automated checks and manually test critical and failure paths.
- 05
Document ownership, monitoring, backups, rollback, privacy, and support before launch.
What good use looks like
- Preview quality is not security evidence.
- Keep environments separate.
- Review generated dependencies.
Official references
Check the current product documentation.
Features, plan limits, availability, and data controls change. These official pages are the starting points used for this guide.