Bolt.new (StackBlitz's in-browser, full-stack AI builder) ships a real SaaS dashboard when you hand it an app-level brief with the exact metrics, columns, and roles — not a request for "an admin panel." Every prompt below pins the stack (Vite + React + TypeScript + Tailwind or Next.js, Recharts for charts, Supabase for the database and auth), acknowledges the WebContainer runtime, describes design tokens, and uses [bracketed placeholders] you fill in.
Paste each one into the Bolt.new chat box. Build the shell plus one core widget first, then add each chart and table in its own message so every generation stays small and cheap — remember every message spends tokens even if the build fails. For the broader set, start with the 40 best Bolt.new prompts roundup, and see how to prompt Bolt.new for full-stack apps for the underlying formula.
Dashboard shells & layout
Start with the frame. Give Bolt an app-level brief and build the shell alone, so navigation, spacing, and the design vibe stay consistent as you queue each page into it.
1. SaaS dashboard app brief and shell
Build the shell of a SaaS analytics dashboard app called [ProductName]. This is an app-level brief, so read it all before building.
The app: an internal analytics + admin console used by [product] operators to watch revenue and manage users. Users: owner, admin, and viewer roles. Core pages: Overview, Revenue, Users, Billing, Settings. Data lives in Supabase (Postgres + auth); I'll connect it later.
For THIS first message, build ONLY the shell and the empty Overview page — no real data yet:
- A collapsible left sidebar with nav items (Overview, Revenue, Users, Billing, Settings), each with an icon and an active state.
- A top bar with the product name, a global search input, a notifications bell, and a user menu (avatar, Account, Sign out).
- A main content area with a page title and a breadcrumb.
Stack & constraints:
- Vite + React + TypeScript + Tailwind. Use Recharts later for charts and Supabase later for data — do not add them yet.
- You run in WebContainer (browser Node), so no native binaries and no local database; keep everything JS-native.
- Design vibe: elegant, high-tech, minimal. Tokens: sidebar bg #0F172A, primary #6366F1, positive #16A34A, negative #DC2626, radius 0.75rem, font Inter.
- Responsive to 360px; the sidebar collapses to a drawer on mobile. Keyboard-accessible with visible focus rings.
Before you build, briefly outline the file structure you'll create, then build the shell.Why it works: the app-level brief plus "shell only, no data yet" gives Bolt a design vibe to carry through every later screen while keeping the first build small.
2. Dashboard layout with sidebar and top bar
Refine the dashboard layout. Only edit the layout and sidebar components — leave the pages alone.
- The sidebar collapses to a 64px icon rail on a toggle and remembers its state in localStorage.
- Group nav into sections: "Insights" (Overview, Revenue, Funnels) and "Manage" (Users, Billing, Settings), each with a small uppercase section label.
- The top bar sticks on scroll, has a Cmd+K search trigger, and a light/dark theme toggle wired to a Tailwind dark class on .
- Add a breadcrumb driven by the current route.
Stack: Vite + React + TypeScript + Tailwind. Keep the tokens from the shell (primary #6366F1, radius 0.75rem, Inter). Responsive; the rail becomes a bottom sheet on mobile. Keyboard-accessible; the theme toggle has an aria-label.Best for: turning a plain shell into a durable, themeable frame before you add any pages.
3. Responsive dashboard grid and page scaffold
Build the Overview page as a responsive dashboard grid — layout and placeholders only, real widgets come next.
- A 12-column CSS grid: a full-width KPI row (4 cards), a 2/3-width chart area next to a 1/3-width breakdown card, then a full-width table section.
- Each region is a placeholder Card with a title and a skeleton shimmer so I can see the layout.
- A page header with the title "Overview", a date-range selector (7d / 30d / 90d / 12m), and a "Refresh" button.
- The grid reflows: 4 KPIs → 2x2 on tablet → 1 column on mobile; the chart+breakdown stack on mobile.
Stack: Vite + React + TypeScript + Tailwind. Tokens: radius 0.75rem, 16px gap, subtle card border #1E293B / #E2E8F0. Only edit the Overview page and a shared Card component. Keyboard-accessible date selector.Why it works: laying out the grid with skeleton placeholders first lets you approve spacing before spending tokens generating the real charts.
4. Command palette and global search
Add a Cmd+K command palette to the dashboard. Only edit the top bar and a new CommandPalette component.
- Cmd+K (and Ctrl+K) opens a centered modal with a search input and a keyboard-navigable results list.
- Groups: "Go to" (each nav page), "Actions" (Invite user, New API key, Toggle theme), and "Recent" (last 3 visited pages from localStorage).
- Arrow keys move selection, Enter runs it, Esc closes; typing filters across all groups. Trap focus while open.
Stack: Vite + React + TypeScript + Tailwind, no extra command-palette library — build it with a plain modal and list so it stays light in WebContainer. Tokens: radius 0.75rem, primary #6366F1. Fully keyboard-accessible with visible focus and correct ARIA roles (dialog, listbox, option).Best for: the power-user navigation that makes an operations dashboard feel fast.
Analytics & charts
Analytics screens live or die on which numbers you name. These prompts give Bolt the specific KPIs, chart types, and Recharts components so the first build reads like a real product.
5. KPI metric cards row
Build a reusable MetricCard component and render a row of them at the top of the Overview page.
- Each card shows: a label, a big value, a delta chip (+/- % vs the previous period, green up / red down), an optional unit ($ or %), and a small Recharts sparkline of the last 12 points.
- Props: title, value, delta, format ('number' | 'currency' | 'percent'), series (number[]), and a loading state that renders a skeleton.
- Render four cards: MRR $[value], Active users [value], Churn [value]%, Avg revenue per user $[value].
Stack: Vite + React + TypeScript + Tailwind, Recharts for the sparkline (pure-JS, installs cleanly in WebContainer). Format numbers with Intl.NumberFormat. Tokens: positive #16A34A, negative #DC2626, radius 0.75rem, subtle shadow. Cards wrap to 2x2 on tablet, 1 column on mobile. Announce the delta direction to screen readers. Only add the MetricCard component and wire it into Overview.Why it works: explicit props make Bolt build one genuinely reusable card you drop across every dashboard instead of one-off markup.
6. Revenue area chart card with Recharts
Build a revenue area-chart card for the dashboard using Recharts.
- A Card titled "Revenue" with a period toggle (Daily / Weekly / Monthly) in the header.
- A smooth gradient AreaChart of revenue over time with a hover tooltip showing the date and a currency-formatted amount, a subtle CartesianGrid, and a formatted Y axis.
- A footer line: total for the range and % change vs the previous range.
- An empty state and a loading skeleton.
Stack: Vite + React + TypeScript + Tailwind, Recharts (ResponsiveContainer so it reflows). Accept data as { date, revenue }[] and a period prop; for now feed it typed mock data from a getRevenueSeries(period) function I can later swap for a Supabase query. Tokens: area gradient from #6366F1 to transparent, radius 0.75rem. Responsive with a min height; keyboard-focusable toggle. Only add the RevenueChart component and place it in the Overview grid.Best for: the hero chart at the top of a revenue or usage dashboard.
7. Segmented bar and donut breakdown
Build a "breakdown" card that shows how a metric splits across categories, using Recharts.
- A Card with a toggle between a horizontal BarChart view and a PieChart (donut) view of the same data.
- Data: revenue by plan — Free, Pro, Team, Enterprise — each with a value, a % of total, and a color.
- A legend/list below with category name, value, and %; clicking a legend row highlights its segment.
- Total shown in the donut center.
Stack: Vite + React + TypeScript + Tailwind, Recharts. Accept data as { label, value, color }[]. Tokens: category palette [#6366F1, #0EA5E9, #16A34A, #F59E0B], radius 0.75rem; percentages computed from values and currency-formatted. Responsive; legend moves below on mobile. Legend rows keyboard-focusable with a visible highlight on the matching segment. Only add the BreakdownCard component.Why it works: one component with a bar/donut toggle covers two common asks and keeps the palette consistent across the dashboard.
8. Cohort retention heatmap
Build a cohort retention heatmap card. Recharts has no heatmap, so build it as a plain CSS grid of colored cells.
- Rows are signup-week cohorts (last 12 weeks); columns are weeks-since-signup (0–11). Each cell is the retention % for that cohort at that week, colored on a scale from light to the brand color as % rises.
- The first column shows the cohort label and its starting user count.
- Hovering a cell shows a tooltip: cohort, week N, retained / total, and %.
- A toggle between % retention and absolute counts.
Stack: Vite + React + TypeScript + Tailwind. Accept a 2D array from a getRetentionCohorts() function (typed mock for now, swappable for Supabase). Tokens: heat scale based on #4F46E5, radius 0.5rem. Each cell has an aria-label with the exact numbers; arrow keys move between cells. Horizontal scroll on mobile with a sticky cohort-label column. Only add the RetentionHeatmap component.Best for: a retention view where the color grid instantly shows which cohorts stick.
Tables, CRUD & data management
Tables are the heart of any SaaS admin. These prompts push Bolt toward Supabase-backed, server-side data operations so the grid stays fast and the forms stay consistent.
9. Server-side paginated data table
Build a reusable server-side data table for a large `orders` dataset backed by Supabase.
- Columns: order ID, customer, items count, total, payment status (paid/pending/refunded) as a badge, fulfillment status, created date.
- Server-side pagination (50/page), sorting on any column, and filtering by status and a date range — all done in the Supabase query, not in the client.
- A search box for order ID / customer, a column-visibility toggle, and a sticky header.
- Read pagination, sort, and filter state from the URL so links are shareable.
Stack: Vite + React + TypeScript + Tailwind. Query Supabase with .select(), .range(offset, offset+49), .order(), and .ilike()/.eq() built from the params — do NOT load all rows into the client (you run in WebContainer, keep it lean). Show a skeleton while loading and an empty state. Responsive with horizontal scroll and a sticky first column; keyboard-accessible sort headers. Only add a DataTable component and the Orders page.Why it works: spelling out server-side pagination via Supabase range() stops Bolt from dumping the whole dataset into a client component that chokes the preview.
10. Users management page
Build the Users management page inside the existing dashboard layout, backed by Supabase.
- A table of users: avatar + name, email, role (owner/admin/viewer), plan, status (active/invited/suspended) as a badge, last active, joined date.
- A toolbar: search by name/email, filter by role and status, and an "Invite user" button opening a modal with name, email, and role fields.
- Row actions in a dropdown: edit, change role, suspend/reactivate, delete (with a confirm modal).
- Server-side pagination (25/page), sortable by name / last active / joined.
Stack: Vite + React + TypeScript + Tailwind, Supabase. Read/write a `profiles` table (id, name, email, role, plan, status, last_active_at, created_at). Only role owner or admin can change roles or delete — enforce it with a Supabase RLS policy AND a client guard, not just hidden buttons. Responsive with horizontal scroll; keyboard-accessible menus and modals with focus trapping. Only add the Users page and a shared Modal.Best for: the single most-requested admin screen — user CRUD with real columns and RLS-enforced permissions.
11. Bulk actions and row selection
Add row selection and bulk actions to the existing subscribers table. Only edit the subscribers table and add a BulkActionBar component.
- A header checkbox to select all on the page, per-row checkboxes, and an indeterminate state.
- When rows are selected, show a sticky action bar: "N selected", plus Export CSV, Add tag, Change status, and Delete (confirm modal).
- A "select all N matching filter" option that spans pages, not just the current one.
Stack: Vite + React + TypeScript + Tailwind, Supabase. Bulk mutations run through a single update query using .in('id', ids) — or, for select-all-matching, the same filters as the current view. Optimistically reflect the change and toast the result. Keep the action bar keyboard-reachable and announce the selection count to screen readers. Responsive.Why it works: the "select all matching filter across pages" detail is where naive implementations break, so calling it out gets it right the first time.
12. Inline-editable table cells
Make specific cells in the inventory table inline-editable. Only edit the inventory table component.
- The price and stock columns become editable on click: the cell turns into an input, Enter saves, Escape cancels, blur saves.
- The status column becomes an inline select.
- Show a subtle saving spinner in the cell during the write and a brief check on success; revert and toast on error.
Stack: Vite + React + TypeScript + Tailwind, Supabase. Each edit runs an update on the `inventory` table for that row and field with an optimistic UI update and rollback on failure. Only allow price and status edits for role manager or admin — enforce it with an RLS policy on the table, not just the UI. Fully keyboard-operable: Tab moves between editable cells. Responsive.Best for: spreadsheet-style editing where analysts tweak values without opening a modal each time.
13. CRUD resource page with modal forms
Build a full CRUD page for a `products` resource backed by Supabase.
- A table: name, SKU, category, price, stock, status (active/draft/archived).
- "New product" and per-row "Edit" open the SAME modal form: name, SKU, category (select), price (number), stock (number), status, description (textarea). Validate with zod and show inline field errors.
- Delete opens a confirm dialog.
- Toasts on success/failure.
Stack: Vite + React + TypeScript + Tailwind, Supabase, react-hook-form + zod. Wire insert / update / delete on the `products` table and refetch the list after each mutation. Reuse ONE ProductForm component for create and edit. Tokens: radius 0.75rem, primary #6366F1. Responsive; keyboard-accessible form and modals with focus trapping. Only add the Products page, ProductForm, and a confirm dialog.Why it works: demanding one shared, zod-validated form for create and edit keeps the code small and the UX consistent.
14. Orders moderation queue
Build an orders moderation queue page for reviewers clearing a backlog fast.
- A list of held orders: order summary, customer, hold reason, amount, submitted time, and a status badge.
- Each row has Approve and Reject buttons; Reject opens a modal to pick a reason and add a note.
- A bulk mode: select multiple rows via checkboxes and Approve/Reject all selected.
- Tabs for Pending / Approved / Rejected, with a count on each tab.
- Keyboard shortcuts: J/K to move selection, A to approve, R to reject the focused row.
Stack: Vite + React + TypeScript + Tailwind, Supabase. Approve/reject update the order's status (and reject stores the reason) via Supabase updates, optimistically updating the row. Tokens: approve #16A34A, reject #DC2626, radius 0.5rem. Responsive; keyboard shortcuts shown in a small legend. Only add the Moderation page.Best for: an operational screen where throughput — bulk mode and J/K/A/R shortcuts — is the whole point.
Auth, roles & settings (Supabase)
Auth, roles, and account screens are where a dashboard becomes a real product. These prompts give Bolt the exact Supabase auth flow, RLS rules, and settings fields.
15. Feature flags admin
Build a feature-flags admin page for an engineer toggling rollouts, backed by Supabase.
- A table of flags: key, description, environment (dev/staging/prod) as tabs, a switch for on/off, a rollout % slider, and last-updated by/when.
- A "New flag" modal: key, description, default state, rollout %.
- Each row expands to show targeting rules (e.g. "plan == enterprise") as editable chips.
- A search box and a filter for enabled/disabled.
Stack: Vite + React + TypeScript + Tailwind, Supabase. Persist to a `feature_flags` table (key, env, enabled, rollout_pct, rules jsonb, updated_by, updated_at). Confirm before toggling anything in the prod tab. Tokens: primary #6366F1, radius 0.5rem. Responsive; keyboard-accessible switches and sliders. Only add the FeatureFlags page.Why it works: per-environment tabs and a prod-confirm guard are the details that make an internal flag tool safe to use.
16. Audit log viewer
Build a read-only audit log viewer for admins investigating who did what, backed by Supabase.
- A reverse-chronological table: timestamp, actor (name + email), action (e.g. "changed user role", "deleted product"), target, IP, and a "details" expander showing a before/after JSON diff.
- Filters: date range, actor, and action type (select), plus a free-text search over target.
- Server-side pagination (100/page) and an "Export CSV" for the current filter.
Stack: Vite + React + TypeScript + Tailwind, Supabase. Query an `audit_logs` table with the filters applied in the Supabase query. Read-only — no way to edit or delete entries from the UI, and restrict the page to role admin via an RLS SELECT policy plus a route guard. Tokens: mono font for the JSON diff, radius 0.5rem. Responsive; keyboard-accessible expanders. Only add the AuditLog page.Best for: a compliance-facing screen that must stay read-only and admin-gated at the database, not just the UI.
17. Supabase auth and protected routes
Add authentication to the dashboard using Supabase Auth. I've already connected Supabase.
- A /login page with email + password and a "Sign in with Google" button (Supabase OAuth), plus a /signup page and a "forgot password" link.
- On sign-in, create or upsert a row in `profiles` (id = auth uid, name, email, role default 'viewer').
- Wrap the whole dashboard in an auth guard: unauthenticated users are redirected to /login; while the session loads, show a splash.
- Wire the top-bar user menu "Sign out" to Supabase signOut and show the real avatar/name/email from the session.
Stack: Vite + React + TypeScript + Tailwind, @supabase/supabase-js. Read the Supabase URL and anon key from Vite env vars (import.meta.env.VITE_SUPABASE_URL / VITE_SUPABASE_ANON_KEY). Keep a single supabase client and an AuthProvider context. Responsive login page; keyboard-accessible forms with inline errors. Only add the auth pages, the client, and the AuthProvider.Why it works: naming the env var keys and the profiles upsert gives Bolt the exact Supabase auth wiring instead of a half-built login screen.
18. Row Level Security and roles
Make the dashboard role-aware for three roles — owner, admin, viewer — enforced with Supabase Row Level Security, not just hidden UI.
Rules:
- owner: everything, including Billing and deleting users.
- admin: manage users and content, edit rows, but no Billing and cannot delete the last owner.
- viewer: read-only — all charts and tables visible, but no create/edit/delete controls.
Do this:
- Add a `role` column to `profiles` if missing.
- Write RLS policies for `profiles`, `products`, and `orders` so each role's allowed reads/writes are enforced at the database; give me the SQL to paste into the Supabase SQL editor.
- Add a client helper canDo(role, action) and use it to hide/disable controls so the UI matches the policies.
Stack: Vite + React + TypeScript + Tailwind, Supabase. Critically: hidden UI must NOT be bypassable — the RLS policies are the real gate. Keyboard-accessible; no layout shift between roles beyond hidden widgets. Only edit the data layer, the pages' action controls, and output the SQL.Best for: real access control — RLS at the database, mirrored by a client helper, not cosmetic hiding.
19. Account settings page
Build an account settings page with tabbed sections, backed by Supabase.
- Tabs: Profile, Notifications, Security, Danger Zone.
- Profile: avatar upload (to Supabase Storage), full name, email (with "verify" if unverified), timezone select, and a Save button disabled until something changes.
- Notifications: toggles for product updates, weekly digest, and billing alerts, each with a short description.
- Security: change-password fields, a sessions list with device/last-active and a "revoke" button, and a two-factor toggle.
- Danger Zone: "Delete account" behind a typed-confirmation modal.
Stack: Vite + React + TypeScript + Tailwind, Supabase (Auth + Storage). Each section saves via its own handler with zod validation and a success/error toast; persist profile fields to `profiles`. Tokens: radius 0.5rem, danger #DC2626, Inter. Responsive single column on mobile; keyboard-accessible tabs and forms with visible focus. Only add the Settings page.Why it works: the four named tabs and the typed-confirmation danger zone give Bolt a complete, conventional settings screen in one message.
Wiring it up & shipping
The last set connects the data layer, controls Bolt's edits with scoping and file locks, and deploys — using Bolt's built-in buttons rather than asking it to do these in chat.
20. Billing and subscription page
Build a billing & subscription page for a SaaS account owner.
- A current-plan card: plan name, price/interval, seats used / included, next renewal date, and "Change plan" / "Cancel" buttons.
- A plan comparison modal with three tiers (Starter $19, Growth $49, Scale $149) showing features and a "Switch" button per tier.
- A payment method card: card brand, last 4, expiry, and "Update".
- An invoices table: date, amount, status (paid/failed) badge, and a download link per row.
- A usage meter for the current period (API calls used / limit) with a progress bar.
Stack: Vite + React + TypeScript + Tailwind, Supabase for plan/usage data. Stub the Stripe calls behind a billing service module with clear TODOs where the Stripe keys and webhook go — Stripe is a known Bolt integration I'll wire next. Only role owner can change the plan (RLS + client guard). Tokens: primary #6366F1, radius 0.75rem. Responsive; invoices table scrolls on mobile; keyboard-accessible modals. Only add the Billing page.Best for: a Stripe-style billing screen with real tiers, invoices, and a usage meter, ready for the Stripe wire-up.
21. Team members and invites
Build a team management page for inviting and managing members, backed by Supabase.
- A members table: avatar + name, email, role (owner/admin/member), status (active / pending invite), joined date, and a role select + "Remove" action per row.
- An "Invite people" panel: a multi-email input (paste comma-separated), a role select, and "Send invites"; show pending invites with "resend" and "revoke".
- A seat counter: "N of M seats used" with an upgrade prompt when full.
Stack: Vite + React + TypeScript + Tailwind, Supabase. Persist to `memberships` and `invites` tables. Only owner/admin can invite or change roles, and the last owner cannot be removed — enforce both with RLS policies AND client guards. Tokens: radius 0.5rem, primary #6366F1. Responsive; keyboard-accessible. Only add the Team page.Why it works: the "last owner cannot be removed" and seat-limit rules are the edge cases teams actually hit, so naming them prevents a broken invite flow.
22. Connect Supabase and wire the data layer
I've clicked "Connect Supabase" and my project is linked. Now replace all mock data in the dashboard with real Supabase queries.
- Create the schema: give me the SQL to create `profiles`, `orders`, `products`, `subscribers`, and `audit_logs` with sensible columns and foreign keys, plus a little seed data, so I can paste it into the Supabase SQL editor.
- Create ONE typed data layer in src/lib/data.ts with functions like getRevenueSeries, listOrders(params), listUsers(params), createProduct, updateProduct — each calling the shared supabase client with proper typing.
- Swap every component's mock import to call these functions; add loading and error states where missing.
Stack: Vite + React + TypeScript + Tailwind, @supabase/supabase-js. Read VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY from env (remind me to set them). You're in WebContainer, so all data goes through hosted Supabase — no local database. Keep the client a singleton. Edit only the data layer and the imports in each component; don't restyle anything.Best for: the moment you go from mock to real — one typed data layer swapped in behind every widget.
23. Scope to file, lock, and refactor
Refactor ONLY src/components/DataTable.tsx — do not touch any other file. The shell, data layer, and other pages are locked and finished.
- Extract the sorting, pagination, and filter logic into a small useTableQuery hook so every page's table shares it.
- Add a "no results" empty state and a retry button on error.
- Keep the exact same props and visual output so the Orders, Users, and Products pages that use it don't change.
Stack: Vite + React + TypeScript + Tailwind, Supabase. Use diff-based edits scoped to this one file plus a new src/hooks/useTableQuery.ts. Do not change styling, tokens, or any other component. After this, I'll right-click and lock DataTable.tsx too.Why it works: scoping the message to one file and reminding Bolt that the rest is locked uses diff-based editing to prevent collateral changes and save tokens.
24. Plan, deploy to Netlify, and ship
Before I deploy, act as a build engineer and give me a short pre-ship plan for this SaaS dashboard — no code yet.
Cover:
1. A checklist of what's done vs missing across Overview, Users, Billing, Settings, and auth.
2. Env vars I must set in the Netlify deploy settings (VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY) and where each is used.
3. A production checklist: RLS enabled on every table, no service-role key in client code, error boundaries around pages, and a 404 route.
4. Any WebContainer-only shortcuts (mock data, stubs) I must replace before going live.
Stack: Vite + React + TypeScript + Tailwind, Supabase. After I fix the gaps, I'll use the Deploy button to publish to Netlify and export to GitHub for version control — don't try to deploy from chat. Keep the plan concise and ordered by priority.Best for: the final pass before you hit Deploy. Ready for more? Explore Bolt.new prompts for Supabase backends to deepen the data layer, or the full roundup for prompts beyond dashboards.
Frequently Asked Questions
How do I prompt Bolt.new for a SaaS dashboard?
Give Bolt an app-level brief, not a screen request. Name the product, who uses it, the exact metrics and columns, the data model, and the auth story, then pin the stack (Vite + React + TypeScript + Tailwind, Recharts, Supabase). Ask Bolt to build the dashboard shell plus one core widget first, then add each chart and table in its own message. Concrete numbers like MRR, churn, and active seats produce a far better first build than asking for "a dashboard."
Can Bolt.new connect a dashboard to a real database?
Yes. Because Bolt runs in WebContainer with no local Postgres, use Supabase for the database and auth. Use the built-in Connect Supabase button rather than asking Bolt to do it in chat, then tell Bolt your table and column names and ask it to generate typed queries and RLS policies. Bolt scaffolds the client, the .env keys, and the read/write calls for your dashboard widgets.
Which chart library should I ask Bolt.new to use?
Recharts is the safe default — it is pure JavaScript, installs cleanly in WebContainer, and renders responsive area, bar, line, and donut charts. Pin it in the prompt ("use Recharts") so Bolt does not reach for a native or canvas-heavy library that fights the browser runtime. For sparklines and small inline charts, Recharts also works well inside metric cards.
How do I keep a Bolt.new data table fast with many rows?
Ask Bolt for server-side pagination, sorting, and filtering through Supabase queries with range() and order() rather than loading every row into the client. Specify the page size, the sortable columns, and the filter fields, and have Bolt read that state from the URL so links are shareable. This keeps the WebContainer preview responsive even against a large table.
Should I build the whole dashboard in one Bolt.new prompt?
No. Ask Bolt to plan first and outline the pages and data model, then build the shell and one core feature, and add each widget in its own message. Small, scoped messages produce cleaner code, are easier to review, and spend fewer tokens — and every message costs tokens even if the build fails, so a tight prompt saves money.
How do I stop Bolt.new from changing files I already finished?
Scope each message to the exact files it should touch, for example "only edit src/components/RevenueChart.tsx," and right-click any stable file in the editor and choose Lock file so Bolt will not rewrite it. Diff-based editing means Bolt only changes the lines it needs, so naming the target file keeps collateral edits out of your finished dashboard shell and data layer.
How do I add roles and permissions to a Bolt.new dashboard?
State the roles and what each can see or do, and ask Bolt to gate both the UI and the data. With Supabase, enforce it with Row Level Security policies on the tables, not just by hiding buttons — hidden UI must not be bypassable. Have Bolt add a role column, RLS policies per table, and a client helper that mirrors the rules so the interface and the database agree.
How do I deploy a Bolt.new dashboard?
Use the built-in Deploy button to publish to Netlify (or Vercel) in a couple of clicks — do not ask Bolt to deploy in chat. For any other host, use GitHub export to sync the repo and connect it to your pipeline. Before deploying, make sure your Supabase URL and anon key are set as environment variables so the live dashboard can reach the database.