Build the UI first, wire the data after. A SaaS dashboard is a stack of predictable parts, a shell, some charts, a table, admin pages, and the states in between, and Lovable builds each one fast when your prompt names the components, the columns, the chart types, the filters, and every loading, empty, and error state. Each prompt below is scoped to a single task so Build Mode makes clean edits, and you can use Chat Mode to plan and Visual Edits to nudge spacing without spending credits.
New to this? Start with our best Lovable prompts, then see Lovable prompts for full-stack apps when you are ready to add a backend, and keep the Lovable prompt cheat sheet open for phrasing that keeps edits surgical.
App shell & navigation
The shell is the frame every other screen lives in. Get the sidebar, topbar, and grid right first so new pages inherit a consistent layout.
1. Dashboard layout with collapsible sidebar and topbar
Build the main dashboard shell for a SaaS app called [App Name]. Layout: a fixed left sidebar (240px) with the app logo at top, primary nav items (Overview, Analytics, Customers, Billing, Settings) each with an icon and label, and a user avatar with a dropdown at the bottom. The sidebar collapses to a 64px icon-only rail via a toggle button, and collapses to an off-canvas drawer below the md breakpoint. Add a topbar with a page title on the left, a global search field, a notifications bell with an unread badge, and the user avatar on the right. The main area is a scrollable content region with comfortable padding. Use React and Tailwind, my Knowledge file design system, and highlight the active nav item. Keep it responsive.Why it works: It fixes exact widths, breakpoints, and nav items, so Lovable produces a reusable shell instead of guessing at structure.
2. Analytics overview with KPI stat cards
Create the Overview page inside the dashboard shell. Top row: four KPI stat cards showing MRR, Active Users, Churn Rate, and Trial Conversions. Each card has a label, a large value, a small delta vs last period (green up / red down with an arrow), and a tiny sparkline. Below the cards, add a two-thirds / one-third split: a large area chart of revenue over the last 30 days on the left, and a compact list of top plans on the right. Use placeholder data for now. Include a loading skeleton for every card and chart, and an empty state if a metric has no data. Match my Knowledge file design system.Why it works: Naming each KPI, the delta styling, and the split layout gives you a real overview page, not a generic hero.
3. Responsive grid layout
Refactor the Overview page to use a responsive 12-column grid. On desktop (lg+): KPI cards span 3 columns each (4 across), the main chart spans 8 columns, the side panel spans 4. On tablet (md): KPI cards go 2 across, chart and panel stack full width. On mobile (below md): everything stacks to a single column with consistent gap spacing. Keep all existing components and data the same; only change the layout and breakpoints.Why it works: Explicit column spans per breakpoint prevent the cramped or overflowing grids dashboards usually ship with.
4. Command palette and global search
Add a command palette that opens with Cmd/Ctrl+K and from the topbar search field. It is a centered modal with a search input and grouped results: Pages (Overview, Analytics, Customers, Billing, Settings), Recent customers, and Actions (Invite user, Create report, Open docs). Filter results live as I type, support arrow-key navigation and Enter to select, and Escape to close. Show an empty state ("No results for [query]") when nothing matches. Keep everything else the same; only add the command palette.Why it works: It specifies the shortcut, result groups, keyboard behavior, and empty state, so search is usable rather than decorative.
Charts & data views
These are the screens users stare at all day. Be specific about chart type, table columns, filters, and interactions.
5. Line and bar charts from data
On the Analytics page, add two charts using a React charting library. Chart 1: a line chart of Daily Active Users over time, with a smooth line, hover tooltip showing date and value, and a range selector (7d / 30d / 90d). Chart 2: a grouped bar chart of Revenue by Plan (Free, Pro, Team) per month for the last 6 months, with a legend and axis labels. Both charts resize to their container and use my Knowledge file color palette. Include a skeleton while loading and an empty state ("No data for this range") when the series is empty. Use placeholder data.Why it works: It picks the chart type per metric and defines tooltips, ranges, and empty states so the visuals are complete on first pass.
6. Sortable, filterable, paginated data table
Build a Customers data table. Columns: Name (with avatar), Email, Plan (badge), MRR, Status (Active / Trial / Churned badge), Signup Date, and a row actions menu (View, Edit, Delete). Features: click a column header to sort ascending/descending; a search field that filters by name or email; a Plan filter dropdown and a Status filter dropdown; a page size selector (10 / 25 / 50) with pagination controls showing "X-Y of Z". Add a header checkbox for select-all and a bulk actions bar when rows are selected. Include a loading skeleton with placeholder rows and an empty state with an "Add customer" CTA. Use placeholder data and match my design system.Why it works: Every column, filter, and control is named, so you get a production-grade table instead of a static list.
7. Kanban board with drag and drop
Create a Kanban board on a new Deals page. Columns: Lead, Contacted, Demo, Won, Lost. Each card shows a company name, deal value, owner avatar, and a colored priority tag. Support drag-and-drop to move cards between columns and to reorder within a column, updating the card's status. Show a per-column count and total value in each column header. Add a "New deal" button that opens a modal form (company, value, owner, priority). Include an empty column state ("Drop deals here") and a loading skeleton. Use placeholder data.Why it works: It names the columns, card fields, and drag behavior, plus the empty-column state most boards forget.
8. Calendar and schedule view
Add a Schedule page with a month calendar view and a Week/Day toggle. Render events as colored blocks with a title and time; color-code by type (Onboarding, Demo, Renewal, Internal). Clicking a day opens a side panel listing that day's events; clicking an event opens a detail popover with edit and delete. Add "Today" and prev/next navigation, and a "New event" button that opens a form (title, type, date, start/end time). Include a loading skeleton and an empty state for days with no events. Use placeholder data and my design system.Why it works: Defining views, event types, and the click-through detail flow yields a real calendar rather than a static grid.
9. Activity feed
Add an Activity feed panel to the dashboard. Each item shows an actor avatar, a plain-language action ("[Name] upgraded to Pro", "[Name] invited a teammate", "[Name] exported a report"), a relative timestamp ("2h ago"), and an icon by event type. Group items by day with sticky date headers, and add "Load more" pagination. Include filter chips (All, Billing, Team, Reports) at the top. Show a loading skeleton and an empty state ("No recent activity"). Use placeholder data.Why it works: Concrete event copy and grouping make the feed scannable, and the filters keep it useful as volume grows.
10. CSV export and report view
Add CSV export to the Customers table and a Reports page. Export: an "Export CSV" button that downloads the currently filtered rows with all visible columns, respecting active sort and filters, and shows a toast when the file is ready. Reports page: a date-range picker and a metric selector (Revenue, Signups, Churn), rendering a summary card row plus a chart plus a small breakdown table, with a "Download report as CSV" button. Include loading skeletons and an empty state when the range has no data. Use placeholder data and match my design system.Why it works: Tying export to the active filters and adding a toast delivers the behavior users expect, not just a download stub.
Admin & management
Admin screens are where roles, billing, and settings live. Keep prompts scoped to one page so shared components stay stable.
11. User management table with roles
Build a Team / Users management page for admins. A table with columns: User (avatar + name), Email, Role (dropdown: Owner, Admin, Member, Viewer), Status (Active / Invited / Suspended badge), Last active, and actions (Change role, Resend invite, Remove). Above the table: an "Invite user" button opening a modal (email + role), plus a search field and a Role filter. Changing a role updates the badge and shows a confirmation toast; removing a user asks for confirmation. Include a loading skeleton and an empty state with an "Invite your first teammate" CTA. Use placeholder data.Why it works: The role list, per-row actions, and confirmations map directly to what team management needs.
12. Billing and subscription page
Create a Billing page. Sections: current plan card (plan name, price, billing cycle, next invoice date, "Change plan" and "Cancel" buttons); usage meter (seats used / total, with a progress bar); a plan comparison grid (Free, Pro, Team) with feature bullets and a "Current" badge on the active plan; a payment method row with card brand + last 4 and an "Update" button; and an invoice history table (Date, Amount, Status, Download PDF). Wire the plan buttons to open a Stripe checkout later, but stub the actions for now with toasts. Include loading skeletons and empty states. Match my design system.Why it works: Listing every billing section and noting the Stripe hook keeps the page complete and ready to wire.
13. Settings page with tabs
Build a Settings page with a tabbed layout: General, Profile, Team, Notifications, Security. General: workspace name, logo upload, timezone. Profile: name, email, avatar. Notifications: toggle switches grouped by category (Product, Billing, Team) for email and in-app. Security: change password, two-factor toggle, active sessions list with "Sign out" per session. Each tab has its own Save button with a success toast and disabled state until a field changes. Keep tab state in the URL so refresh preserves the active tab. Include loading skeletons. Match my design system.Why it works: Defining the tabs and their fields, plus URL-persisted tab state, produces settings that behave like a real product.
14. Notifications center
Add a notifications center opened from the topbar bell. A dropdown panel with a header ("Notifications", "Mark all read"), tabs (All / Unread), and a list of items each showing an icon by type, a title, a short body, a relative time, and an unread dot. Clicking an item marks it read and navigates to the related page. Add a filter for type (Billing, Team, System) and a "See all" link to a full notifications page with pagination. Update the bell's unread badge count live. Include a loading skeleton and an empty state ("You're all caught up"). Use placeholder data.Why it works: Read-state handling, tabs, and the badge count are spelled out, so the center actually manages notifications.
15. Audit log
Create an Audit Log page for admins. A table with columns: Timestamp, Actor (avatar + name), Action (e.g. "Updated billing plan", "Removed user", "Exported customers"), Target, IP address, and a details expander showing the before/after or metadata as JSON. Filters: date range, actor dropdown, and action-type dropdown. Add search and pagination showing "X-Y of Z". Make rows read-only. Include a loading skeleton and an empty state ("No events for these filters"). Use placeholder data and match my design system.Why it works: An audit log is a filterable read-only table, and naming the columns and expander keeps it precise.
16. Role-based views (admin vs member)
Add role-based views using the roles in my Knowledge file (Admin, Member). Members see Overview, Analytics, and their Profile settings only. Admins additionally see Team/Users, Billing, Audit Log, and all Settings tabs. Hide admin-only nav items and action buttons for members, and guard admin routes so a member who navigates directly sees a "You don't have access" page. Add a small role badge next to the user avatar. Use a current-user role value I can toggle for testing now; I'll wire it to real auth later. Keep everything else the same.Why it works: It defines exactly what each role sees and guards routes, so hidden UI is not the only line of defense.
States, real-time & polish
The states between full and empty are where dashboards feel finished. Name every one, then wire the data and add the extras.
17. Add loading skeletons
Add loading skeletons across the dashboard that match the shape of each component: KPI cards show a shimmer block for the value and delta; charts show a shimmer rectangle at chart height; tables show 6-8 shimmer rows matching the column layout; the activity feed shows placeholder line items. Skeletons appear while data is pending and cross-fade to real content when loaded. Reuse a single Skeleton component with size variants. Keep all data and layout the same; only add the loading states.Why it works: Shape-matched skeletons prevent layout shift, and reusing one component keeps them consistent everywhere.
18. Empty states with CTAs
Add empty states to every list, table, chart, and board. Each empty state has a relevant icon, a short heading, one line of helper text, and a primary CTA button that starts the obvious next action (e.g. Customers -> "Add customer", Deals -> "Create deal", Reports -> "Build report", Activity -> no CTA, just "No recent activity"). Also add a distinct "no results" state for filtered/searched views that offers a "Clear filters" action. Keep everything else the same; only add empty states.Why it works: Distinguishing true-empty from filtered-empty, each with the right CTA, guides users instead of dead-ending them.
19. Error and toast handling
Add error handling and toasts. For failed data loads, show an inline error card with a message and a "Retry" button instead of a broken component. For failed actions (save, delete, invite, export), show a red toast with a clear message; for successes, show a green toast. Add a top-level error boundary that renders a friendly full-page fallback with a "Reload" button if a screen crashes. Toasts auto-dismiss after 4s, stack, and are dismissible. Keep everything else the same; only add error and toast handling.Why it works: Retry cards, action toasts, and an error boundary cover the three failure surfaces users actually hit.
20. Wire charts and tables to Supabase with real-time updates
Enable Lovable Cloud and set up the backend. Create tables: customers (id, name, email, plan, mrr, status, signup_date), deals (id, company, value, owner, priority, status), and activity (id, actor, action, type, created_at). Seed ~30 realistic rows in each. Then replace the placeholder data in the Overview KPIs, the Analytics charts, the Customers table, the Deals board, and the Activity feed with live Supabase queries. Add real-time subscriptions so the UI updates when rows change. Add RLS policies scoped to the user's workspace. Do one table at a time and confirm before moving on. Keep the existing UI and loading/empty/error states intact.Why it works: It defines the schema, seeds data, and asks for real-time plus RLS one table at a time, which keeps Lovable Cloud edits scoped and credit-efficient.
21. Dark mode toggle
Add a dark mode toggle. Put a sun/moon switch in the topbar and in Settings > General. Use Tailwind's dark class strategy driven by my Knowledge file color tokens so charts, cards, tables, badges, and skeletons all adapt. Persist the choice in localStorage and respect the system preference on first visit. Ensure text contrast and chart colors remain readable in dark mode. Keep everything else the same; only add dark mode.Why it works: Driving dark mode from design tokens makes every component adapt at once instead of one screen at a time.
22. Onboarding checklist flow
Add an onboarding checklist for new workspaces. A dismissible card on the Overview page titled "Get started" with a progress bar and steps: Complete your profile, Invite a teammate, Add your first customer, Connect billing, Create a report. Each step shows a check when done, a short description, and a button that jumps to the relevant page or opens the relevant modal. Mark steps complete automatically when the action happens. Hide the card once all steps are done, with a "Dismiss" option earlier. Store progress in the backend. Use placeholder completion states for now.Why it works: Tying steps to real actions and auto-completing them turns the checklist into activation, not a static to-do list.
Want more structure? See Lovable prompt templates for reusable skeletons you can drop these into.
Frequently Asked Questions
How do I build a dashboard in Lovable?
Build the UI first, then wire data. Start with an app shell prompt for the sidebar and topbar, add an analytics overview with KPI stat cards, then add charts and a data table with dummy data. Use Build Mode for structure, Visual Edits for quick tweaks, and Lovable Cloud to add the Supabase backend once the layout is right.
How do I wire charts and tables to real data (Supabase)?
Enable Lovable Cloud, which provisions a native Supabase backend with Postgres, auth, storage, and RLS. Prompt Lovable to create the tables, seed sample rows, then replace mock data in your charts and table with live queries. Ask for real-time subscriptions so the dashboard updates when rows change, and keep the prompt scoped to one table or one view at a time.
How do I add loading and empty states?
Ask for them explicitly. Prompt Lovable to add skeleton loaders that match the shape of each card, chart, and table, plus empty states with an icon, a one-line explanation, and a primary CTA button. Also request error states with a retry action and toast notifications, since these are easy to skip if you do not name them.
How do I add role-based access?
Define roles in your Knowledge file (for example admin and member) so every prompt inherits them. Then prompt Lovable to gate routes, hide admin-only nav items and actions for members, and enforce access with Supabase Row Level Security policies on the backend, not just in the UI.
How do I keep the design consistent across pages?
Put your design system in the Knowledge file: colors, spacing, font, border radius, and component style. It is sent with every prompt, so new pages inherit it. When you change a shared component, add "keep everything else the same; only change X" so Lovable does not redesign unrelated screens.
Will it stay responsive on mobile?
Yes, if you ask for it. Lovable outputs React and Tailwind, which is responsive by default, but dashboards need extra care. Prompt for a sidebar that collapses to a drawer on mobile, tables that scroll horizontally or switch to stacked cards, and charts that resize to the container. Test the mobile breakpoint and use Visual Edits to fix spacing without spending credits.