These 40 prompts are written for Bolt.new, StackBlitz's in-browser, full-stack AI app builder that turns a plain-language message into working code, installs the packages, runs the dev server, and deploys, all inside the browser. Because Bolt runs on WebContainer (a browser Node.js runtime, so no native binaries, no Docker, no local Postgres), every prompt pins a JS-native stack and uses Supabase for the database and auth.
Each prompt is an app-level brief, not a screen-level ask: it names the product, the users, the core flows, the data model, the auth story, and the pages, then pins the stack and describes a design vibe. Fill the [bracketed placeholders] with your own details. Every message spends tokens even when a build fails, so a tight prompt is the cheapest prompt. For the reasoning behind these patterns, see how to prompt Bolt.new for full-stack apps, and for the quick reference grab the Bolt.new prompt cheat sheet.
Full-stack apps
Bolt is at its best when you zoom out from "build me this screen" to "build me this app." Name the product, the data model, the auth story, and the pages, then ask Bolt to plan first and build the shell plus one core feature before anything else. For a deeper set, see Bolt.new prompts for full-stack apps.
1. Plan-first full-stack app brief
I want to build [app: e.g. a team task tracker]. Before writing code, outline a short plan: the core user stories, the data model (tables and fields), the pages and routes, where auth is required, and the Supabase tables and policies you will create. This runs in Bolt on WebContainer, so use a browser-friendly, JS-native stack and Supabase for the database, no local Postgres. Stack: Vite + React + TypeScript + Tailwind, Supabase for DB and auth. Design vibe: clean, minimal, high-contrast. Do not generate code yet. When I approve the plan, build in this order: (1) Supabase schema, (2) app shell + auth, (3) the main list page, (4) create/edit, (5) polish.Why it works: a plan plus an explicit build order turns a big app into safe, reviewable steps that do not burn tokens on rework.
2. Team task tracker app shell
Build the shell of a team task tracker called [name]. Users: [small teams] who create projects and assign tasks. Core flow: sign in, pick a project, see its tasks in a list and board view, create and assign tasks. Data model: workspaces, projects, tasks (title, status, assignee, due date), and users. Pages: /login, /app (project list), /app/[project] (task list). Build the layout shell now: a top bar with workspace switcher and user menu, a left sidebar of projects, and an empty main area. Stack: Vite + React + TypeScript + Tailwind, Supabase for DB and auth (connect it via the Supabase button). WebContainer runtime, so no native deps. Design vibe: elegant, spacious, subtle borders, indigo accent. Build only the shell and routing now; I will add features next.Best for: establishing the architecture and design vibe once, so every later feature inherits it.
3. CRM with contacts and deals
Build a lightweight CRM for [a small sales team]. Data model in Supabase: contacts (name, email, company, tags), deals (title, value, stage, contact_id, owner), and notes (body, contact_id, created_at). Pages: a contacts list with search and tag filters, a contact detail with linked deals and a notes timeline, and a deals pipeline as a column-per-stage board. Auth: Supabase email/password, each user sees only their org's data. Stack: Vite + React + TypeScript + Tailwind, Supabase. Runs on WebContainer, so keep everything JS-native. Design vibe: professional, calm, data-dense but readable. Start with the schema and the contacts list; use realistic sample data.Why it works: the explicit data model with foreign keys gives Bolt real tables to generate instead of guessing at structure.
4. Booking and scheduling app
Build a scheduling app where [a solo consultant] shares a link and clients book [30-minute calls]. Core flow: a public booking page shows available days and time slots in the visitor's timezone, the visitor picks a slot and enters name/email/notes, and the booking is saved and confirmed. Owner side: a dashboard listing upcoming bookings and a page to set weekly availability. Data model in Supabase: availability rules, bookings (name, email, slot, status). Stack: Vite + React + TypeScript + Tailwind, Supabase for DB. WebContainer runtime. Design vibe: friendly, clean, generous whitespace. Build the public booking page and the bookings table first.Best for: a self-serve app with clear availability logic and a public plus private surface.
5. Notes app with markdown
Build a personal notes app with a two-pane layout: a searchable list of notes on the left and a markdown editor with live preview on the right. Features: create, rename, and delete notes, autosave on change, folders or tags, and full-text search. Data model in Supabase: notes (title, body, folder, updated_at) scoped to the signed-in user. Auth: Supabase email/password. Stack: Vite + React + TypeScript + Tailwind, Supabase, a lightweight markdown renderer that works in WebContainer (no native binaries). Design vibe: quiet, focused, monospace editor, soft neutral palette. Handle the empty state when there are no notes yet.Why it works: naming autosave and the empty state gives Bolt concrete behaviors instead of a bare CRUD form.
6. Job board with listings
Build a niche job board for [industry]. Public side: a home page listing jobs with search, filters ([remote, full-time, location]), and a job detail page with an apply button. Employer side: a gated form to post a job that saves to Supabase and appears pending until approved. Data model: jobs (title, company, location, type, remote, description, status), applications (job_id, name, email, link). Auth: Supabase, employers sign in to post. Stack: Astro + Tailwind for fast public pages, Supabase for data; keep it WebContainer-friendly. Design vibe: modern, editorial, big type. Build the public listing and detail pages first with sample jobs.Best for: a content-heavy public site with a small authenticated posting flow behind it.
Landing pages & marketing sites
Landing pages are Bolt's fastest win. Describe the exact sections, the single conversion goal, and the design vibe, and pin a static-friendly stack. Say what NOT to build so Bolt does not pad the page. For more, see Bolt.new prompts for landing pages.
7. SaaS product landing page
Build a marketing landing page for [product], a [one-line description]. Sections in order: sticky nav with logo and a [Start free] CTA, a hero (eyebrow, H1, subhead, primary + ghost CTA, framed product screenshot), a logo trust row, a 3-column feature grid with lucide icons, a "how it works" 3-step section, a testimonial block, a pricing teaser, an FAQ accordion, and a footer. Single conversion goal: sign up. Stack: Vite + React + TypeScript + Tailwind (static, WebContainer-friendly). Design vibe: high-tech, confident, dark hero fading to light, indigo #4F46E5 accent, radius 12px, font Inter, generous spacing. Use realistic copy, no lorem ipsum. Make it fully responsive down to 360px.Why it works: the ordered section list plus one conversion goal keeps Bolt from inventing filler blocks.
8. Waitlist launch page
Build a single-screen waitlist landing page for [product]. Sections: centered logo, an H1, a one-line value prop, an email capture (input + "Join the waitlist" button) with inline validation and a success state, and a small "No spam, unsubscribe anytime" line. Wire the submit to save the email into a Supabase table [waitlist] and show a thank-you state. Stack: Vite + React + TypeScript + Tailwind, Supabase. Runs on WebContainer. Design vibe: dark, high-contrast, glowing cyan #22D3EE accent, big type, lots of space. Fully responsive and keyboard-accessible. Do not add a nav or extra sections.Best for: a focused pre-launch page that actually captures signups into a real table.
9. Agency portfolio site with Astro
Build a portfolio site for [a design studio]. Pages: Home (hero, selected work grid, services, contact CTA), Work (filterable case-study grid), a case-study template (cover image, overview, role, outcome, gallery), and About. Shared nav and footer across pages. Stack: Astro + Tailwind for fast static output that runs in WebContainer, TypeScript. Design vibe: editorial, minimalist, oversized headings, muted palette, tasteful motion on scroll. Use placeholder projects with realistic names and descriptions. Build the Home page and shared layout first, then the Work grid.Why it works: pinning Astro and reusing one shared layout keeps a multi-page site consistent and light.
10. Pricing and features section
Add a pricing section to the current landing page with three plans: [Starter $0], [Pro $20/mo], [Team $60/mo]. Each plan is a card with a name, price, a monthly/annual toggle that updates prices, a feature list with checkmarks, a "Most popular" badge on Pro, and a CTA button. Below it, add an FAQ accordion with [6] questions. Stack stays Vite + React + TypeScript + Tailwind. Design vibe: match the existing tokens, highlight Pro with the primary-color border. Responsive: stack to one column under 768px. Only add these two sections; do not touch the hero or nav.Best for: a conversion-critical section where the middle tier must visually win.
11. Changelog and blog with MDX
Add a blog and a changelog to the current site. Blog: an index listing posts (title, date, excerpt, tag) and a post page rendered from MDX files in [content/blog]. Changelog: a reverse-chronological timeline of releases (version, date, grouped bullet points) from [content/changelog]. Both share the site's nav and footer. Stack: Astro + Tailwind + MDX, WebContainer-friendly (no native image tooling). Design vibe: clean reading layout, comfortable line length, subtle date labels. Create 3 sample posts and 3 sample releases. Do not change any existing marketing pages.Why it works: file-based MDX content keeps the build static and easy to edit without a database.
SaaS dashboards & admin
Dashboards work when you spell out the exact metrics, tables, and actions rather than asking for "a dashboard." Give Bolt the app shell first, then the data each widget shows and the decision the viewer needs to make. See Bolt.new prompts for SaaS dashboards for the full set.
12. SaaS dashboard app shell
Build a reusable dashboard app shell. Layout: a collapsible left sidebar with a logo and nav items ([Overview, Customers, Orders, Reports, Settings]) with lucide icons and an active state, a secondary section ([Help, Log out]) pinned to the bottom, a top bar with a search input, a notifications bell, and a user avatar menu, and a main content slot. Use it as the layout wrapper for every authenticated page via React Router. Stack: Vite + React + TypeScript + Tailwind, Supabase for auth. WebContainer runtime. Design vibe: dark sidebar #0F172A, light content, indigo #4F46E5 active state, radius 10px. Sidebar collapses to icons under 1024px and to a drawer on mobile. Build only the shell now.Best for: the layout wrapper every other dashboard page will live inside.
13. Analytics overview page
Inside the existing dashboard shell, build the Overview page. Top row: 4 KPI cards ([MRR, Active users, Churn %, Trial conversions]) each with a value, a delta vs last period, and a sparkline. Then a large line chart of [signups over 30 days] with a range selector, a bar chart of [revenue by plan], and a table of the [10 most recent signups]. Used by [a founder checking growth each morning] to spot what changed overnight. Stack: Vite + React + TypeScript + Tailwind, a WebContainer-friendly chart library (Recharts). Design vibe: primary #4F46E5, positive #16A34A, negative #DC2626, radius 12px. Use realistic sample data; wire it to Supabase later. Only edit the Overview route.Why it works: naming the four metrics and their deltas yields concrete widgets, and scoping to one route protects the shell.
14. Admin users table with actions
Build an admin users page inside the dashboard shell. A table of users ([avatar, name, email, role, status, last active]) with a search input, filter dropdowns for [role] and [status], column sorting, row checkboxes with a bulk-actions bar ([Suspend, Delete, Export]), pagination, and a right-side drawer that opens on row click to show user detail and actions. Back it with a Supabase table [users] and sample rows. Stack: Vite + React + TypeScript + Tailwind, Supabase. WebContainer runtime. Design vibe: radius 10px, muted #64748B labels. Responsive: collapse less-critical columns under 900px. Scope this to the /admin/users route only.Best for: the CRUD-heavy admin screen at the center of most internal tools.
15. Settings and team management
Build a settings page with left-rail tabs: [Profile, Account, Notifications, Billing, Team]. Profile: name, email, avatar upload to Supabase Storage, bio textarea. Notifications: grouped toggle rows. Team: a table of members ([name, email, role]) with an invite-by-email form and role dropdowns. Each tab has a sticky "Save changes" bar that enables only when a field is dirty. Stack: Vite + React + TypeScript + Tailwind, Supabase for data and storage. WebContainer runtime. Design vibe: radius 10px, primary #4F46E5. Responsive: tabs become a top scroll strip on mobile. Only add the /settings route.Why it works: a dirty-state save bar is a concrete behavior Bolt can implement, not a vague ask.
16. Kanban board with drag and drop
Build a Kanban board for [tasks]. Columns: [Backlog, In progress, Review, Done]. Each card shows title, assignee avatar, a label chip, and a due date. Features: drag cards between columns with a smooth animation, add a card via an inline composer at the bottom of each column, and open a card in a side panel to edit details. Persist card position and status to a Supabase table [tasks] (with an order field). Stack: Vite + React + TypeScript + Tailwind, a WebContainer-compatible drag-and-drop library, Supabase. Design vibe: airy, rounded cards, soft shadows, indigo accent. Handle the empty-column state.Best for: an interaction-rich board where drag state must persist to the database.
Supabase backend & auth
Bolt connects Supabase for a Postgres database and auth. Use the Connect Supabase button rather than asking in chat, then give Bolt the schema, the policies, and the auth flow explicitly. For a focused set, see Bolt.new prompts for Supabase backends.
17. Connect Supabase and model the schema
I have connected Supabase via the button. Create the database schema for [app]. Tables: [list tables with columns and types, e.g. projects (id uuid pk, name text, owner_id uuid fk to auth.users, created_at timestamptz default now())]. Add foreign keys, sensible indexes, and updated_at triggers where useful. Write the SQL as a migration I can review, then apply it. Do not turn on RLS yet, I will add policies in the next step. Confirm the tables exist and seed [each] with 5 realistic sample rows. Keep everything WebContainer-friendly; no local database.Why it works: asking for a reviewable migration first keeps schema changes explicit and reversible.
18. Supabase email and OAuth auth
Add authentication using Supabase Auth. Build a sign-in and sign-up page (email + password, plus an OAuth [Google] button), a sign-out action in the user menu, and route protection so [/app/*] redirects unauthenticated users to /login. Show the signed-in user's name and avatar in the top bar, and read the session on load so refreshes stay logged in. Handle and display auth errors inline (wrong password, email in use). Stack: Vite + React + TypeScript + Tailwind, Supabase Auth. WebContainer runtime. Design vibe: match the existing theme. Do not build a password-reset flow yet; I will add it later.Best for: a complete sign-in surface with real session handling and scoped access.
19. Row level security policies
Enable Row Level Security on all app tables and write policies so each user can only read and write their own rows. For [projects] and [tasks], scope by owner_id = auth.uid(); for shared tables like [workspace_members], allow read if the user belongs to the workspace. Write the policies as a reviewable SQL migration, explain each one in a comment, then apply it. After applying, test with the current signed-in user and confirm cross-user access is blocked. Do not change any application code, only the database policies.Why it works: spelling out the ownership rule per table gives Bolt correct policies instead of a permissive default.
20. CRUD wired to Supabase
Wire the [projects] list page to Supabase. Fetch rows from the [projects] table on load, show a loading skeleton and an empty state, and render them in the existing table. Add a "New project" button that opens a dialog form (name, status, owner) and inserts a row, inline edit that updates a row, and delete with a confirm dialog and optimistic UI. Re-fetch or update local state after each mutation so the list stays in sync. Stack: Vite + React + TypeScript + Tailwind, Supabase client. Runs on WebContainer. Only edit the files for the projects list and its dialog; do not change the app shell or auth.Best for: turning a static list into a real data-backed CRUD screen end to end.
21. Supabase realtime feature
Add realtime notifications backed by Supabase. A bell in the top bar shows an unread count badge; clicking it opens a dropdown of the latest [10] notifications ([icon, message, timestamp, read state]) with a "Mark all read" action. Back it with a Supabase table [notifications] and subscribe to realtime inserts so new rows appear without a refresh, plus a toast pop-in for each new event. Stack: Vite + React + TypeScript + Tailwind, Supabase realtime. WebContainer runtime. Design vibe: unread dot primary #4F46E5, radius 10px. Handle the empty state. Scope edits to the notifications components and the top bar only.Why it works: Supabase realtime is JS-native, so it runs cleanly in WebContainer without a custom socket server.
22. File uploads to Supabase Storage
Build a file upload feature using Supabase Storage. A drag-and-drop zone plus a browse button, accepted types [images and PDFs] with a size limit, a list of queued files each with a thumbnail/icon, name, size, a progress bar, and a remove button, plus a done state. Validate type and size before upload, upload to a [uploads] bucket scoped to the signed-in user, and store the returned path in a Supabase table [files]. Stack: Vite + React + TypeScript + Tailwind, Supabase Storage. WebContainer runtime, no native image processing. Design vibe: primary #4F46E5, error #DC2626, radius 12px. Keyboard-accessible.Best for: real uploads with validation and progress rather than a bare file input.
E-commerce & payments (Stripe)
For payments, describe the store, the cart, and where Stripe fits, and keep the flow WebContainer-friendly by using Stripe Checkout and a serverless webhook. Never put a secret key in client code. Ask Bolt to list the environment variables you must set.
23. Storefront with cart
Build a storefront for [a small shop]. Pages: a product grid with search and category filters, a product detail page (gallery, description, price, add-to-cart), and a slide-over cart with quantity controls and a subtotal. Cart state persists in localStorage. Data model in Supabase: products (name, price, description, images, category, stock). Stack: Vite + React + TypeScript + Tailwind, Supabase for products. WebContainer runtime. Design vibe: clean, product-forward, big imagery, plenty of whitespace, warm neutral palette. Seed 8 sample products. Build the grid and cart first; I will add checkout with Stripe next.Why it works: building the browse-and-cart surface before payments lets you validate the shopping flow first.
24. Stripe Checkout integration
Add Stripe Checkout to the storefront. On "Checkout," call a serverless route that creates a Stripe Checkout Session from the cart line items and redirects to Stripe's hosted page; on success, return to a /success page that shows the order summary, and on cancel return to the cart. Keep the Stripe secret key server-only, never in client code. Since this runs on WebContainer, use a serverless function route (not a native server) and read keys from env vars. Tell me exactly which env vars to set ([STRIPE_SECRET_KEY], [STRIPE_PUBLISHABLE_KEY]) and where. Stack: Vite + React + TypeScript + Tailwind, Stripe. Do not store card data; Stripe handles it.Best for: taking real payments without handling card data yourself.
25. Subscription billing with Stripe
Add subscription billing to the app. On the Billing settings tab, show the current plan and a usage meter, and let the user upgrade via Stripe Checkout in subscription mode for plans [Pro $20/mo] and [Team $60/mo], plus a "Manage billing" button that opens the Stripe Customer Portal. Store the Stripe customer_id and subscription status on the user's row in Supabase, and gate [premium features] behind an active subscription. Keep secret keys server-only in a serverless route (WebContainer-friendly). List the env vars and the Stripe products/prices I need to create. Stack: Vite + React + TypeScript + Tailwind, Stripe, Supabase.Why it works: tying subscription status to the Supabase user row is what lets the app gate features reliably.
26. Stripe webhook handler
Add a serverless Stripe webhook route at [/api/stripe/webhook]. Verify the signature against [STRIPE_WEBHOOK_SECRET], then handle [checkout.session.completed] by creating an order row in Supabase, [customer.subscription.updated] and [customer.subscription.deleted] by updating the user's subscription status. Return 200 on success and 400 on a bad signature, and log failures. Use the raw request body for signature verification. This runs as a serverless function in WebContainer, so no long-lived server. Stack: TypeScript, Stripe, Supabase. Add a comment block documenting each handled event, and tell me which env vars to set in my host.Best for: making payment state authoritative on the server, driven by Stripe events.
27. Orders and customer account area
Build a customer account area for the storefront. Pages: an orders list (order number, date, total, status) and an order detail (line items, shipping address, status timeline), plus a profile page to edit name and address. Read orders from the Supabase [orders] and [order_items] tables scoped to the signed-in user via RLS. Auth is Supabase (already set up). Stack: Vite + React + TypeScript + Tailwind, Supabase. WebContainer runtime. Design vibe: match the storefront, clean receipts-style layout. Handle the empty state for a customer with no orders. Only add the /account routes; do not touch checkout.Why it works: scoping orders by RLS means the account area is secure without extra client-side checks.
UI components & design
For single components, describe the states and props, pin the stack, and give the design tokens. Bolt returns a self-contained, reusable piece you can drop into the app. Establishing tokens early keeps every later build consistent.
28. Design system and tokens
Set up a centralized theme before we build more features. Define design tokens in the Tailwind config: colors (primary #4F46E5, secondary #22D3EE, success #16A34A, danger #DC2626, a neutral scale), radius 10px, font Inter, a spacing scale (4/8/12/16/24/32), and shadow presets (sm, md, lg). Add a light and dark variant driven by a class on the root. Refactor the existing components to read from these tokens instead of hard-coded values. Stack: Vite + React + TypeScript + Tailwind. Show me the tokens file so I can tweak it. Do not change any layout or copy, only the token wiring.Best for: establishing one source of truth so later prompts stay visually consistent.
29. Reusable data table component
Build a reusable DataTable component that takes columns and rows as props with TypeScript generics so any row shape works. Features: column sorting, a global search input, per-page pagination, a sticky header, row selection with a checkbox column, and a slot for a per-row actions menu. Include loading skeleton rows and an empty state. Render a demo with [8] sample rows of [orders]. Stack: Vite + React + TypeScript + Tailwind. WebContainer runtime. Design vibe: radius 10px, header background #F8FAFC, subtle border #E2E8F0. Keep it self-contained in one file so I can reuse it across pages.Why it works: asking for generics and prop-driven columns yields a table you can reuse everywhere.
30. Multi-step form wizard
Build a 3-step onboarding wizard. Steps: (1) [workspace name + logo upload], (2) [invite teammates by email, add rows], (3) [pick a starting template]. Include a progress indicator, Back/Next buttons, per-step validation with Zod that blocks Next until valid, state preserved across steps, and a final "Finish" that saves the payload to Supabase and shows a success screen. Stack: Vite + React + TypeScript + Tailwind, Zod, Supabase. WebContainer runtime. Design vibe: primary #4F46E5, radius 10px, calm and guided. Responsive and keyboard-navigable. Build it as a self-contained flow I can mount at /onboarding.Best for: first-run setup where each step must validate before advancing.
31. Import a Figma design
[Import this Figma frame.] Turn the design into a responsive React component. Map the Figma text and spacing styles to Tailwind tokens, extract repeated blocks into reusable components, and use semantic HTML. Keep it pixel-close on desktop and gracefully responsive on mobile down to 360px. Read colors and radii from the frame; font Inter. Stack: Vite + React + TypeScript + Tailwind, WebContainer runtime. Flag any Figma layer that does not map cleanly to a component so I can decide, and use realistic placeholder content, not lorem ipsum. Do not change any existing pages.Why it works: asking Bolt to extract repeated blocks avoids one giant unmaintainable component.
32. Command palette and shortcuts
Build a command palette component. It opens on [Cmd/Ctrl+K], shows a search input and grouped results ([Pages, Actions, Recent]), supports keyboard navigation with arrow keys and Enter, highlights the matched text, and shows an empty state. Actions are passed in as props. Close on Escape and on selection, trap focus while open, and wire correct aria roles. Stack: Vite + React + TypeScript + Tailwind. WebContainer runtime. Design vibe: radius 12px, muted #64748B, subtle border #E2E8F0. Add it to the app shell and register a few sample commands.Best for: a power-user shortcut that needs correct keyboard and focus behavior.
33. Empty, loading, and error states
For the [list/table on the current page], add proper empty, loading, and error states as three small reusable components. Empty: a centered icon, a short headline, one line of guidance, and a primary CTA ([Create your first item]). Loading: shimmer skeletons matching the real layout. Error: a friendly message with a Retry button that re-runs the fetch. Stack: Vite + React + TypeScript + Tailwind. WebContainer runtime. Design vibe: muted #64748B, radius 10px. Only edit the files for this page's states; do not change the happy-path layout or any other route.Why it works: these are the states teams skip, and naming all three makes the UI feel finished.
Iterating & fixing (scope, lock, deploy)
Bolt edits with diffs, so the biggest token saver is scoping each message to named files and locking finished code. These prompts cover the last mile: surgical edits, bug fixes, and getting the app deployed. For the reference card, see the prompt cheat sheet.
34. Scope an edit to one file
Only edit [src/components/Cart.tsx]. Do not change any other file. In the cart, add a quantity stepper (- and + buttons with a number input) per line item that updates the subtotal live, and a "Remove" link per item. Clamp quantity to a minimum of 1 and the item's stock as a maximum. Keep the existing styling and props; do not refactor unrelated code. If a change is needed in another file, tell me which and why before touching it, and wait for my go-ahead.Why it works: pinning the single file and requiring a heads-up before spreading keeps edits surgical and cheap.
35. Lock files and refactor safely
I have locked [the auth files and the app shell] in the editor so they are stable, do not modify them. Refactor the [projects] feature: extract the data-fetching logic into a custom hook [useProjects], move the dialog form into its own component, and keep behavior identical. Only touch files inside [src/features/projects]. After the refactor, confirm the app still builds and the projects list works exactly as before, and give me a short summary of what moved where. Do not change any styling or public props.Best for: reshaping a feature without risking the stable code you have already locked.
36. Fix a bug from an error message
The app throws this error: [paste the exact error and stack trace]. It happens when [describe the action]. Diagnose the root cause, explain it in one or two sentences, then apply the smallest fix that resolves it. Change only the files needed for the fix and tell me which you touched. Do not refactor unrelated code or add new dependencies unless strictly required (remember this runs in WebContainer, so no native modules). After the fix, confirm the build passes and the original action now works.Why it works: pasting the real error and asking for the smallest fix stops Bolt from rewriting half the app.
37. Add tests and type safety
Harden the [projects] feature. Add TypeScript types for the Supabase [projects] row and the API responses, remove any `any`, and add unit tests with Vitest for the [useProjects] hook and the create/update/delete logic, mocking the Supabase client. Also add a couple of React Testing Library tests for the list rendering its empty and populated states. Use tooling that runs in WebContainer (Vitest, no native test runners). Only add test files and types; do not change component behavior. Show me how to run the tests.Best for: locking in a feature's behavior before you build more on top of it.
38. Prepare for deploy to Netlify
Prepare this app for deployment to Netlify. List every environment variable it needs ([SUPABASE_URL], [SUPABASE_ANON_KEY], [STRIPE_SECRET_KEY], any others), what each is for, and which must stay server-only. Confirm the production build passes, flag anything that will break in production (missing env vars, a secret used in client code, a hardcoded localhost URL), and add any Netlify config needed for the serverless routes. Do not change app features. When it is ready, I will click the Deploy button; just get it deploy-clean and tell me the env vars to set in Netlify.Why it works: it makes Bolt audit env and build readiness before you ship, catching secrets leaked to the client.
39. Export to GitHub and document
Get this project ready to export to GitHub. Write a clear README with a project summary, the tech stack (Vite + React + TypeScript + Tailwind, Supabase, Stripe), setup steps, the full list of environment variables with placeholders, how to run locally, and how to deploy. Add a sensible .gitignore and .env.example. Make sure no secrets are committed. Do not change application code. After that I will use the GitHub button to push, so just prepare the repo hygiene and documentation.Best for: handing the project off or taking it out of Bolt to any host.
40. Convert to a PWA and optimize
Make this app a fast, installable PWA. Add a web manifest with [name, icons, theme color], a service worker for offline caching of the app shell using a WebContainer-friendly Vite PWA plugin, and an install prompt. Also do a performance pass: lazy-load routes, code-split heavy components, add width/height to images, and defer non-critical work. Keep all existing features and styling intact. Stack: Vite + React + TypeScript + Tailwind. Report the specific optimizations you applied and any Lighthouse-style wins, and tell me which icon sizes to provide.Why it works: pinning the Vite PWA plugin keeps offline support JS-native so it builds cleanly in WebContainer.
That is the full set of 40. If you keep one habit: write an app-level brief, pin the stack and acknowledge WebContainer, hand Bolt the data model and auth story, and build the shell plus one core feature first, then add the rest one scoped message at a time. For deeper packs, see the full-stack app prompts and the SaaS dashboard prompts, and if you also use Vercel's builder, compare the best v0 prompts.
Frequently Asked Questions
What is Bolt.new?
Bolt.new is StackBlitz's in-browser, full-stack AI app builder. You describe an app in plain language and Bolt writes the code, installs the npm packages, runs the dev server, and lets you deploy, all inside the browser with no local setup. It runs on WebContainer, a browser-based Node.js runtime, and integrates Supabase for database and auth, Netlify and Vercel for deploy, GitHub for export, and Stripe for payments. It is powered by Claude.
How should I structure a Bolt.new prompt?
Write an app-level brief, not a screen-level one. Name the product, the users, the core flows, the data model, the auth story, and the pages in plain language. Pin the tech stack (for example Vite + React + TypeScript + Tailwind, Supabase for DB and auth), describe the design vibe, and acknowledge the WebContainer runtime. Ask Bolt to establish the architecture and one core feature first, then add features one message at a time.
What is WebContainer and why does it matter for prompts?
WebContainer is the browser-based Node.js runtime Bolt runs on. It means no native binaries, no Docker, and no local Postgres, so prompts should favor JS-native and serverless approaches and use a hosted database like Supabase rather than a local one. Acknowledging the WebContainer runtime in your prompt keeps Bolt from choosing a stack that cannot run in the browser.
How do I save tokens in Bolt.new?
Every message spends tokens even if the build fails, so a tight, specific prompt is the main saver. Scope each edit to named files (only edit src/components/Cart.tsx), lock files that are done so Bolt will not touch them, ask Bolt to plan first before big builds, and use the built-in buttons to deploy or connect Supabase rather than asking in chat. Prompting technique matters more than the plan tier you pick.
Can Bolt.new build a full-stack app with a database and auth?
Yes. Bolt connects Supabase for a Postgres database and authentication, and emits server routes or serverless functions on the backend. Give it the data model and auth story in the brief, ask it to build the app shell and one core feature first, then add features. Use the Connect Supabase button rather than asking Bolt to wire it in chat.
How do I make focused edits without breaking working code?
Bolt uses diff-based editing, so scope each message to specific files or functions, for example only edit src/components/Cart.tsx and do not change anything else. Right-click a finished file in the editor and choose Lock file so Bolt will not touch stable code. Stating what NOT to change in the prompt keeps edits surgical and saves tokens.
How do I deploy an app built in Bolt.new?
Use the built-in Deploy button to ship to Netlify or Vercel in a couple of clicks, and use the GitHub export or sync button for any other host. Rather than asking Bolt to deploy in chat, ask it to confirm the build passes and list the environment variables you need, then click Deploy and set those variables in your host.
Should I use the Enhance Prompt button and plan-first mode?
Yes for large builds. The Enhance Prompt button (the sparkle icon) rewrites your prompt before sending and you can edit its suggestion. For anything beyond a single screen, ask Bolt to outline a plan or spec before it builds, so you can approve the direction before it spends tokens generating code.