Type “build me a CRM” into Lovable, and you won’t get a wrong app. You’ll get a question.
Lovable recognizes that “CRM” describes a category, not a specification, so before it builds anything, it asks: “What’s the core scope for your CRM?” with checkboxes for things like Contacts & companies, Deals/pipeline, Tasks & activities, and Multi-user with auth, plus a “write your own” option.
The right website builder can help creators turn great prompts into polished digital projects and online brands. The platforms in the table below are worth comparing for their ease of use, flexibility, and features that support fast site creation. See our recommended website builders here.
Top Website Builders for Creators Turning Prompts Into Projects
| Provider | User Rating | Recommended For | |
|---|---|---|---|
 | 4.6 | Beginners | Visit Hostinger |
 | 4.4 | Pricing | Visit IONOS |
 | 4.2 | Design | Visit Squarespace |
Select what you need, hit Next, and Lovable builds toward those choices.
This is a real feature, and it’s the reason a one-line prompt in Lovable produces a far better starting point than a one-line prompt in most AI app builders.
But the checkboxes can only ask about scope. They have no way to ask:
- What stages your sales pipeline has
- What fields your contacts need
- Or what the finished app should actually look like
Those details still have to come from somewhere.
If they come from you upfront, in your first prompt, Lovable builds toward all of it at once: the scope and the specifics, with nothing left to clarify afterward. If they don’t, you’ll spend your next few prompts answering, one at a time, exactly what the checkboxes couldn’t ask.
This guide is about closing that second gap, the one between “Lovable knows roughly what you want” and “Lovable has everything it needs to build it right the first time.”
In this guide, you’ll find:
- A framework for structuring any prompt so it answers both the scope question and the details behind it
- Six before-and-after examples covering the most common projects people build in Lovable
- A set of prompts for fixing the specific things that go wrong mid-build
The Five Things a Working Prompt Includes
Every prompt that produces a usable result, across any app type, tends to specify the same five things. The first two are close to what Lovable’s scope-clarification screen already asks about.
The other three are what it has no way to ask about at all, which is exactly where most follow-up prompts end up going.
1. What the app actually does, in concrete terms
Not “a CRM,” but “a contact management tool where I can add a contact’s name, company, email, and a status (lead, customer, churned), and filter the list by status.” The second version describes a screen, not a category.
2. Who uses it and what they can see
If more than one type of person will use the app, say so from the start. “Admins can see all requests, customers can only see their own” is a sentence Lovable can act on directly. Adding this after the fact, once the database and pages already exist without role logic, takes considerably more back-and-forth.
3. The data model, even informally
You do not need to write a formal schema. Listing the fields matters: “each project has a name, a client, a budget, a status (not started, in progress, complete), and a due date” gives Lovable exactly what it needs to create the right database table in Supabase, with the right columns, the first time.
4. Design direction, even minimal
“Clean and professional” means nothing specific. “Deep navy and white, rounded cards, generous whitespace, similar to Linear’s interface” gives the AI an actual visual target. You can also reference real brands: “write the copy in a confident, slightly playful tone, similar to how Mailchimp or Notion write their marketing copy” works as a direction for tone, not just visuals.
5. One task, not five
This is the one you’re most likely to skip. A prompt that asks for the database, the UI, the authentication, the Stripe integration, and a dark mode toggle in one message will get you partial attempts at all five rather than a complete version of any. Lovable’s own documentation recommends thinking in iterations: lock the layout, then add content, then wire up logic, checking the result at each stage rather than requesting everything at once.
Here is the same project idea, written the weak way and the strong way, before moving into full examples by app type:
Weak: “Build me an app for tracking client projects.”
Strong: “Build a project tracker for a small design agency. Each project has a name, a client name, a budget, a status (not started, in progress, complete, on hold), and a due date. Show all projects in a table on the main page, with the ability to filter by status. Use a clean layout with a sidebar for navigation, and a soft blue and gray color palette.”
The second prompt is longer, but it describes a screen Lovable can build correctly on the first attempt. The first prompt describes a feeling.
Six Prompts That Work, by Project Type
These six examples cover the project types that come up most often: a marketing page, an internal dashboard, a client portal with logins, an online store, a CRM, and a booking app.
Each weak prompt below might trigger a scope-clarification screen like the CRM example, get built as a reasonable best guess, or land somewhere between the two.
What they all share is the same gap: the specific details, your data fields, your business context, your design direction, that no clarification screen can ask about. The strong prompt for each one fills that gap directly.
1. Landing Page or Marketing Site
Weak prompt: “Create a landing page for my new app.”
What this produces is technically a landing page: a hero section, a few feature cards with generic icons, a pricing table with placeholder numbers, and a footer. It’s not wrong, but it’s also not yours.
The headline will be generic, the feature descriptions will not match your product, and the pricing tiers will be invented.
Strong prompt:
“Build a landing page for a habit-tracking app called Streakly. The hero section should have the headline ‘Build habits that actually stick’ with a subheadline about tracking daily habits with visual streaks. Below that, add a three-column feature section covering: streak tracking with visual calendars, daily reminders, and progress sharing with friends. Add a pricing section with two tiers: Free (basic tracking, 3 habits) and Pro at $5/month (unlimited habits, streak history, friend leaderboards). Use a warm, energetic color palette with orange as the primary accent color. Write the copy in an encouraging, motivational tone, similar to how Headspace or Duolingo write their marketing copy.”
What changes:
| Element | Weak Prompt | Strong Prompt |
| Headline | AI invents something generic | “Build habits that actually stick” |
| Feature descriptions | Generic, won’t match your product | Streak tracking, daily reminders, and friend sharing, named explicitly |
| Pricing | Invented placeholder tiers | Free and Pro ($5/month), each with specific features listed |
| Tone | “Professional and modern” gives no real target | References Headspace and Duolingo as concrete style anchors |
2. SaaS Dashboard or Internal Tool
Weak prompt: “Build me a dashboard for my business.”
A prompt this open might lead Lovable to ask what kind of dashboard you need, sales, operations, finance, or it might build a generic dashboard with placeholder metrics like “Total Sales” and “New Users” that have nothing to do with your business. Either way, what’s missing is what your business actually tracks.
Strong prompt:
“Build an internal dashboard for a small landscaping business. The main page should show four summary cards at the top: Active Jobs, Jobs Completed This Week, Revenue This Month, and Upcoming Estimates. Below the cards, show a table of active jobs with columns for Client Name, Service Type (mowing, landscaping, snow removal), Scheduled Date, and Status (scheduled, in progress, completed). Add a sidebar with navigation for Dashboard, Jobs, Clients, and Settings. Use a clean layout with a white background, dark gray text, and green as the accent color for status badges.”
What changes:
| Element | Weak Prompt | Strong Prompt |
| Summary cards | Generic (“Total Sales,” “New Users”) | Active Jobs, Jobs Completed This Week, Revenue This Month, Upcoming Estimates |
| Table columns | Unspecified | Client Name, Service Type, Scheduled Date, Status |
| Database schema | Built around guessed metrics | Jobs table with service type and status fields, matching the real business |
| Navigation | Unspecified | Sidebar with Dashboard, Jobs, Clients, Settings |
3. Client Portal With Login and User Roles
Weak prompt: “I need a portal where my clients can log in and see their projects, and I can manage everything as the admin.”
This prompt is closer to working than the previous two because it mentions login and two user types, but it does not specify what “see their projects” or “manage everything” actually means on screen. The result is often a login page that looks correct but a dashboard that does not differentiate between what an admin sees and what a client sees, because the distinction was implied rather than stated.
Strong prompt:
“Build a client portal for a marketing agency with two user roles: Admin and Client. Use Supabase for authentication and the database. Admins can see a list of all clients and all projects, with the ability to create new projects and assign them to a client. Each project has a name, a status (planning, in progress, review, complete), and a list of deliverables (each deliverable has a name and a status: not started, in progress, done). Clients can only see their own projects and the deliverables within them, and can mark a deliverable as ‘approved’ but cannot edit anything else. Use a professional blue and white color scheme with a sidebar navigation showing different menu items depending on the logged-in user’s role.”
What changes:
| Element | Weak Prompt | Strong Prompt |
| Authentication | Implied, not built | Supabase auth and row-level security set up from the start |
| Admin permissions | Vague “manage everything” | Create projects, assign to clients, full visibility across all projects |
| Client permissions | Vague “see their projects” | View own projects and deliverables, can mark deliverables “approved” |
| Role distinction | Same screen for everyone | Sidebar navigation changes based on the logged-in user’s role |
4. E-commerce Store With Stripe Checkout
Weak prompt: “Build me an online store to sell my products.”
A prompt this broad leaves Lovable to either ask what you’re selling or build a generic product grid with placeholder items, prices, and images, with no specified checkout flow. Either way, what’s missing is what’s actually being sold and how payment should work.
Strong prompt:
“Build an online store for a small business selling handmade candles. The homepage should show a grid of products, each with an image, name, scent description, and price. Include categories for Seasonal, Signature, and Gift Sets. Each product page should have a larger image, full description, price, and an ‘Add to Cart’ button. Use Stripe for checkout, with a cart page showing selected items, quantities, and a total, and a checkout flow that collects shipping address and processes payment. Use a warm, neutral color palette (cream, soft brown, sage green) with a minimal, boutique feel similar to brands like Otherland or Brooklyn Candle Studio.”
What changes:
| Element | Weak Prompt | Strong Prompt |
| Checkout | “Buy Now” button with no logic behind it | Stripe checkout, cart page, shipping address collection |
| Product categories | Flat product list | Seasonal, Signature, and Gift Sets built into the data model |
| Product details | Generic placeholders | Image, name, scent description, and price for each product |
| Aesthetic | “Modern and clean” gives no real target | Cream, soft brown, sage green, referencing Otherland and Brooklyn Candle Studio |
5. CRM or Data Management Tool
Weak prompt: “I want something like a simple CRM to keep track of my contacts and deals.”
A prompt like this is exactly the kind that triggers Lovable’s scope-clarification screen, the same “What’s the core scope for your CRM?” question with checkboxes for Contacts & companies, Deals/pipeline, Tasks & activities, and Multi-user with auth. Selecting all four gets you a real CRM structure. What the checkboxes can’t tell Lovable is what fields your contacts and deals actually need, what stages your pipeline has, or what the app should look like, which is exactly where the strong prompt picks up.
Strong prompt:
“Build a contact and deal tracker for a freelance consultant. The main page should show a table of contacts with columns for Name, Company, Email, and Status (lead, active client, past client). Clicking a contact should open a detail view showing their information plus a list of associated deals, where each deal has a name, value, stage (prospecting, proposal sent, negotiation, won, lost), and a notes field. Add a separate page showing all deals grouped by stage in a kanban-style board, where I can drag deals between stages. Use a minimal, neutral color palette with blue accents for status badges.”
What changes:
| Element | Weak Prompt | Strong Prompt |
| Contact fields | Unspecified | Name, Company, Email, Status (lead, active client, past client) |
| Deal fields | Unspecified | Name, value, stage, notes |
| Relationships | Not defined | Contacts linked to deals, deals linked to stages |
| Pipeline view | Not requested | Kanban board grouped by stage, with drag-between-stages support |
6. Booking or Scheduling App
Weak prompt: “I need an app where customers can book appointments with me.”
A prompt this general leaves the actual booking logic, available time slots, what happens after a booking is made, whether double-bookings are prevented, for Lovable to guess at, usually resulting in a calendar-shaped page that does not actually check availability. What’s missing is the business’s real scheduling rules.
Strong prompt:
“Build a booking app for a hair salon with one stylist. Customers should see a list of services (Haircut, 30 min; Color, 90 min; Blowout, 45 min) with prices, then pick a service and see available time slots for the next two weeks based on a 9am to 5pm schedule, Tuesday through Saturday. Once a customer selects a time slot, ask for their name and phone number, then confirm the booking and mark that time slot as unavailable for other customers. Add an admin view where I can see all upcoming bookings in a list, sorted by date, with the ability to cancel a booking, which should make that slot available again. Use Supabase to store services, time slots, and bookings. Use a soft pink and white color scheme.”
What changes:
| Element | Weak Prompt | Strong Prompt |
| Services | Unspecified | Haircut (30 min), Color (90 min), Blowout (45 min), each with a price |
| Availability | Calendar shows dates, doesn’t track availability | 9am-5pm, Tuesday-Saturday, real slot availability |
| Booking flow | Unspecified | Collects name and phone, marks the slot unavailable, confirms the booking |
| Admin view | Not requested | List of upcoming bookings, with cancel reopening the slot |
| Database | Not specified | Supabase tables for services, time slots, and bookings |
Fixing What Goes Wrong: Iteration Prompts That Work
Even a well-structured first prompt rarely produces a finished app. What happens next, how you prompt for fixes and additions, matters just as much as the first prompt did.
One Change Per Prompt
Lovable’s own prompting documentation is direct about this: make one meaningful change at a time, then check the result before moving on.
A prompt like “change the button color to green, add a dark mode toggle, fix the spacing on the pricing page, and add a footer with social links” asks for four unrelated changes in one message. If the result has a problem, you will not know which of the four changes caused it.
Instead, four separate prompts:
- “Change the primary button color to green across the entire app.”
- “Add a dark mode toggle in the top navigation bar.”
- “Fix the spacing on the pricing page so the cards have more padding and breathing room.”
- “Add a footer with links to our Twitter, LinkedIn, and Instagram pages.”
Each one is small enough to verify before moving to the next. This also keeps credit usage predictable: four small, targeted prompts at roughly 0.5 to 0.7 credits each cost less in total than one large prompt that has to be partially redone because one of the four changes broke something else.
Fixing a Broken Supabase Connection
A common error in Lovable looks like “Uncaught Error: Missing Supabase environment variables,” usually appearing as a blank white screen in the preview.
This happens when a feature that needs the database, like authentication or a data table, was generated before Supabase was connected, or when the connection was interrupted.
The fix prompt is straightforward:
“The app is showing a blank screen with a Supabase environment variable error. Please fix the missing Supabase configuration and reconnect the database.”
Lovable’s built-in “Try to fix” option, which appears alongside error banners, often resolves this automatically.
If it does not, describing the exact error message in a prompt, copied directly from the error banner, gives the AI the specific detail it needs rather than a general “something is broken” report.
Fixing Contradictory or Unclear Logic
Lovable’s AI does not push back when a prompt contains a contradiction. If you ask for “role-based permissions so admins and clients have different access, but also make sure everyone can edit everything,” the AI will attempt to satisfy both halves, usually by implementing roles that do not actually restrict anything.
If you notice permissions are not working as expected, the fix is to remove the ambiguity directly:
“Currently, clients can edit all projects, but they should only be able to view their own projects and mark deliverables as approved. Admins should retain full edit access to everything. Please update the permission rules so clients cannot edit, create, or delete any project data.”
This works because it states the desired end state explicitly, rather than describing a change relative to a previous (and possibly already-confused) instruction.
Using the Visual Editor for Small Tweaks
Not every change needs a prompt. Lovable’s visual editor lets you click an element directly in the preview and adjust text, colors, spacing, and sizing without using a credit.
For small, cosmetic changes, moving a button, changing a heading’s font size, adjusting a margin, the visual editor is faster and free. Save prompts for changes that affect logic, data, or multiple components at once: things the visual editor cannot reach.
A reasonable rule of thumb: if the change is “make this one thing look slightly different,” use the visual editor. If the change is “make the app behave differently” or “add something new,” write a prompt.
Requesting a Refactor Before It’s Needed
As a Lovable project grows, file structure can get messy, especially after many small prompts stacked on top of each other. Lovable’s AI often suggests refactoring on its own, but you can request it directly:
“The codebase has grown messy after several rounds of changes. Please refactor the components for the dashboard page to reduce duplication and improve organization, without changing how anything looks or functions.”
The “without changing how anything looks or functions” clause matters. Without it, a refactor prompt can sometimes introduce visual changes as a side effect because the AI treats “refactor” as an opportunity to also improve things it was not asked to improve.
A Quick Reference Before Submitting a Prompt in Lovable
Before submitting a prompt in Lovable, run it against these five questions:
- Does it describe a specific screen or feature, not a category of app?
- Does it specify who uses the app and what each type of user can see or do, if there is more than one?
- Does it list the actual fields or data points involved, even informally?
- Does it give a real design direction, ideally with a reference point (a brand, a color palette, a specific feel)?
- Is it one task, not several bundled together?
A prompt that answers yes to all five will not guarantee a perfect result, Lovable’s AI still makes mistakes, generates the occasional nested error, and sometimes needs a second pass on mobile layouts. But it will produce something close enough to what you described that the next prompt can be a refinement rather than a rebuild.
