Uncategorized18 MIN READ

Create a Website With Lovable (Step-by-Step, 2026)

Create a website with Lovable using Plan mode, Agent mode, publishing, a custom domain, and security basics. Includes prompts and launch checklist.

Tudor Barbu
Tudor Barbu
Create a Website With Lovable (Step-by-Step, 2026)

Intro

If you can describe what you want, you can ship a website now.

That’s the promise of Lovable: build websites and web apps through natural language, backed by real code and a real deploy flow.

But “create website with Lovable” has two very different meanings:

  1. A marketing website (landing page, portfolio, small business site)
  2. A Lovable app that acts like a website but can grow into login, database, and workflows

This guide covers both, with a step-by-step flow from first prompt → Plan mode → Agent mode → publish → custom domain → basic security.

If you want the app-style version (auth, DB, Stripe, deeper SEO workflow), use this companion guide: Build with Lovable in 2026.

Key takeaways

  • Lovable is a full-stack AI development platform that generates a working application with editable code and can cover frontend, backend, database, authentication, and integrations.
  • The workflow that ships is: Plan mode for decisions, Agent mode for implementation and verification, repeat.
  • Prompting works best when you plan before you prompt, map the user journey, and avoid vague placeholder content.
  • Publishing includes access control (workspace-only vs public), plus editable SEO and social preview metadata (favicon, title, description, share image).
  • Custom domains require DNS access and verification via A and TXT records, and you must avoid AAAA records that can interfere with setup.
  • Security is not optional: protect API keys via Secrets + server-side functions, and use RLS when your “website” becomes a multi-user app.

What “website with Lovable” means in 2026

Lovable positions itself as a platform for building and deploying web applications with real code, using natural language, and supporting the full lifecycle from exploration to deployment.

So when someone says “Lovable website,” it’s usually one of these:

A) A pure website (marketing site)

Typical examples:

  • personal portfolio
  • agency website
  • product landing page
  • campaign site
  • small business site

You need:

  • pages and sections
  • good copy and CTAs
  • contact forms
  • publish and custom domain
  • SEO metadata and social share previews

B) A “website” that becomes a web app

This is the Lovable advantage: you can start as a website, then add:

  • authentication
  • database
  • dashboards
  • internal workflows
  • integrations

Lovable explicitly lists “websites and marketing pages” among what you can build, alongside SaaS, internal tools, and commerce.

When Lovable is the right tool

Lovable is a great fit for “website with some product behavior,” such as:

  • a landing page plus waitlist form
  • a directory with filters
  • a calculator tool
  • a lightweight lead capture workflow
  • an internal portal

If you only need pixel-perfect design control with minimal logic, design-first tools might feel simpler. Lovable is strongest when the site has a workflow behind it.

Step 0: Decide what you’re building (and validate fast)

Before you prompt anything, decide:

  1. Who is the site for?
  2. What do you want them to do (one action)?
  3. What proof makes them trust you?
  4. What happens after they take the action?

That “one action” matters because Lovable itself recommends identifying a single key action the user should take.

Quick validation (optional, but saves weeks)

If the site is for a new product or MVP idea, validate demand before you build a polished website.

Use Validate your MVP idea in 7 steps (scripts included) to run interviews, landing tests, and a pricing check.

Step 1: Plan before you prompt

Lovable’s prompting guide starts with a blunt recommendation: plan first. It suggests answering four questions:

  • what are you building,
  • who is it for,
  • why will they use it,
  • what is the one key action.

If you do that, your prompts produce cleaner output and less rework.

The 10-minute website brief (copy/paste)

Fill this out in plain language:

  • Site type: (portfolio, agency, product landing page, internal portal)
  • Audience:
  • Primary CTA: (book a call, request demo, join waitlist, buy, contact)
  • Secondary CTA: (newsletter, download, follow)
  • Proof: (testimonials, logos, case study, numbers, screenshots)
  • Pages: (Home, About, Services, Case Studies, Blog, Contact)
  • Brand vibe: (minimal, bold, playful, enterprise, editorial)
  • Constraints: (must load fast, must rank for X, must be mobile-first)

If you want a structured version that becomes build instructions, use the Mini PRD Generator and treat your website as a product with acceptance criteria.

Step 2: Use Plan mode to design the structure

Plan mode exists to think and decide before code is written. Lovable describes Plan mode as decision-making, and explicitly says it never modifies your code.

This is perfect for website planning because you can explore structure without committing to implementation.

What to ask for in Plan mode (website edition)

Ask Plan mode for:

  • A page map (routes)
  • A section map per page (hero, proof, features, FAQs, CTA)
  • A copy outline (headlines + bullets)
  • A “trust story” (why you, why now)
  • A list of needed assets (images, screenshots, logos)

