To build websites for clients with AI, start with a small agreed result: who the site serves, what it contains, and how the client will operate it. An AI builder such as Lovable can generate pages from your instructions. Your job is to turn the client's needs into a clear brief, check what was built, and leave the client able to use and maintain the website.
If you are new to Lovable, practise this sequence on a fictional business before promising it to a paying client. Our first Lovable website guide covers the editor and a simple first build. This guide focuses on the client work around that build: scope, approval, acceptance, and handover.
We will use Fern & Pot, a fictional indoor plant-care service for small offices and cafés. The brief and prompts below are original practice examples, not a completed client project or a tested Lovable build.
1. Agree what the first website must do
Ask the client to describe a visitor's next step. “We want a modern website” gives you a visual preference; “An office manager should understand our plant-care services and email us” gives you something to build and check.
Write a short project brief and ask the client to confirm it before building. For Fern & Pot, it could look like this:
| Decision | Agreed first version |
|---|---|
| Visitor | An office or café manager looking for indoor plant care |
| Purpose | Explain the services and invite an email enquiry |
| Pages | Home, Services, and Contact, in one agreed language |
| Content | Plant assessment, regular care visits, and repotting; approved descriptions and images |
| Main action | An Email us link to the client's agreed address |
| Updates | The builder makes requested content changes under a separate maintenance agreement |
| Outside this version | Enquiry forms, booking, payments, customer accounts, and an owner editing dashboard |
Also agree who approves the text, how feedback is collected, which revisions are included, and when the client must supply materials. If the client later asks for online booking, describe the extra work and agree a revised scope before adding it.
A three-page site does not automatically include a tool for the owner to edit those pages. If independent content editing is essential, decide how it will work before choosing the build approach.
2. Collect the client's content and ownership decisions
Ask for accurate service descriptions, contact details, service area, business name, logo, and images the client has permission to use. Mark missing items explicitly. AI-written reviews, qualifications, or prices should never fill those gaps.
Keep account decisions alongside the content. A workspace is the area in Lovable where projects and collaborators are managed. For a real client project, agree whether the client will control that workspace from the start or whether you will provide an ongoing managed service.
| Responsibility | Builder's part | Client's part |
|---|---|---|
| Brief and revisions | Record included pages, behavior, exclusions, and changes | Confirm the scope and name one approver |
| Business facts and media | Organize the supplied material; flag gaps | Provide accurate facts and approve use of images and logo |
| Build and checks | Implement the brief; record checks and unresolved issues | Review the wording and try the main visitor path |
| Accounts and costs | List required services, access, and recurring charges | Confirm account control, billing responsibility, and renewals |
| Enquiries | Connect and check the agreed contact route | Monitor that route and answer visitors |
| Maintenance | Explain how updates and fixes will be handled | Decide who requests, approves, and pays for ongoing work |
Use invitations to individual accounts rather than sharing a password. Give people access to the relevant project, and review which role they need. Lovable supports project and workspace collaboration; collaborators use the credits of the project's workspace. Agree who pays for building and later edits.
For a custom domain, record who controls its registration, renewal, and connection settings. Connecting a domain to a website does not transfer its registration to a new owner. See Lovable's domain documentation when planning that step.
3. Build one visitor path, then revise it
Turn the approved brief into an instruction for Lovable. A prompt is the request you give AI. The official quick start describes creating a project from a written request and refining it in the project chat.
For practice, replace both occurrences of YOUR_TEST_EMAIL below with an address you control. The example requests an English-language website. For a real project, specify the client's agreed website language and review the generated copy in that language.
Build a small English-language website for Fern & Pot, a fictional indoor plant-care service used for practice.
Audience: managers of small offices and cafes.
Purpose: explain the services, then help the visitor enquire by email.
Create three pages: Home, Services, and Contact, with navigation between them.
Services: Plant assessment, Regular care visits, and Repotting. Use short factual descriptions without prices or guarantees.
Add an "Email us" link that opens mailto:YOUR_TEST_EMAIL, and show YOUR_TEST_EMAIL on the Contact page.
Use a readable design that works on phones and desktop screens. Make all three pages reachable from the phone navigation.
Show "Practice website for a fictional business" on every page. Use simple plant illustrations rather than photos of supposed clients.
Do not invent testimonials, certifications, an address, service areas, or opening hours.
Do not add forms, booking, payments, customer accounts, a database, or an owner editing dashboard.Inspect all three pages before asking for extra polish. Check the navigation, service names, contact address, and practice notice. Keep a short change record: what you requested, what changed, and what you checked.
For a revision exercise, rename one service without changing the site's scope:
Rename "Regular care visits" to "Scheduled plant care" everywhere on the website. Keep its description, the other services, navigation, email destination, and design unchanged. Do not add features.After the change, search the pages for the old wording and recheck the contact link. A requested text edit is complete when the intended text changed and the existing visitor path still works.
For client feedback, turn “make it better” into an observable change. “On the phone layout, the Contact link is hidden behind the menu” gives you a specific problem to investigate. Collect feedback in one agreed place, so conflicting messages do not become conflicting build instructions.
4. Agree acceptance through things you can observe
Review the website against the brief with the client. Keep content approval and functional checks explicit: the client knows whether the service description is true; you must also verify whether the contact action works.
| Check | Evidence for acceptance |
|---|---|
| Pages and navigation | Home, Services, and Contact open; each is reachable through desktop and phone navigation |
| Business content | The client approves the names, descriptions, contact details, and media |
| Email action | The link opens an email draft with the agreed recipient on a device with an email handler configured |
| Contact handling | A marked test email is sent separately and the client confirms receiving it |
| Phone layout | Text and controls are readable; menus work; the page does not scroll sideways |
| Basic usability | Links have understandable labels, keyboard focus is visible, and text remains usable when enlarged |
| Published version | The agreed visitor URL shows the approved content and passes the same contact and navigation checks |
An email link opens a draft; it does not send a message, save an enquiry, or confirm an appointment. If a device has no email handler, inspect the link destination and test on another configured device. Keep the address visible so visitors can copy it.
If a real client's scope includes a form, add a separate acceptance check: submit a marked test request, find it at the agreed destination, and have the client confirm they can read it. Also check invalid input, failed submissions, and who can access stored requests. Our AI landing-page guide covers that enquiry path in more detail.
Resolve open issues before describing the site as complete. If you cannot explain or verify an added feature, narrow the delivery or get experienced help before offering it to a client.
5. Publish and hand over control
Obtain the client's approval for the content and the planned public address. Replace the fictional material before launching a real business site. Follow Lovable's publishing workflow, then open the visitor URL in a separate browser session and on a phone. After later edits, use Publish → Publish changes and repeat the affected checks; editing the preview does not update the published site automatically.
Give the client a short handover note containing:
- Website and project locations: the public URL and where the website is edited.
- Account control: who controls the project, workspace, domain, and any connected services; confirm the client's intended access from their own account.
- Costs and renewals: services in use, who pays each bill, and who monitors usage or renewal notices.
- Contact handling: where enquiries arrive and who checks that destination.
- Update instructions: how to request a content change, approve it, publish it, and check the visitor's version.
- Recovery and support: where the source or recovery copy is kept, how a broken change will be handled, and what support is included.
Lovable distinguishes inviting a collaborator, transferring project ownership to another workspace member, and moving a project to another workspace. Use the current project documentation for the chosen route. Check domain control, billing, and connected services separately rather than assuming a project action transfers everything.
If you promise the source code, include where the client can access it. A code copy alone does not include every account, stored request, or running service. Lovable's ownership and hosting guide explains why code, hosting, and backend services need separate decisions.
Finish with a client demonstration: sign in with their own account, locate the project, check the contact destination, and walk through the agreed update process. Record any access you retain for maintenance and why it is needed.
Choose a first project you can keep working
A suitable practice project has a clear visitor, a few stable pages, approved content, and a simple contact route. Build it, complete the checks, and rehearse handover before taking on a project with private data, accounts, or complex integrations.
For paid work, agree the work and ongoing support in writing. Name who corrects delivery defects, who handles later content changes, and how new features are quoted. A live URL does not settle those responsibilities, and builder charges are only part of the operating cost. Read our Lovable pricing guide for usage limits and AI app cost guide for the broader budget.
RianVibe's Build Your First Digital Product with AI course uses a Todo app to practise briefing Lovable, making changes, handling data, checking results, and applying the method to your own project. The introduction is free; the full course is paid, with provider charges separate. It provides foundational practice, not a complete freelancing business course or a guarantee of readiness for every client project.
Workflow sources checked October 9, 2026: Lovable quick start, collaboration, projects and ownership, domains, publishing, and ownership and hosting.
FAQ
Can a beginner build client websites with AI?
You can learn by building a small practice site. Before accepting a client project, make sure you can deliver and check its agreed behavior, explain the costs, and hand over the intended access. Requirements involving private data or complex integrations may need experienced help.
Who should own the Lovable account and domain?
Agree this before building. For a client-controlled site, use accounts the client controls and invite the builder. A managed service can use a different arrangement, but account access, payment, updates, and the exit process should be clear to both sides. Use separate personal logins rather than a shared password.
Can the client edit the website after handover?
Only through the update method you agreed and provided. Access to a project does not automatically give the client a simple content-editing dashboard. Demonstrate the actual process, whether that means editing in Lovable, using a separately built owner tool, or requesting maintenance from you.
Is a contact form necessary for a small client website?
No. A working email or messaging route may meet the brief. A form adds storage or a receiving service, access rules, and more checks. Choose it when it helps the client's process, and agree who will read and answer the requests.