Setting it up
Getting Lovable working, in order
You've decided. From here we stop selling it to you and start getting it done. Tick things off as you go, this browser remembers, no account needed.
0 of 7 steps everyone does · next: Create your account and open a project
First
Get set up properly
Ten minutes of thinking here saves a week of rebuilding later.
- 01
Create your account and open a project
about 10 minWhy now, You have decided Lovable is the right tool for this build.
Create your account and open one empty project. Do not type a build request yet, the next three steps are what make the first one worth sending.
The first message you send shapes everything that follows, so it is worth arriving prepared rather than starting with a one-line idea.
Done when, You are signed in with an empty project open.
You'll know it worked when you can see an empty project and the message box.
Start building with LovableGoes directly to Lovable's official site.
- 02
Understand how the three parts work together
about 5 minWhy now, You are signed in and about to start building.
Three things do three different jobs. Biz Spouse keeps the business decisions, the order of work and the wording you copy. ChatGPT, Claude or Gemini, whichever you already use, is where you think out loud and turn your situation into a plan. Lovable is where the plan gets built. When something is unclear, come back here; when you need to think, use your AI assistant; when you need it built, use Lovable.
People get stuck because they ask the builder to make business decisions, or ask a chat assistant to build. Neither is what those tools are for, and both waste days.
Done when, You can say which of the three you would open for a given question.
You'll know it worked when you have your AI assistant open in another tab, ready for the next step.
Before you build
Work out what you're building
This part happens in ChatGPT, Claude or Gemini, whichever you already use. You come back with one clear request to hand over.
- 03
Decide what you are actually building
about 20 minWhy now, You have an account and an empty project staring at you.
Say in one sentence whether this is a marketing site, a lead-generation site, a customer portal, an internal tool or a full web app. Everything after this depends on that answer.
The same builder produces very different work for a brochure site and for a product with logins. Deciding first stops you building the wrong shape.
Done when, You can name what you are building and who it is for in one sentence.
You'll know it worked when you can say the job of the site in one sentence without using the word "and" twice.
Start from an idea
Use this when you have an idea in your head and the build keeps drifting away from what you meant.
Turn a rough idea into a first version worth building.
Asks what the one job is, then writes a two-sentence brief before anything gets built.
- 04
Gather what it needs to say and do
about 40 minWhy now, You know the job; the build now needs facts only you have.
Write down the screens or pages you genuinely need, the one action that matters most, and anything real you already have: brand colours, a logo, your own words about the business.
The result tracks the brief. Everything you do not supply is either asked for or missing.
Done when, You have a short written brief you would be happy to hand a person.
You'll know it worked when you have your pages, your one main action, and your actual business details in one place.
Plan before building
Use this once you have a brief and before the first screen is built.
Get the build order right before anything is built.
Produces a numbered plan where each step ends in something you can see working.
Then
Get something that actually works
One real, working version, then protect it before you change anything else.
- 05
Hand it the brief below
about 30 minWhy now, You have the raw material and are about to type your first message.
Copy the prompt below into the same conversation where you planned this, paste the block it gives you back into Lovable as your first message, and let it build.
It makes the builder ask you for the missing pieces instead of guessing at your business.
Done when, It asked you questions and showed a plan before building.
You'll know it worked when a first version exists and opens in the preview.
Turn your plan into the first message for Lovable
You have a plan, and the next thing you have to do is say it to the builder in one message.
Turn the plan you just made into the one message you paste into Lovable.
It writes the build request for you, in your words, and tells you what to check when the build comes back.
- 06
Review the first version on a phone and a desktop
about 20 minWhy now, A first version exists.
Open the preview on your own phone as well as your computer. Ask for one change per message and check each one.
Small changes are easy to check and easy to undo. Big ones are neither.
Done when, The first version does what you described, on both screen sizes.
You'll know it worked when you have opened it on your own phone and listed what is actually wrong.
Audit it on a phone
Use this when the site looks right on a laptop and wrong on a phone.
Make the phone version a designed one, not a squeezed desktop.
Goes page by page for sideways scroll, cramped taps and hidden actions.
- 07
Lock in what works before you change it
about 15 minWhy now, Something in the build now works and you are about to change more of it.
Write down the handful of things that must keep working, the enquiry form, the phone number, the sign-in, and say so explicitly every time you ask for a change. Take a copy of the working version first.
Most of the pain people report with build tools is not a failed change; it is a change that silently broke something else that had been working for a week.
Done when, You have a written list of what must not break, and a saved copy of the working version.
You'll know it worked when your list exists and you have used it in at least one change request.
Protect what already works
Use this when a fix in one place has already broken something in another.
Change one thing without breaking the rest.
Treats your list of working features as a hard constraint, and reports how each was checked.
- 08
Keep your own copy of the code
Only if your build needs itabout 15 minWhy now, Something real exists and works, which is the point at which losing it would actually hurt.
Applies when Once this is becoming a real business asset rather than a weekend experiment.
Connect the project to a code repository in your own account, so a full copy of the code lives somewhere you control and keeps updating as you build.
It is your asset. Being able to walk away with the code is the difference between a tool and a trap, and it is a real backup of the version that works.
Done when, The project appears in a repository owned by you, and updates when you make a change.
You'll know it worked when your repository shows the project code, and a change you make in the builder appears there.
Your own code repository
A two-way sync between the project and a code repository you own, on GitHub or GitLab.
It means the work exists somewhere you control, and a developer can pick it up later without asking anyone's permission.
- You get
- Your own copy of everything, plus a history of changes you can look back through.
- You'll need
- A free GitHub or GitLab account.
- Do this
- Connect the repository from the project, then confirm the first sync completed.
- Check it
- Your repository shows the project files and updates after your next change.
- Then
- Carry on building.
Haven't got it? That's fine, Nothing breaks without it, but the only copy of the work stays in one account.
Read our take on GitHubOfficial source · as of September 2026 · Checked against the vendor's own documentation.
Only if your build needs it
Add what this particular build requires
None of these apply to every build. Each one says when it applies to yours.
- 09
Add sign-in and stored data
Only if your build needs itabout 60 minWhy now, Your build needs to remember people or records.
Applies when Only if people log in, or you store records such as bookings, customers or orders.
Turn on the built-in database and sign-in, then keep each account able to see only its own data.
A brochure site does not need a login. Adding one early is work with no return.
Done when, A test account can sign in and sees only its own data.
You'll know it worked when someone can sign in, and one account cannot see another account's records.
Walks through adding a database, accounts and stored data to a Lovable build.
Built-in database, sign-in and file storage
The platform's own backend: a database, accounts and sign-in, file storage and server code, switched on inside the project.
If your site has to remember anything, enquiries, bookings, customer accounts, this is the shortest route to it, with no separate hosting account to run.
- You get
- Sign-in, stored records and per-account privacy without wiring up a separate service.
- You'll need
- A working first version.
- Do this
- Ask for the built-in backend to be enabled, then ask for sign-in and the records you need.
- Check it
- You can sign in as a test person and see only that person's records.
- Then
- Run the security review.
Haven't got it? That's fine, A brochure site with a contact form that emails you does not need this. Skip it until something has to be remembered.
Official source · as of September 2026 · Checked against the vendor's own documentation.
Wire up the backend
Use this before building anything that has to remember information.
Get the data and connections right before building on top of them.
Describes what to store, who may see it, and what connects to what, in build order.
Before real people use it
Check it, then let people in
Not needed while you're still experimenting. Needed before anyone else relies on it.
- 10
Check it is safe before real people use it
Before you launchabout 45 minWhy now, You are close to letting real people in.
Applies when Only if it handles logins, payments, or any personal details.
Work through the platform security review and fix what it flags.
The builder speeds you up; it does not sign off on protecting other people's details.
Done when, No outstanding security warnings on anything holding personal data.
You'll know it worked when the security review has been run and everything it flagged is either fixed or understood.
Check before going live
Use this before real customers put data into anything you built.
Find exposure before customers arrive.
Lists findings by severity: what is exposed, to whom, and what to change.
- 11
Put it on your own web address
Before you launchabout 30 minWhy now, The site is ready to be seen.
Applies when Only when it goes out publicly and you have a domain and a paid plan.
Point your domain at the project so people see your name, not a platform address.
A platform address undercuts trust and is hard to say out loud.
Done when, Your domain loads it over https.
You'll know it worked when your own address loads the site over https.
Your own web address
Pointing a domain you own at the finished site.
People judge a business by its address. Yours should be your name, not a platform subdomain.
- You get
- A professional address you keep, whatever you build it with.
- You'll need
- A registered domain.
- Do this
- Add the domain in the project settings and update the records at your registrar.
- Check it
- Your own address loads the site over https.
- Then
- Prove the parts that matter work.
Haven't got it? That's fine, The platform address works fine while you are still testing.
Official source · as of September 2026 · Checked against the vendor's own documentation.
Audit how you get found
Use this when the site is live and nobody is finding it.
Make each page findable and clearly about one thing.
Checks title, description and headings page by page, and rewrites the weak ones.
- 12
Prove the parts that matter actually work
Before you launchabout 30 minWhy now, You are about to tell people the site exists.
Run the real actions end to end, whichever exist: send yourself an enquiry, sign in as a customer, take a test payment, save and reload a record. Check the phone version last.
A build that looks finished and quietly loses enquiries or payments is worse than no build.
Done when, Every action that matters has been completed once, by you, on a phone.
You'll know it worked when you have completed every real action yourself, end to end, on a phone.
Final check and what next
Use this when you think it is finished, before you put it in front of anyone.
Confirm it is ready, and name the next worthwhile improvement.
Reports what was actually checked, what is outstanding, and the single next step.
Connections
What to connect it to, and what to leave alone
Connecting everything is the expensive mistake. Each of these says what it is, why you'd want it, and whether you want it yet.
Recommended for this build
Built-in database, sign-in and file storage
The platform's own backend: a database, accounts and sign-in, file storage and server code, switched on inside the project.
If your site has to remember anything, enquiries, bookings, customer accounts, this is the shortest route to it, with no separate hosting account to run.
- You get
- Sign-in, stored records and per-account privacy without wiring up a separate service.
- You'll need
- A working first version.
- Do this
- Ask for the built-in backend to be enabled, then ask for sign-in and the records you need.
- Check it
- You can sign in as a test person and see only that person's records.
- Then
- Run the security review.
Haven't got it? That's fine, A brochure site with a contact form that emails you does not need this. Skip it until something has to be remembered.
Official source · as of September 2026 · Checked against the vendor's own documentation.
Your own code repository
A two-way sync between the project and a code repository you own, on GitHub or GitLab.
It means the work exists somewhere you control, and a developer can pick it up later without asking anyone's permission.
- You get
- Your own copy of everything, plus a history of changes you can look back through.
- You'll need
- A free GitHub or GitLab account.
- Do this
- Connect the repository from the project, then confirm the first sync completed.
- Check it
- Your repository shows the project files and updates after your next change.
- Then
- Carry on building.
Haven't got it? That's fine, Nothing breaks without it, but the only copy of the work stays in one account.
Read our take on GitHubOfficial source · as of September 2026 · Checked against the vendor's own documentation.
Required before you launch
Your own web address
Pointing a domain you own at the finished site.
People judge a business by its address. Yours should be your name, not a platform subdomain.
- You get
- A professional address you keep, whatever you build it with.
- You'll need
- A registered domain.
- Do this
- Add the domain in the project settings and update the records at your registrar.
- Check it
- Your own address loads the site over https.
- Then
- Prove the parts that matter work.
Haven't got it? That's fine, The platform address works fine while you are still testing.
Official source · as of September 2026 · Checked against the vendor's own documentation.
Useful later
Visitor measurement
A measurement tag that records how many people visit and what they do.
Once real people arrive, guessing about what they do is expensive. This is the cheapest way to stop guessing.
- You get
- Real numbers behind decisions about pages and wording.
- You'll need
- A live site and a free analytics account.
- Do this
- Create the property, then ask for the tag to be added to the site.
- Check it
- Your own visit shows up in the real-time report.
- Then
- Check how you get found.
Haven't got it? That's fine, Before anyone visits, there is nothing to measure. Leave it.
Official source · as of September 2026 · Checked against the vendor's own documentation.
Search reporting
A free tool that shows how a search engine sees the site and what it is being found for.
It is the only honest source on whether your pages can actually be found.
- You get
- Indexing problems you would otherwise never see.
- You'll need
- A live site on your own address.
- Do this
- Verify the site, then submit it.
- Check it
- The site shows as verified and pages start appearing as indexed.
- Then
- Fix whatever it reports.
Haven't got it? That's fine, Not useful until the site is live on its real address.
Official source · as of September 2026 · Checked against the vendor's own documentation.
Working from ChatGPT
A way to work with your project from inside ChatGPT rather than only in the browser editor.
If your thinking already happens in ChatGPT, this shortens the trip between deciding and building.
- You get
- Planning and building in one conversation.
- You'll need
- A project that already exists.
- Do this
- Follow the official setup for the ChatGPT app.
- Check it
- Your project responds from inside ChatGPT.
- Then
- Carry on building.
Haven't got it? That's fine, Completely optional. The browser editor does everything.
Official source · as of September 2026 · Checked against the vendor's own documentation.
Connecting outside tools to the build assistant
Connectors that let the build assistant read from tools you already use while it works.
It saves pasting the same context in repeatedly when the facts live somewhere else.
- You get
- Less re-explaining of things the assistant could look up.
- You'll need
- An account with whichever tool you are connecting.
- Do this
- Add the connector from the integrations settings.
- Check it
- The assistant can reach the connected tool when asked.
- Then
- Carry on building.
Haven't got it? That's fine, Pasting the context by hand works and costs nothing.
Official source · as of September 2026 · Checked against the vendor's own documentation.
Not needed yet
Connectors inside the app you build
Connections your finished app makes to outside services on behalf of you or your users.
Only relevant when the app itself has to reach another service to do its job.
- You get
- Your app doing work in other tools.
- You'll need
- A live app with a real reason to reach outside.
- Do this
- Add the connector the app needs.
- Check it
- The app completes the outside action end to end.
- Then
- Test it as a real customer would.
Haven't got it? That's fine, A site that presents your business and takes enquiries needs none of this.
Official source · as of September 2026 · Checked against the vendor's own documentation.
Taking payment
A payment provider wired into the site so customers can pay.
Only if you are selling through the site rather than invoicing after the work.
- You get
- Card payment without a separate checkout.
- You'll need
- A payment account and something to sell.
- Do this
- Follow the official payment integration steps.
- Check it
- A real test payment reaches your payment account.
- Then
- Confirm what the customer receives afterwards.
Haven't got it? That's fine, Most local service businesses quote first and invoice after. Skip it.
Official source · as of September 2026 · Checked against the vendor's own documentation.
Automatic emails
A service that sends emails your site generates, confirmations, receipts, notifications.
Needed once the site has to email someone reliably rather than just show a phone number.
- You get
- Confirmations that actually arrive.
- You'll need
- A domain you can verify.
- Do this
- Connect the email service and verify your sending domain.
- Check it
- A test confirmation arrives in a real inbox, not spam.
- Then
- Check what the wording says.
Haven't got it? That's fine, A form that emails you directly is enough at the start.
Official source · as of September 2026 · Checked against the vendor's own documentation.
Automation between this and your other tools
UnconfirmedA separate automation tool sitting between your site and the rest of your stack, moving information between them.
It is the usual answer when two tools have no direct connection and you are copying between them by hand.
- Then
- Look at whether the two tools connect directly first.
Haven't got it? That's fine, We have not verified a direct, officially documented relationship between Lovable and any specific automation tool, so we are not claiming one. Custom connections through an API are possible; the exact route is a research gap on our side.
Biz Spouse research · as of September 2026 · No official documentation found for this relationship; recorded as unresolved rather than asserted.
Something not behaving? The problems people actually hit with Lovable, and the prompts that fix them, are on the main page.
Problems and fixes