Prompting Guide

The Instruction Quality Problem

A senior partner at a CA firm gives different quality instructions to a junior assistant depending on how they frame the request.

Version A: "Prepare the client file."

The junior associate does not know which client, what kind of file, in what format, by when, or for what purpose. They will either guess and get it wrong, or come back and ask three follow-up questions.

Version B: "Prepare Sharma Industries' FY25 audit file — include the trial balance from Tally, last year's financials for comparison, and a reconciliation of the opening balances. We need it by Thursday because the audit team arrives Friday morning."

The junior associate knows exactly what to do.

Lovable works the same way. Vague instructions produce generic results. Specific instructions produce exactly what you need.

The Spectrum: Vague to Precise

Here is the same app request written at five different levels of specificity. Notice how the output quality changes.

Level 1 — Too Vague

Prompt: "Make a dashboard."

Lovable produces a generic dashboard with placeholder charts, random KPI cards with made-up metrics, and a layout that has nothing to do with your actual use case. It has to guess everything — what the dashboard is for, who uses it, what data it shows. You will spend 30+ minutes in follow-up corrections undoing the assumptions.

Level 2 — Slightly Better

Prompt: "Make an invoice dashboard for a CA firm."

Something closer — Lovable knows it is about invoices and CA firms. But it still guesses at the specific fields, the layout priority, and the design style. Expect 15–20 minutes of follow-up corrections.

Level 3 — Getting There

Prompt: "Make an invoice dashboard for a CA firm with a table showing client name, invoice amount, due date, and whether it's been paid."

A table with the right columns appears. But the visual design is still generic, there is no summary section, and the status field is probably plain text rather than a color-coded badge. Expect 10 minutes of design and layout corrections.

Level 4 — Good

Prompt: "Build an invoice tracker dashboard for a CA firm. Show 3 summary cards at the top: Total Invoices This Month, Total Amount Collected, and Total Amount Overdue. Below the cards, show a table with columns: Client Name, Invoice Number, Amount (₹), Invoice Date, Due Date, Status (Paid/Unpaid/Overdue). The status column should be color-coded — green for Paid, yellow for Unpaid, red for Overdue. Use a clean, professional design with white background and navy blue headers."

Extremely close to what you want. The structure, the fields, the colors, the layout — all specified. Expect only 2–3 targeted follow-up changes.

Level 5 — Precise

Prompt: "Build an invoice tracker dashboard for a CA firm. Layout: navigation bar at top with firm name 'Mehta & Associates' and a bell icon for notifications. Main content area has two sections: left section (70% width) contains 3 KPI cards in a horizontal row showing — Total Invoices This Month (count), Total Collected (₹ sum of paid invoices), Total Overdue (₹ sum of overdue invoices — this card should have a red background). Below the KPI cards, show an invoice table with columns: Client Name (link, opens client detail), Invoice Number, Amount (₹ formatted with commas, like ₹1,25,000), Invoice Date (DD MMM YYYY format), Due Date (DD MMM YYYY format), Status (badge — green chip for 'Paid', orange chip for 'Unpaid', red chip for 'Overdue'), Actions (View PDF, Send Reminder buttons). Right section (30% width): upcoming deadlines panel showing clients whose invoices are due in the next 7 days, sorted by earliest first. Design: white background, #1e3a5f navy blue for headers and navigation, #27ae60 green for paid status, #e74c3c red for overdue. Font: clean sans-serif. Add 5 realistic sample rows for a CA firm (Indian company names, realistic amounts between ₹15,000 and ₹2,50,000)."

Exactly the app you described, ready to use immediately with perhaps one or two minor tweaks.

The Five Elements of a Great Prompt

Every good Lovable prompt covers these five areas. You do not need all five for every project — but the more you include, the more accurate the result.

1. Purpose and Context

Tell Lovable what the app is for and who uses it.

• Not: "a form"
• Yes: "an expense submission form for company employees to submit reimbursement requests to their finance manager"

Context shapes every decision Lovable makes — the terminology it uses, the workflow it assumes, the kind of data it prepopulates as examples.

2. Layout and Structure

Describe the physical arrangement of the screen.

• Not: "show the data"
• Yes: "three cards in a horizontal row at the top, then a searchable table below"

Words that help: sidebar, top navigation, left panel, right panel, tabs, modal popup, cards in a grid, horizontal row, stacked vertically, full-width, split view.

3. Data Fields

List the exact fields you need, with their data types if it matters.

• Not: "client information"
• Yes: "client name, PAN number, GSTIN, phone number, email, city, last filing date (date field), outstanding amount (number in rupees)"

If a field has specific options (like a dropdown), list them: "status field with options: Active, Inactive, Under Audit, Follow-up Needed".

4. Visual Style

Describe how you want it to look.

• Colors: "navy blue and white", "dark background like a financial terminal", "light gray with green accents"
• Feel: "clean and minimal", "professional like a bank dashboard", "modern with rounded cards"
• Specific elements: "color-coded status badges", "data table with alternating row colors", "prominent red for overdue items"

5. Sample Data

Ask Lovable to include realistic example data.

"Add 8 sample rows with realistic Indian company names and amounts between ₹50,000 and ₹5,00,000."

This makes the preview look like a real app immediately, which makes it easier to evaluate whether the design is working.

Effective Follow-Up Instructions

After the initial generation, you will almost always want to refine. Here is how to make follow-up instructions work well:

Be specific about what to change, not just what is wrong:

• Not: "The table looks bad."
• Yes: "The table rows are too tall. Reduce the row height so I can see more rows without scrolling."

Reference specific elements by name:

• Not: "Fix the top part."
• Yes: "The KPI cards at the top — change the 'Total Overdue' card background from gray to red so it stands out as urgent."

One change at a time for precise control:

If you ask for five changes in one message, Lovable may implement them all but introduce a new issue in one. Smaller, focused requests are easier to evaluate and roll back if needed.

Say what you want, not what you do not want:

• Not: "Do not make it look boring."
• Yes: "Add more visual hierarchy — make the KPI card numbers larger and bolder, and add a thin colored border on the left side of each card."

5 Complete Example Prompts for CA Scenarios

These are ready-to-use prompts. Copy and modify them for your own projects.

Common Mistakes and How to Fix Them

Mistake 1: Asking for everything in one prompt

A prompt describing a complete multi-page application with ten features will produce something that tries to do everything and does nothing well. Start with the core screen, get it right, then add features one by one.

Mistake 2: Using internal jargon without explaining it

Terms like "FORM 26AS", "Schedule III compliance", or "CARO reporting" are obvious to you but not to Lovable. Either explain what they mean in context, or use simpler terminology that describes the function: "a tax deducted at source reconciliation screen showing what the company deducted and what has been deposited with the government."

Mistake 3: Describing the data without describing the layout

Listing all your fields without saying how they should be arranged produces a technically complete but visually awkward result. Always pair field lists with layout instructions: "the fields on the left, a status summary panel on the right."

Mistake 4: Not asking for sample data

An app with empty tables looks broken, even if it is technically correct. Always ask for realistic sample data in your initial prompt. It makes the preview look real, which makes evaluation much easier.