Plan mode prompt (copy/paste):

I want to create a website with Lovable.
Site type: [type].
Audience: [audience].
Primary CTA: [CTA].
Proof we have: [proof].
Pages needed: [pages].
Brand vibe: [vibe].

Output:

  1. Sitemap and page goals
  2. Section layout per page
  3. Draft copy outline (headline + 3 bullets per section)
  4. Asset list
  5. A strict cut list (what NOT to add yet)

Plan mode is designed to ask clarifying questions and generate a structured plan you can inspect and refine.

Step 3: Use Agent mode to build sections, not the whole site

Agent mode is where Lovable implements and verifies changes directly, executing end-to-end tasks across your project.

The mistake is asking for everything at once.

Lovable’s prompting guide recommends prompting by component or section because it improves clarity and control, and lets you fix one block without re-prompting the entire page.

Lovable Agent Mode

The “section-by-section” build sequence

Build in this order:

  1. Global layout: header, footer, navigation
  2. Home hero section (headline, subhead, CTA)
  3. Proof section (logos, testimonials, metrics)
  4. Offer section (what you do, how it works)
  5. Secondary CTA section (newsletter, download, waitlist)
  6. Contact section (form, email, links)
  7. Then repeat for other pages

Use real content, not filler

Lovable explicitly warns that it does not work well with lorem ipsum or generic placeholders, and recommends using real words to communicate intent and improve layout decisions.

That is especially important for websites because copy is the design.

Website prompt templates (copy/paste)

Hero section prompt

Create a hero section for [site type].
Headline: “[exact headline]”
Subheadline: “[exact subheadline]”
Primary CTA button: “[CTA text]” links to [destination].
Secondary link: “[secondary CTA]” links to [destination].
Layout: [centered/left aligned], mobile-first, strong spacing, accessible contrast.

Proof section prompt

Add a proof section under the hero.
Include: [testimonials/logos/metrics].
Make it scannable.
If data is missing, add placeholders that I can easily replace.

Contact section prompt

Add a contact section with a form: name, email, message.
Validate email format and show inline errors.
After submit, show a clear success state and send the message to [email / endpoint].

Agent mode’s docs show it’s designed to implement changes and verify outcomes, including debugging.

Step 4: Add forms and interactions safely

Most websites need at least one interactive element:

  • contact form
  • newsletter form
  • booking link
  • waitlist form

The safe default: keep it simple

For a first version:

  • store submissions (so you don’t lose leads)
  • send a notification (email or Slack)
  • show a clear success state
  • prevent spam with basic measures (later: rate limits, CAPTCHA)

If you need auth, database, or “real app” features

Lovable is designed for web apps and can include database/auth/integrations, but that changes your scope.

If your “website” is turning into:

  • a customer portal,
  • a dashboard,
  • a paid membership area,

switch mental models and follow the app playbook:

Step 5: Publish your website

Publishing is where most “website builders” are simple. Lovable is more flexible because it supports different access policies.

Lovable’s publish docs explain you can choose who can access a published app, including workspace-only access on Business/Enterprise plans vs anyone with the link for public publishing.

Pick your access policy

Choose one:

  • Public website: anyone with the link can visit.
  • Internal website: workspace members only (useful for internal portals).

This matters for ops teams building internal sites.

If you’re building an internal ops portal and wondering whether to keep it in Airtable or move to a custom system, this guide helps: Airtable vs custom app. For spreadsheet-driven processes: replace a spreadsheet with a web app.

Set metadata that makes your site look real

Lovable’s publish flow includes “website info” metadata for SEO and social previews:

  • favicon and title
  • meta description
  • social share image (OG image)

Do this before you share the link widely, especially if you’re posting on LinkedIn or sending in DMs.

Step 6: Connect a custom domain (and fix DNS issues)

A custom domain is the difference between “cool prototype” and “real website.”

Lovable’s custom domain docs list prerequisites:

  • paid Lovable plan,
  • project must be published,
  • you own a domain (can be purchased within Lovable via IONOS),
  • you have DNS access,
  • you must add DNS A and TXT records for verification,
  • and you should not have AAAA records for the domain because they can interfere with setup.

The custom domain flow, simplified

  1. Publish your project first.
  2. Add your domain in Lovable.
  3. Copy the DNS records Lovable gives you (A and TXT).
  4. Add them at your DNS provider.
  5. Wait for verification and SSL issuance, the domain becomes Live and your site is live.

DNS gotchas Lovable explicitly warns about

  • DNS propagation can take up to 72 hours, often faster.
  • AAAA (IPv6) records can interfere and route traffic incorrectly.
  • Hostname format varies by DNS provider, sometimes it’s @, blank, or the full domain.

