30 Best Bolt Prompts
Precise, copy-paste prompts for Bolt.new (by StackBlitz) to scaffold full-stack apps, ship landing pages and dashboards, build SaaS MVPs, add features, wire up APIs, and squash bugs.
In short: This page contains 30 copy-paste ready prompts, organized into 6 categories with a description and pro tip for each. The first 15 prompts are free instantly โ no signup needed. Hand-curated and tested by the AI Academy team.
Scaffolding Full-Stack Apps
5 promptsScaffold a Full-Stack App From Scratch
1/30<context> App idea: [YOUR APP IDEA] Stack: Next.js 14 (App Router) + TypeScript + Tailwind CSS + Prisma + SQLite (swap to Postgres later) Core entities: [ENTITY 1], [ENTITY 2], [ENTITY 3] Auth: email + password with sessions </context> <task> Scaffold the complete project. Do the following: 1. Set up the folder structure: app/ routes, components/, lib/, prisma/schema.prisma. 2. Define the Prisma schema for the core entities above with sensible relations and timestamps. 3. Create typed server actions for CRUD on each entity. 4. Build a minimal but clean home page and one list+detail view per entity. 5. Add basic auth (sign up, log in, log out, protected routes). 6. Seed the database with 5 realistic example rows per entity. 7. Make sure npm run dev starts with zero errors and explain how to run it. </task>
Generates a runnable full-stack app skeleton with database, CRUD, and auth.
Pro tip: Name your exact entities in the context block โ vague ideas make Bolt invent the wrong data model.
Pick the Right Stack for an Idea
2/30<context> Idea: [YOUR APP IDEA] Constraints: ships in a weekend, deploys free, must support [REALTIME / FILE UPLOAD / PAYMENTS / NONE] My experience: [BEGINNER / INTERMEDIATE / EXPERT] in JavaScript </context> <task> Before writing code, do the following: 1. Recommend ONE stack (framework, styling, database, hosting) and justify it in 2 sentences for my constraints. 2. List the npm packages you will install and why each is needed. 3. Outline the file structure as a tree. 4. Flag any constraint that the chosen stack handles poorly and propose an alternative. 5. Then scaffold the empty project with that stack and a placeholder home page. </task>
Produces a justified stack decision plus an empty, correctly configured starter.
Pro tip: Ask Bolt to commit to ONE stack โ without that instruction it tends to hedge across several.
Convert a Spec Into a Working Prototype
3/30<context> Product spec: [PASTE YOUR SPEC OR PRD HERE] Target users: [WHO] Must-have screens: [SCREEN 1], [SCREEN 2], [SCREEN 3] </context> <task> Turn this spec into a clickable prototype. Do the following: 1. Extract the data model implied by the spec and define it in Prisma. 2. Build each must-have screen with realistic placeholder data wired to the model. 3. Connect navigation between screens so the core flow is clickable end to end. 4. Use Tailwind for a clean, modern, neutral design (no lorem ipsum โ write believable copy). 5. List any spec ambiguities you had to assume, so I can correct them. </task>
Turns a written spec or PRD into a navigable, data-backed prototype.
Pro tip: Paste the real PRD rather than summarizing it โ Bolt reads long specs well and infers the schema better.
Multi-Page Marketing Site Skeleton
4/30<context> Product: [YOUR APP IDEA] Pages needed: Home, Features, Pricing, About, Contact, Blog index Brand vibe: [MODERN / PLAYFUL / ENTERPRISE], primary color [HEX] </context> <task> Scaffold a multi-page marketing site. Do the following: 1. Create a shared layout with a sticky responsive header and footer. 2. Build each listed page as its own route with realistic section content. 3. Implement the Pricing page with 3 tiers and a monthly/annual toggle. 4. Make the Blog index render from a local markdown/MDX folder. 5. Ensure mobile responsiveness and a consistent design system via Tailwind config tokens. </task>
Builds a complete multi-page marketing site with shared layout and pricing.
Pro tip: Define brand color and vibe up front so Bolt sets Tailwind theme tokens instead of hardcoding random colors.
Monorepo With Shared Types
5/30<context> Project: [YOUR APP IDEA] Apps: a web frontend and a separate API service Goal: share TypeScript types between them </context> <task> Scaffold a TypeScript monorepo. Do the following: 1. Set up a workspace (npm/pnpm workspaces) with apps/web, apps/api, and packages/types. 2. Put all shared domain types and Zod schemas in packages/types. 3. Build the API with Express or Hono exposing 3 example endpoints validated by the shared schemas. 4. Build the web app consuming those endpoints with the same shared types. 5. Add a single root script that runs both apps concurrently in dev. </task>
Creates a typed monorepo where frontend and backend share schemas.
Pro tip: Keep Zod schemas as the single source of truth โ ask Bolt to derive both validation and types from them.
Prompts get you started. Tutorials level you up.
A growing library of 300+ hands-on AI tutorials. New tutorials added every week.
Landing Pages & Marketing
5 promptsHigh-Converting SaaS Landing Page
6/30<context> Product: [YOUR APP IDEA] One-line value prop: [VALUE PROP] Primary CTA: [SIGN UP / BOOK DEMO / JOIN WAITLIST] Audience: [WHO] </context> <task> Build a single-page, conversion-focused landing page. Do the following: 1. Hero with headline, subhead, primary CTA, and a hero visual placeholder. 2. A 3-column problem/solution section and a 3-step 'how it works'. 3. A features grid (6 features) with icons and short benefit-led copy. 4. Social proof section (logos + 3 testimonials) and an FAQ accordion. 5. A repeated CTA before the footer. 6. Use Tailwind, smooth scroll, subtle entrance animations, and full mobile responsiveness. </task>
Produces a complete, animated, mobile-ready SaaS landing page in one shot.
Pro tip: Give a sharp one-line value prop โ Bolt mirrors its phrasing into the hero and CTAs.
Waitlist Page With Email Capture
7/30<context> Product: [YOUR APP IDEA] Launch status: pre-launch Email storage: store signups in a database table </context> <task> Build a focused waitlist page. Do the following: 1. Create a centered hero with the pitch and an email capture form. 2. Validate the email on the client and store valid signups in a waitlist table via a server action. 3. Prevent duplicate emails and show a friendly already-on-list message. 4. After submit, show a success state with a referral share link. 5. Add an admin-only /waitlist route that lists signups with a CSV export button. </task>
Ships a waitlist page with validated email capture, dedupe, and admin export.
Pro tip: Ask for the referral share link in the success state โ it turns a static form into a viral loop for free.
Product Feature Page With Comparison Table
8/30<context> Product: [YOUR APP IDEA] Key feature to highlight: [FEATURE] Competitors to compare against: [COMPETITOR A], [COMPETITOR B] </context> <task> Build a feature deep-dive page. Do the following: 1. Lead with a benefit headline and an animated demo placeholder for the feature. 2. Explain the feature in 3 use-case cards, each with a short scenario. 3. Add a responsive comparison table (us vs the two competitors) with check/x cells. 4. Include a short objection-handling FAQ. 5. End with a CTA band linking to sign up. </task>
Creates a feature page with use-case cards and a competitor comparison table.
Pro tip: List real competitors so the comparison rows read as credible instead of generic.
Animated Hero Section Variants
9/30<context> Product: [YOUR APP IDEA] Current hero: [DESCRIBE OR 'none yet'] Vibe: [BOLD / MINIMAL / TECH] </context> <task> Design three distinct hero section variants I can A/B test. Do the following: 1. Build Hero A (copy-led, big type), Hero B (visual-led with a gradient/mesh background), and Hero C (interactive, e.g. a typed-text headline). 2. Implement all three as separate components and a route that lets me toggle between them. 3. Use Framer Motion (or CSS) for tasteful entrance animations. 4. Keep the same CTA and value prop across all three so only the design varies. </task>
Generates three swappable hero variants ready for A/B testing.
Pro tip: Holding CTA and value prop constant across variants keeps your test isolated to design.
Launch Countdown & Coming-Soon Page
10/30<context> Product: [YOUR APP IDEA] Launch date: [DATE] </context> <task> Build a coming-soon page. Do the following: 1. Center a live countdown timer to the launch date that updates every second. 2. Add a one-field email notify form stored to a database table. 3. Include social links and a subtle animated background. 4. Handle the post-launch case: after the date passes, show a 'We are live' CTA instead of the timer. 5. Make it fully responsive and add basic OpenGraph meta tags. </task>
Builds a coming-soon page with live countdown, notify form, and post-launch state.
Pro tip: Asking for the post-launch state up front saves you a second edit pass after the date hits.
Dashboards & Internal Tools
5 promptsAnalytics Dashboard With Charts
11/30<context> App: [YOUR APP IDEA] Metrics to show: [METRIC 1], [METRIC 2], [METRIC 3] Data source: mock data for now (realistic shape) </context> <task> Build an analytics dashboard. Do the following: 1. Create a sidebar layout with a top bar (date-range picker, user menu). 2. Add 4 KPI stat cards with trend deltas at the top. 3. Add a line chart, a bar chart, and a donut chart using Recharts with mock time-series data. 4. Add a recent-activity table with sorting and pagination. 5. Make the whole layout responsive and add a light/dark theme toggle. </task>
Produces a responsive analytics dashboard with KPI cards, charts, and a data table.
Pro tip: Have Bolt generate realistic mock data first; swapping it for a real API later is a one-line change.
Admin CRUD Panel With Roles
12/30<context> App: [YOUR APP IDEA] Entity to manage: [ENTITY] Roles: admin (full access), editor (create/edit), viewer (read-only) </context> <task> Build an admin panel. Do the following: 1. Create a data table for the entity with search, filter, sort, and pagination. 2. Add create/edit modals with validated forms and inline error messages. 3. Add delete with a confirmation dialog and optimistic UI updates. 4. Gate actions by role so viewers cannot mutate and editors cannot delete. 5. Show a toast on every successful or failed action. </task>
Builds a role-gated admin CRUD panel with search, modals, and toasts.
Pro tip: Specify exactly which role can do what โ otherwise Bolt grants every action to everyone.
Kanban Board With Drag and Drop
13/30<context> App: [YOUR APP IDEA] Columns: Backlog, In Progress, Review, Done Persistence: save board state to the database </context> <task> Build a Kanban board. Do the following: 1. Render the four columns with draggable cards using dnd-kit. 2. Persist card position and column on every drop via a server action. 3. Add a quick-add card input at the bottom of each column. 4. Support a card detail drawer for editing title, description, and assignee. 5. Keep drag interactions smooth on both desktop and touch devices. </task>
Creates a persistent drag-and-drop Kanban board with a card detail drawer.
Pro tip: Name dnd-kit explicitly โ Bolt otherwise reaches for the deprecated react-beautiful-dnd.
Settings Page With Tabs and Forms
14/30<context> App: [YOUR APP IDEA] Settings groups: Profile, Account, Notifications, Billing </context> <task> Build a settings area. Do the following: 1. Create a tabbed (or sidebar) layout with one panel per settings group. 2. Build validated forms for each panel with dirty-state detection and a sticky save bar. 3. Add notification preferences as toggles saved individually. 4. Stub the Billing tab with the current plan, usage, and an upgrade button. 5. Show a confirmation toast and disable Save until something changes. </task>
Generates a tabbed settings area with validated forms and a sticky save bar.
Pro tip: Dirty-state detection is the detail most builders forget โ calling it out gets you a proper save flow.
Data Table With Server-Side Filtering
15/30<context> App: [YOUR APP IDEA] Rows: large dataset (thousands of [RECORDS]) Needs: search, multi-column filter, sort, pagination </context> <task> Build a performant data table. Do the following: 1. Implement server-side pagination, sorting, and filtering (do NOT load all rows client-side). 2. Use TanStack Table for the UI and debounce the search input. 3. Add column visibility toggles and a row-selection checkbox column. 4. Add a bulk-action bar that appears when rows are selected. 5. Show skeleton loaders while fetching and an empty state when no rows match. </task>
Builds a scalable data table with server-side filtering, sorting, and bulk actions.
Pro tip: Insisting on server-side paging prevents Bolt from shipping a table that freezes on large datasets.
SaaS MVPs
5 promptsMulti-Tenant SaaS Foundation
16/30<context> SaaS idea: [YOUR APP IDEA] Tenancy: each customer is an organization with multiple members Roles: owner, admin, member </context> <task> Build a multi-tenant SaaS foundation. Do the following: 1. Model User, Organization, and Membership (with role) in Prisma. 2. Scope all data queries to the current organization so tenants never see each other's data. 3. Build org creation on signup and an org switcher in the header. 4. Add an invite-by-email flow that creates pending memberships. 5. Gate admin-only screens (members, settings) by role. </task>
Lays down a multi-tenant SaaS base with orgs, memberships, roles, and invites.
Pro tip: Explicitly demand org-scoped queries โ tenant data leaks are the classic multi-tenant bug.
Subscription Billing With Stripe
17/30<context> SaaS: [YOUR APP IDEA] Plans: Free, Pro ($X/mo), Business ($Y/mo) Gated feature: [FEATURE LOCKED BEHIND PRO] </context> <task> Integrate subscription billing. Do the following: 1. Add a pricing page reflecting the three plans. 2. Wire Stripe Checkout for upgrades and a customer portal link for managing billing. 3. Handle the Stripe webhook to update the user's plan on subscription changes. 4. Implement a feature gate so the locked feature only works on Pro and above. 5. Read Stripe keys from environment variables and tell me exactly which ones to set. </task>
Wires Stripe Checkout, webhooks, and feature gating into a SaaS app.
Pro tip: Have Bolt list the exact env vars and webhook events so you know what to configure in the Stripe dashboard.
Usage-Based Metering & Limits
18/30<context> SaaS: [YOUR APP IDEA] Metered action: [ACTION, e.g. API calls / generations] Plan limits: Free = [N]/mo, Pro = [M]/mo </context> <task> Add usage metering. Do the following: 1. Track each metered action against the user's current billing period. 2. Enforce plan limits and block the action with a clear upgrade prompt when exceeded. 3. Show a usage meter (used / limit) in the dashboard with a progress bar. 4. Reset usage at the start of each billing period. 5. Expose an internal endpoint to inspect a user's current usage. </task>
Implements per-plan usage metering, enforcement, and a dashboard usage meter.
Pro tip: Define the billing-period reset rule explicitly so limits do not silently accumulate forever.
Onboarding Flow With Checklist
19/30<context> SaaS: [YOUR APP IDEA] Aha moment: [THE FIRST VALUABLE ACTION] </context> <task> Build a new-user onboarding flow. Do the following: 1. After signup, show a multi-step wizard collecting only the minimum needed to reach the aha moment. 2. Persist onboarding progress so users can resume where they left off. 3. Add a dismissible setup checklist on the dashboard that ticks items as they are completed. 4. Show an empty-state with a clear first action before any data exists. 5. Track completion of each step so I can see where users drop off. </task>
Creates a resumable onboarding wizard plus a dashboard setup checklist.
Pro tip: Name your aha moment so Bolt designs the flow to reach it fast instead of collecting busywork.
Public API With Keys & Rate Limiting
20/30<context> SaaS: [YOUR APP IDEA] Resource to expose: [RESOURCE] </context> <task> Build a public REST API for the product. Do the following: 1. Let users generate and revoke API keys from a settings page (store hashed keys). 2. Authenticate requests via a Bearer API key. 3. Add per-key rate limiting with clear 429 responses and remaining-quota headers. 4. Expose CRUD endpoints for the resource, validated with Zod. 5. Generate a short OpenAPI spec and a usage example with curl. </task>
Builds an authenticated, rate-limited public API with key management and docs.
Pro tip: Storing hashed keys (not raw) is the security detail to insist on โ keys should never be readable after creation.
Adding Features & Integrations
5 promptsAdd a Feature to an Existing Bolt App
21/30<context> Current app: [BRIEFLY DESCRIBE WHAT IT DOES] New feature: [FEATURE TO ADD] It should touch: [WHICH SCREENS / MODELS] </context> <task> Add this feature without breaking existing functionality. Do the following: 1. First, summarize how the relevant existing files work so we agree on the starting point. 2. List the exact files you will create or modify before changing anything. 3. Implement the feature, reusing existing components and patterns where possible. 4. Add the new UI entry point into current navigation. 5. Confirm nothing else regressed and note anything I should test manually. </task>
Adds a new feature to an existing project while protecting current behavior.
Pro tip: Make Bolt list the files it will touch first โ review that plan before letting it write, to avoid wide rewrites.
Integrate a Third-Party REST API
22/30<context> App: [YOUR APP IDEA] API to integrate: [API NAME] Auth: [API KEY / OAUTH], docs: [LINK OR PASTE ENDPOINT] Goal: [WHAT DATA / ACTION YOU NEED] </context> <task> Integrate this external API. Do the following: 1. Create a typed client wrapper in lib/ that reads the credential from an environment variable. 2. Call it from a server action or route handler (never expose the secret to the client). 3. Type the response and handle errors, timeouts, and rate limits gracefully. 4. Build a small UI that triggers the integration and shows the result or a clear error. 5. Tell me which environment variables to set. </task>
Wires a third-party API in via a typed, server-side client with error handling.
Pro tip: Emphasize server-side calls so your API secret never ships to the browser bundle.
Add Authentication & Protected Routes
23/30<context> App: [YOUR APP IDEA] Auth method: [EMAIL+PASSWORD / MAGIC LINK / OAUTH WITH GOOGLE] Protected areas: [WHICH ROUTES] </context> <task> Add authentication. Do the following: 1. Implement the chosen auth method with secure session handling. 2. Protect the listed routes and redirect unauthenticated users to login. 3. Add login, signup, and logout UI plus a user menu showing the current user. 4. Hash passwords properly if using email+password. 5. Show a clear error on invalid credentials and a loading state during submit. </task>
Adds secure auth with protected routes, session handling, and auth UI.
Pro tip: Pick one auth method in the context โ mixing several in one prompt produces half-finished flows.
Add File Uploads With Previews
24/30<context> App: [YOUR APP IDEA] Upload type: [IMAGES / PDFS / ANY] Storage: [LOCAL FOR NOW / S3-COMPATIBLE] </context> <task> Add file upload. Do the following: 1. Build a drag-and-drop upload zone that also supports click-to-select. 2. Validate file type and size on the client with clear rejection messages. 3. Show upload progress and an instant preview for images. 4. Store the file and persist its metadata (name, size, url) in the database. 5. Let users delete an uploaded file and reflect it immediately in the UI. </task>
Adds drag-and-drop uploads with validation, previews, and metadata storage.
Pro tip: State the max size and allowed types so Bolt enforces them instead of accepting any file.
Add Realtime Updates
25/30<context> App: [YOUR APP IDEA] What should update live: [e.g. notifications / chat / presence] </context> <task> Add realtime behavior. Do the following: 1. Recommend the lightest realtime approach for this case (polling, SSE, or websockets) and justify it. 2. Implement it so the specified data updates without a page refresh. 3. Add an optimistic UI update on the sender side and reconcile with the server. 4. Handle reconnection if the connection drops. 5. Keep it performant with many concurrent clients and explain the trade-offs. </task>
Adds live-updating data with optimistic UI and reconnection handling.
Pro tip: Let Bolt pick polling vs SSE vs websockets โ for simple cases polling is far less fragile than websockets.
Go from copy-pasting to actually mastering AI.
AI Academy: 300+ hands-on tutorials on ChatGPT, Claude, Midjourney, and 50+ other tools. New tutorials added every week.
Debugging & Refactoring
5 promptsFix an Error From the Console
26/30<context> What I was doing: [ACTION THAT TRIGGERED IT] Error message: [PASTE FULL ERROR / STACK TRACE] Relevant file(s): [FILE NAMES IF KNOWN] </context> <task> Diagnose and fix this error. Do the following: 1. Explain the root cause in plain language, not just the symptom. 2. Identify the exact file and line responsible. 3. Apply the minimal fix and show only the changed code. 4. Check whether the same bug pattern exists elsewhere in the project. 5. Suggest one guard (validation, type, or test) that would have caught this earlier. </task>
Diagnoses a console error to its root cause and applies a minimal, scoped fix.
Pro tip: Paste the FULL stack trace, not just the top line โ the cause is usually a few frames down.
Debug Why the UI Is Not Updating
27/30<context> App: [YOUR APP IDEA] Expected: [WHAT SHOULD HAPPEN] Actual: [WHAT HAPPENS INSTEAD] Component(s): [WHERE] </context> <task> Find why the UI is not updating. Do the following: 1. Trace the data flow from state/source to the component that should re-render. 2. Check for the usual culprits: stale closures, missing dependency arrays, mutating state directly, unkeyed lists, or uncached server data. 3. Pinpoint the break and fix it with the smallest change. 4. Explain why your fix triggers the render and the previous code did not. </task>
Tracks down a stale or missing re-render and fixes the underlying state issue.
Pro tip: Describe expected vs actual precisely โ 'it does not work' makes Bolt guess at the symptom.
Refactor a Bloated Component
28/30<context> File: [COMPONENT FILE] Problem: it is too large / does too much / hard to follow </context> <task> Refactor this component for clarity without changing behavior. Do the following: 1. Extract logic into custom hooks and pure helper functions. 2. Split the UI into smaller, well-named child components. 3. Remove dead code and duplicate logic. 4. Keep the public props/behavior identical so nothing else breaks. 5. Briefly summarize what changed and why it is now easier to maintain. </task>
Breaks a large component into hooks and subcomponents with no behavior change.
Pro tip: Insist that public props stay identical so the refactor cannot ripple into the rest of the app.
Improve Performance
29/30<context> App: [YOUR APP IDEA] Symptom: [SLOW PAGE / LAGGY INTERACTION / SLOW LOAD] Where: [ROUTE OR COMPONENT] </context> <task> Improve performance. Do the following: 1. Identify the likely bottleneck (re-renders, oversized bundle, N+1 queries, unoptimized images, blocking requests). 2. Apply targeted fixes: memoization, code-splitting, query batching, lazy loading, or image optimization as relevant. 3. Avoid premature optimization โ only change what measurably helps. 4. Show before/after for each change and what improvement to expect. </task>
Finds the real performance bottleneck and applies targeted, measured fixes.
Pro tip: Point Bolt at the specific slow route so it optimizes the hot path instead of micro-tuning everything.
Add Error Handling & Edge Cases
30/30<context> App: [YOUR APP IDEA] Feature to harden: [FEATURE] </context> <task> Make this feature production-ready. Do the following: 1. Add loading, empty, and error states to every async UI in the feature. 2. Validate all inputs and show friendly, specific error messages. 3. Handle network failures and timeouts with a retry option. 4. Add a React error boundary so one crash does not blank the whole app. 5. List the edge cases you covered and any you recommend testing manually. </task>
Hardens a feature with loading/empty/error states, validation, and an error boundary.
Pro tip: Ask for the list of covered edge cases at the end so you can spot the gaps Bolt missed.
Frequently Asked Questions
Prompts are the starting line. Tutorials are the finish.
A growing library of 300+ hands-on tutorials on ChatGPT, Claude, Midjourney, and 50+ AI tools. New tutorials added every week.
7-day free trial. Cancel anytime.