How to Prompt Bolt.new for Full-Stack Apps (2026): Formulas + Examples

Bolt.new by StackBlitz turns a natural-language prompt into a running full-stack app — it writes the code, installs the npm packages, starts the dev server, and deploys, all inside the browser on WebContainer. How good that app is depends on one thing: how you brief it. The winning pattern is an app-level brief + pinned stack + WebContainer-aware constraints + design vibe + build order — you describe the whole product, not one screen, then build the shell and one core feature before adding anything else.

Copy this shape into the Bolt.new chat box and fill the brackets:

Build [app name], a [one-line product].
Users: [who] use it to [core outcome].
Core flows: [flow 1], [flow 2], [flow 3].
Data model: [entities and key fields].
Auth: [sign-in method and what's gated].
Pages: [page 1], [page 2], [page 3].
Stack: [Vite + React + TypeScript + Tailwind], Supabase for DB and auth.
Constraints: runs in WebContainer — JS-native/serverless only, no native binaries.
Vibe: [elegant / minimalist / playful], [reference].
Start with: the app shell + [first core feature] only. We'll iterate after.

This guide breaks that formula down, then gives you nine copy-paste prompts — a full app brief, an auth add-on, a scoped bug-fix, a redesign message, a plan-first spec, a ship message, and more. For a ready-made library, keep 40 Best Bolt.new Prompts open in another tab.

The Bolt.new prompt formula

A strong Bolt prompt answers five things before Bolt has to guess: what the app is, who uses it, what data it holds, how the shell looks, and what to build first. Miss any one and Bolt fills the gap with an average default that costs tokens to unwind. The biggest shift from prompting a UI tool is scope: zoom out from "build me this screen" to "build me this app," then let Bolt establish the architecture and a design vibe it carries through the rest of the build.

• App-level brief — product, users, core flows, data model, auth story, and pages, in plain language.
• Pinned stack — name the framework, language, styling, and integrations so Bolt doesn't pick for you.
• WebContainer-aware constraints — favor JS-native and serverless; use hosted Supabase, not a local database.
• Design vibe — a word or two (elegant, minimalist, high-tech, playful) plus a reference sets the feel.
• Build order — shell plus one core feature first, then one feature per message, edits scoped to named files.

Tip: the Enhance Prompt button — the sparkle icon next to the chat box — rewrites a thin prompt into a fuller one before you send it, and you can edit its suggestion. It's a fast way to expand a rough idea into a proper brief without spending a build.

Write an app-level brief

The app-level brief is the whole game. Name the product, the users, the core flows, the data model, the auth story, and the pages — plainly, not in code. Watch the difference. Here is a thin prompt that leaves everything to chance:

Build me a recipe app.

Why it falls flat: no users, no data model, no auth, no pages. Bolt guesses, and you re-prompt. Now the same intent as a real brief:

Build "Panfile," a personal recipe manager.

Users: home cooks who want to save recipes, plan a week of meals, and auto-build a shopping list.

Core flows:
1. Add or import a recipe (title, ingredients, steps, tags, photo, servings).
2. Browse and search recipes by tag and ingredient.
3. Drag recipes onto a 7-day meal planner, then generate a consolidated shopping list.

Data model:
- recipes (id, user_id, title, servings, tags[], photo_url, created_at)
- ingredients (id, recipe_id, name, quantity, unit)
- steps (id, recipe_id, position, text)
- meal_plan (id, user_id, date, recipe_id)

Auth: email + password via Supabase; every user only sees their own recipes and plans (row-level security).

Pages: Recipes (grid), Recipe detail, Add/Edit recipe, Meal planner (week view), Shopping list.

Stack: Vite + React + TypeScript + Tailwind; Supabase for Postgres DB and auth. Runs in WebContainer, so JS-native and serverless only — no native binaries, no local database.

Vibe: warm and editorial, like a cookbook — cream background, one accent color, large recipe photos, generous whitespace.

Start with ONLY the app shell (top nav + routing for the five pages) and the Recipes grid reading from Supabase with 3 seeded recipes. We'll build the rest after.

Why it works: Bolt knows the entities, the flows, the auth rules, and exactly what to build first, so the first generation is a foundation you extend rather than a demo you scrap. For more full briefs like this, see the Bolt.new prompts for full-stack apps.

Pin the stack, mind WebContainer

Bolt can emit React, Vue, Svelte, Astro, Next.js, or Vite with TypeScript and Tailwind, with Node/Express or serverless routes on the back end. Name what you want so it doesn't choose for you. Just as important: Bolt runs in WebContainer, a browser Node.js runtime with no native binaries, no Docker, and no local Postgres — so favor JS-native and serverless approaches and use hosted Supabase for data and auth. Say so in the prompt.

Add authentication to the current app.

- Use Supabase Auth with email + password (I'll click Connect Supabase).
- Add a Sign in and a Sign up page, plus a "forgot password" flow.
- Protect all app routes: unauthenticated users are redirected to Sign in.
- Store the session and show the user's email + a Sign out button in the top nav.
- Add row-level security so each user only reads and writes their own rows in the recipes, ingredients, steps, and meal_plan tables.

WebContainer note: keep this serverless — use the Supabase JS client, no custom auth server. Only touch the auth/routing files and the Supabase policy setup; don't change the Recipes grid UI.

Why it works: it pins Supabase Auth, names the exact pages and route protection, and reminds Bolt to stay serverless for WebContainer — and it scopes the change so the finished Recipes grid is left alone. For a one-page reference of stack lines and modifiers, the Bolt.new prompt cheat sheet is the fastest lookup.

Build order: shell and one feature first

Don't ask for the whole app in one shot. Build the app shell plus one core feature first — layout, navigation, and the single most important flow — so Bolt sets an architecture and design vibe to reuse. Then add features one message at a time. This keeps each generation small, reviewable, and cheap.

Next feature only — don't change existing files unless listed.

Build the Add/Edit recipe page:
- A form with title, servings, a tag multi-select, a photo upload to Supabase Storage, a repeatable ingredients list (name, quantity, unit), and a repeatable steps list.
- On save, insert into recipes/ingredients/steps and redirect to the new recipe's detail page.
- Reuse the design tokens and components already in the app.

Files you may edit: src/pages/RecipeEdit.tsx, src/lib/recipes.ts, and the router. Do not touch the Recipes grid or the auth files.

Best for: extending a working app without regressions. Naming the flow, the tables, and the exact files keeps the generation tight and the rest of the app stable.

Scoped edits and locked files

Bolt uses diff-based editing — it changes only the lines it needs, not whole files. Give it a target so it doesn't wander: name the file or function in every change message. When a file is finished, right-click it in the editor and choose Lock file so Bolt can't touch stable code. A precise fix beats a vague one just like a precise brief does:

Bug fix — scope to one file.

In src/pages/ShoppingList.tsx, the shopping list double-counts ingredients that appear in more than one planned recipe. Group by lowercased ingredient name AND unit, sum the quantities, and show one line per group with the total. If units differ for the same name (e.g. "g" vs "cups"), keep them as separate lines. Don't change any other file or any styling.

Why it works: it isolates the file, describes the exact wrong behavior and the exact fix, and forbids collateral edits — so Bolt's diff stays small and cheap. Every message spends tokens even when a build fails, so tight scoping is also the cheapest way to work. Compare a redesign message, which stays visual and still names its boundary:

Redesign the visual vibe only — no logic changes.

Shift the whole app from the current warm cookbook look to a crisp, high-tech feel:
- Background #0B0B0F, surfaces #15151B, text #F4F4F5, accent #6366F1.
- Border radius 14px on cards, 10px on inputs; 1px subtle borders, no drop shadows.
- Inter font; 700 headings, 500 body; spacing in multiples of 4px.
- Keep the same layout, routes, components, and data wiring — restyle only.

Best for: changing the feel without risking behavior. "Restyle only" plus concrete tokens keeps Bolt out of your logic. The full Bolt.new prompt roundup has more restyle and modifier prompts to fork.

Plan first for big apps

For anything bigger than a small app, ask Bolt to write a plan or spec before it builds — screens, data model, and build order — so you catch structural problems before they become code. Prefer this plan-first phrasing over Discussion mode, which is being retired on August 3, 2026.

Before writing any code, act as a product engineer and write a short build spec for [app idea]:
- The pages/screens and what each one does.
- The data model (tables, key columns, relationships) for Supabase Postgres.
- The auth story (who signs in, what's gated, row-level security rules).
- The core user flows, end to end.
- A build order: which shell + first feature to build, then feature by feature.

Keep it to plain language and a table for the data model. Do NOT generate the app yet — output the spec only. I'll approve it, then we build the shell + first feature.

Best for: aligning on structure before Bolt commits to code — and cheaper than discovering the wrong data model three features in. Once approved, feed the shell + first feature back as a build message. For fill-in-the-blank versions of these briefs, grab the Bolt.new prompt cheat sheet.

Connect Supabase, deploy to Netlify, export to GitHub

Use Bolt's built-in buttons for integrations rather than asking Bolt to do them in chat: Connect Supabase links a project for the database and auth, deploy publishes to Netlify (or Vercel) in a couple of clicks, and GitHub export pushes the code for any other host. Your prompt's job is to get the app deploy-ready, then you click. A ship message looks like this:

Get the app ready to ship, then I'll deploy from the buttons.

- Add a production-safe error boundary and a friendly 404 page.
- Make sure all Supabase keys come from environment variables (VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY), never hardcoded.
- Confirm the build runs with no TypeScript errors and no console warnings.
- Add a short README with setup + the env vars needed.
- List anything I must set in Supabase (tables, RLS policies, storage bucket) before the first deploy.

Don't add analytics or extra pages. When it's clean, tell me it's ready and I'll click Deploy to Netlify and, separately, export to GitHub.

Why it works: it hardens the app for production and hands you a checklist for the buttons, instead of asking Bolt to run deploys it can't fully own from chat. Add Stripe or a Figma import the same way — describe the integration in the brief, wire it with the Supabase client or Bolt's importer, and keep the message scoped.

Common mistakes to avoid

Most weak Bolt output traces back to a few prompt habits. Avoid these and the first build gets dramatically closer:

• Screen-level, not app-level. "Build me a dashboard" gives Bolt no product to reason about. Brief the whole app — users, flows, data, auth, pages.
• No data model or auth story. Bolt invents tables and guesses at access. Name the entities, key fields, and who can see what.
• Ignoring WebContainer. Asking for a local Postgres or a native binary produces a build that can't run. Stay JS-native and serverless; use Supabase.
• One giant prompt. A whole app in one message produces tangled code and burns tokens. Build the shell + one feature, then iterate.
• Unscoped edits. "Fix the app" invites collateral changes. Name the file or function and forbid other edits; lock files that are done.
• Doing integrations in chat. Use the Connect Supabase, Deploy, and GitHub buttons instead of asking Bolt to run them for you.

Fold the fixes into one default shape — app-level brief, pinned stack, WebContainer constraints, design vibe, and a build order — and reuse it for every app. For ready-made starting points, browse the best Bolt.new prompts; if you also build in a sibling tool, compare technique with the best v0 prompts.