How do you share a Lovable project with a client?

Export the project code, build it to static output, and host that output at a shareable URL. The client opens a normal web link in any browser with no account, install, or access to your Lovable workspace.

Should a client review the Lovable preview or a hosted copy?

A hosted copy is better for a formal review round because it is a fixed snapshot. The preview inside a generator keeps changing as you prompt, which invalidates the client's notes while they are writing them.

How do clients leave feedback without a project management tool?

Host the build on a platform that supports pinned comments, then send one link. The client clicks the element they mean and types the note there, which removes the step where you translate their email into locations on the page.

Can a client review a Lovable app on their phone?

Yes, if the build is hosted as a normal static site. It loads in a mobile browser like any other page, which also makes it the fastest way to check whether the generated layout actually holds up on a small screen.

How do you keep track of client revision rounds?

Re-upload the new build to the same project instead of sending a new link. Each upload is stored as a version with its own comments, so round one and round three are both retrievable alongside what the client said about each.

How to Share a Lovable Project for Client Feedback

Lovable can take a client brief to a working app inside one sitting. Then the project stalls, because the client’s review still happens over email attachments and screenshots with red arrows on them. This guide is for freelancers and agencies who need a client sign-off loop that moves as fast as the build did.

The Problem

Client review is the part of agency work that eats margin. The generator did not change that — it just made the contrast more obvious.

What normally happens:

You share a preview link or a screen recording.
The client replies with a numbered email: “1. The blue is too dark. 2. Move the pricing bit up. 3. The form on the second page looks broken.”
You reverse-engineer which blue, which pricing bit, and which form.
You guess on two of the three, ship, and get a follow-up email correcting your guesses.

Two things cause this, and neither is the client’s fault:

The feedback channel and the artifact are separate. An email cannot point at a pixel, so the client describes locations in prose. Prose is ambiguous.
There is no shared version reference. “The version I looked at on Tuesday” is not a retrievable thing, so disagreements about what was asked for cannot be settled.

The Solution

Publish the build as its own page and let the client mark it up directly. Three steps, one of which you already do.

1. Export the project

Lovable projects are standard front-end code, and Lovable can push to GitHub or hand you the project. Get it onto your machine as a normal folder with a package.json.

2. Build to static output

npm install
npm run build

You now have a build folder — dist/ for Vite, out/ for a statically exported Next.js app — containing the entire front end as plain files. This is the artifact you want the client to see. It has no dependency on your account, your editor, or your network.

If the project talks to a live backend, decide before the review whether the client is reviewing behaviour or interface. For an interface review, mock the data. A client stuck on a spinner will review the spinner.

3. Upload it and send one link

Zip the build folder, upload it, and send the URL. Nothing to install on their side, and no login wall between the client and the work.

Then use the part that actually shortens the loop: on Undraft, the client can click any element on the live page and leave a comment pinned to it. “The blue is too dark” arrives already attached to the specific button, so there is no interpretation step and nothing to guess.

Why This Matters More for Client Work Than Internal Work

Internal reviewers will tolerate a messy loop. Clients bill you for it, in revision rounds and in scope arguments.

Ambiguity is expensive at both ends. Every clarifying email is a day of calendar time and a small deposit of client doubt about whether you understood the brief.

A version record is leverage. When a client says “this is not what we agreed,” being able to open round two and show the comment they left — and the change that answered it — ends the conversation in a minute rather than a meeting.

Non-technical clients need low-friction access. No install, no “open the terminal and run this.” A link that works on their phone in the taxi is the format that gets reviewed today rather than next week.

Examples

Before

Deliver a Lovable-built landing page as a screen recording.
Client emails five numbered notes.
Three of the five are ambiguous; you email back.
Client replies the next morning.
You make changes and record a new video.
Client asks whether you also fixed the thing from the first email.

Two days, one unresolved item, no record.

After

Build the project and upload dist/.
Send one link with a note: “reviewing layout and copy, data is placeholder.”
Client pins five comments to five elements.
You rebuild and re-upload to the same project.
Client opens the same link, sees version 2, and resolves the comments that are addressed.

One day, nothing ambiguous, and a record either side can point to.

Summary

Send a live link, not a recording — build to static output, upload it, and let the client interact with the real interface in their own browser.
Measure rounds, not messages — count how many upload-and-review cycles a project takes; that number is the one that predicts your margin.
Avoid gathering client notes in email — prose descriptions of screen locations are the single biggest source of avoidable revision rounds.

Next: see how to share an HTML file as a live link, and what it looks like to comment on a webpage directly.