If you’re building client websites, this is the step that causes the most friction because clients often don’t have DNS access. In that case, you can still publish on the default Lovable domain first, then connect a custom domain later when access is available.

Step 7: Security basics for a Lovable website

If your site is purely static content, security is mostly about:

  • your domain,
  • forms,
  • not leaking secrets.

If your “website” becomes an app (logins, data, payments), security becomes core.

Lovable’s security overview describes built-in tools: API key detection, database access controls, and AI-powered security scanning during development and before publishing, while noting these do not replace a thorough security review and you remain responsible for your app’s security requirements.

Lovable Security best practices

Protect API keys the right way

Lovable explicitly recommends not pasting credentials directly, and describes a secure pattern:

  • store API key in Secrets,
  • create an Edge Function to call the API server-side,
  • call that function from the frontend.

That’s the difference between a safe website and “I accidentally leaked my keys in the browser.”

Use RLS when your website has user data

Lovable highlights row-level security (RLS) policies as a control mechanism for which users can access or modify data, and warns that misconfigured RLS is a common cause of data leaks.

If you are building anything multi-user, treat “permissions” as a first-class feature, not a checkbox.

Run a security review before launch

Lovable supports conversational security reviews, and suggests requesting reviews after significant changes or before major releases.

Even for a “simple website,” this is useful if you added:

  • custom APIs
  • edge functions
  • auth
  • data

Step 8: Launch checklist and iteration plan

A website launch is not “publish and forget.” It’s “publish, measure, iterate.”

Pre-launch checklist (copy/paste)

  • Content
  • No lorem ipsum, no placeholders (Lovable warns against fake content).
  • Proof exists (testimonials, screenshots, numbers)
  • UX
  • Mobile looks good
  • CTA appears above the fold
  • Forms validate and show success states
  • Technical
  • Published with correct access policy (public vs internal)
  • Metadata set (title, description, share image)
  • Custom domain connected (if ready), SSL live
  • Security
  • No API keys in frontend, secrets stored properly
  • Run a security review if you added backend behavior

What to measure in week one

For a marketing website:

  • CTA conversion rate (clicks, form submits)
  • Where people drop (scroll depth, page exits)
  • Source quality (LinkedIn vs Google vs direct)

For a website that becomes an app:

  • activation rate (first meaningful action)
  • retention signals (return visits, repeat actions)
  • support burden (what confuses users)

If you’re scoping the “app next” version, use the MVP Cost Estimator. It’s scope-first and scores complexity based on things that actually drive time and cost (platforms, auth, payments, roles, integrations).

When to bring in a team

You can create a strong website with Lovable solo.

Bring in help when:

  • SEO becomes a primary growth channel and you need deeper control
  • the website becomes a multi-user app with permissions and data boundaries
  • you need payments and entitlements
  • you need reliable deployments and monitoring
  • you’re spending more time debugging than shipping improvements

If you’re choosing between a freelancer and an agency, use: Freelancer vs agency risk checklist.

If you want a done-for-you build path, here are the next steps:

FAQ

Can Lovable build a website, or is it only for apps?

Lovable supports building websites and marketing pages, and it also supports full web applications with deployable code and backend capabilities.

What’s the difference between Plan mode and Agent mode?

Plan mode is for thinking and deciding before code is written, and it never modifies your code. Agent mode implements and verifies changes directly in your project.

How do I write prompts that actually produce good website sections?

Plan first (what, who, why, key action), prompt by component/section, and use real content instead of placeholders.

Can I publish privately first?

Yes. Publishing can be restricted to workspace members on certain plans, or you can publish publicly to anyone with the link.

Do I need a paid plan for a custom domain?

Lovable’s custom domain docs list being on a paid plan as a prerequisite, along with having a published project and DNS access.

Why is my domain not verifying?

Common reasons: DNS records incorrect, DNS propagation delay (can take up to 72 hours), or an AAAA record interfering with routing.

What security basics matter for a simple website?

Don’t expose API keys, use Secrets and server-side functions for API calls, and run security reviews if you add backend behavior.

When should I stop treating it as a “website” and start treating it as an “app”?

When you add logins, user data, roles, dashboards, or payments, you need app-level guardrails (permissions, RLS, testing, monitoring).

Conclusion

Creating a website with Lovable is fastest when you do three things:

  1. Plan the message and the one key action first
  2. Use Plan mode to structure, then Agent mode to build section-by-section
  3. Publish with metadata, connect a custom domain, and avoid common DNS and security mistakes

If you want the website to become a real product, or you want it shipped with clear scope boundaries, check:

Share this article