These are skeletons, not finished prompts: copy one into the Bolt.new chat box, replace every [BRACKETED PLACEHOLDER] with your specifics, delete the lines you do not need, and send. Each one is built on how Bolt.new actually works — an app-level brief (the product, users, core flows, data model, auth story, and pages in plain language), a pinned stack line, and a WebContainer note so Bolt favors JS-native and serverless choices — and names the stack Bolt emits: Vite + React + TypeScript + Tailwind on the frontend and Supabase for the database and auth.

Filling brackets tightly matters because every message to Bolt spends tokens even when the build fails, so a specific brief is a cheaper brief. For paste-ready examples see the 40 best Bolt.new prompts; for the formulas behind these skeletons read how to prompt Bolt.new for full-stack apps, and keep the Bolt.new prompt cheat sheet open for structure and modifiers.

Advertisement

App brief templates

The biggest shift in Bolt is zooming out from "build me this screen" to "build me this app." These briefs name the product, users, flows, data model, auth, and pages in one message, then let Bolt build the shell and one core feature first.

1. Full app in one shot (app-level brief)

Build [APP_NAME], a [ONE-LINE PRODUCT DESCRIPTION].

Product: [WHAT IT DOES AND WHY].
Users: [USER_TYPE_1], [USER_TYPE_2].
Core flows: [FLOW_1], [FLOW_2], [FLOW_3].
Data model: [ENTITY_1] with [FIELDS], [ENTITY_2] with [FIELDS], related by [RELATION].
Auth: [SIGN-IN METHOD, e.g. email + Google via Supabase Auth]; roles [ROLE_1], [ROLE_2].
Pages: [PAGE_1], [PAGE_2], [PAGE_3], [PAGE_4].

Stack: Vite + React + TypeScript + Tailwind; Supabase for the database and auth.
This runs in WebContainer, so use JS-native and serverless approaches and Supabase for storage (no local database or native binaries).
Design vibe: [e.g. clean, modern, minimalist].

Start by building the app shell and [ONE CORE FEATURE] only. Do not build the other features yet — I will add them one message at a time.

How to fill it: put the product, users, flows, entities with fields, auth method, and page list in the brackets; keep the "shell + one feature first" line so Bolt gives you a design vibe to carry forward.

2. Plan-first spec (run before a big build)

Before writing any code, plan [APP_NAME], a [ONE-LINE DESCRIPTION].

Output a short spec covering:
- Core entities and fields: [ENTITY_1 with fields], [ENTITY_2 with fields].
- Main user flows: [FLOW_1], [FLOW_2], [FLOW_3].
- Pages/routes and what each does.
- Supabase tables + the auth story.
- Out of scope for v1: [WHAT TO SKIP].

Then list the files you will create, in build order.
Stack: Vite + React + TypeScript + Tailwind + Supabase, running in WebContainer.
Do NOT write code yet — wait for me to approve the plan.

How to fill it: describe the app, its entities and flows, and what to skip in v1; approve or edit the plan before you let Bolt generate. Prefer this over Discussion mode, which retires on August 3, 2026.

3. Landing page for a product

Build a marketing landing page for [PRODUCT_NAME], a [ONE-LINE DESCRIPTION].

Sections in order:
1. Sticky header: logo, links to [NAV_ITEMS], a [PRIMARY_CTA] button.
2. Hero: headline "[HEADLINE]", subhead "[SUBHEAD]", primary + secondary CTA, product-screenshot placeholder.
3. [SOCIAL PROOF / LOGO CLOUD].
4. Features: [FEATURE_1], [FEATURE_2], [FEATURE_3] as cards.
5. [PRICING / TESTIMONIALS / FAQ].
6. Footer with [FOOTER_LINKS].

Visitors are [AUDIENCE] deciding whether to [SIGN UP / BOOK A DEMO].
Stack: Vite + React + TypeScript + Tailwind, running in WebContainer (no backend needed yet).
Design vibe: [e.g. bold, high-tech]. Tokens: primary [#HEX], background [#HEX], radius [VALUE]. Responsive down to 360px. Do not add auth.

How to fill it: list your sections in order, the CTA labels, and the design tokens; delete any section you do not want and keep the "no auth" line for a pure marketing page.

4. Mobile app (Expo)

Build a mobile app [APP_NAME], a [ONE-LINE DESCRIPTION], with Expo (React Native).

Users: [USER_TYPE]. Core flows: [FLOW_1], [FLOW_2].
Screens: [SCREEN_1], [SCREEN_2], [SCREEN_3], with [TAB / STACK] navigation.
Data model: [ENTITY] with [FIELDS], stored in Supabase.
Auth: [METHOD] via Supabase Auth.

Stack: Expo + React Native + TypeScript; Supabase for data and auth. This runs in WebContainer, so keep it to JS-native, Expo-compatible libraries only.
Design vibe: [e.g. friendly, rounded]. Build the navigation shell and [ONE SCREEN] first, then stop for my review.

How to fill it: name the screens, navigation type, and one entity; the "Expo-compatible libraries only" line keeps Bolt inside what WebContainer can run.

Feature add-on templates

Once the shell exists, add one feature per message. Each add-on names the surface, the data it touches, and the pages it plugs into, so Bolt extends the app instead of rebuilding it.

5. Add authentication

Add authentication to [APP_NAME] using Supabase Auth.

Surface:
- Sign-up and sign-in screens with [EMAIL + PASSWORD] and [OAUTH PROVIDERS, e.g. Google, GitHub].
- A protected area: routes [PROTECTED_ROUTES] require a logged-in user; redirect anonymous users to sign-in.
- A user menu with [PROFILE / SIGN OUT].
- Roles: [ROLE_1], [ROLE_2]; [WHAT EACH ROLE CAN DO].

Wire it with Supabase Auth and session handling. Add inline validation and loading/error states.
Only touch the auth-related files and the route guard — do not restyle the rest of the app.
Stack stays Vite + React + TypeScript + Tailwind + Supabase in WebContainer. Use Bolt's Connect Supabase button for the integration.

How to fill it: list the providers, the protected routes, and the roles; the "only touch auth files" line uses Bolt's diff-based editing to keep the change contained.

6. Add payments (Stripe)

Add Stripe payments to [APP_NAME].

Surface:
- A pricing page with plans [PLAN_1 at PRICE], [PLAN_2 at PRICE].
- A checkout flow using Stripe Checkout for [ONE-TIME / SUBSCRIPTION].
- A [SUCCESS] page and a [CANCEL] page.
- After payment, mark the user's [FIELD, e.g. plan] in Supabase.

Use Stripe with a serverless route / Supabase edge function to create the Checkout session and handle the webhook (this runs in WebContainer, so no local server — use serverless).
Put keys in environment variables; do not hard-code them.
Only edit the pricing page, the checkout route, and the webhook handler.

How to fill it: name the plans and prices and whether it is one-time or subscription; keep the env-vars and serverless lines so Bolt does not try to run a local Stripe server.

7. Add a CRUD feature

Add a [ENTITY, e.g. tasks] feature to [APP_NAME] where users can create, read, update, and delete [ENTITY].

Surface:
- A list page: table/cards of [ENTITY] with search and filter by [FIELD].
- A create/edit form with fields [FIELD_1: type], [FIELD_2: type], [FIELD_3: type], [STATUS: enum].
- A detail view and a delete confirm.

Data: a Supabase table [TABLE_NAME] with those columns, scoped to the current user.
Wire create/read/update/delete against Supabase with optimistic UI. Validate [REQUIRED_FIELDS].
Only add the new pages and the [ENTITY] data layer; do not change existing screens.

How to fill it: define one entity fully with field types and the table name; the "scoped to the current user" line sets up the RLS you will confirm in the backend section.

8. Add search

Add a search and filter interface for [ITEM_TYPE] to [APP_NAME].

Surface:
- A search input over [SEARCHABLE_FIELDS].
- Filters: [FILTER_1: type], [FILTER_2: type], [FILTER_3: toggle].
- Results as [GRID / LIST] of cards showing [CARD_FIELDS], sorted by [SORT_OPTIONS].
- Empty state, loading skeletons, and a "clear filters" control.

Query [Supabase table TABLE_NAME]; reflect active filters in the URL so views are shareable.
Only add the search page and its query hook; keep the rest of the app unchanged.

How to fill it: name the searchable fields and each filter with its control type; keep the URL-filters line for shareable results and the "only add the search page" scope.

Advertisement

Fix & iterate templates

Bolt edits with diffs, so scope every fix to named files and lock the ones that are done. These templates keep bug fixes, refactors, and restyles from spilling into working code.

9. Scoped bug fix

Fix this bug in [APP_NAME]:

- What happens: [OBSERVED BEHAVIOR].
- What should happen: [EXPECTED BEHAVIOR].
- Steps to reproduce: [STEPS].
- Likely location: [FILE_PATH] (and [RELATED_FILE] if needed).

Only edit [FILE_PATH]; do not change any other file. Do not restyle or refactor working code.
Explain the root cause in one line, then show only the changed lines.

How to fill it: describe the observed vs expected behavior, reproduction steps, and the likely file; the "only edit [FILE_PATH]" line keeps Bolt's diff tight and cheap.

10. Refactor a named file

Refactor [FILE_PATH] in [APP_NAME] without changing its behavior.

Goals: [e.g. split into smaller components, extract [LOGIC] into a hook, remove duplication, add TypeScript types].
Keep the public API / props the same so nothing else breaks.
Only edit [FILE_PATH] (and create [NEW_FILE] if you extract something). Do not touch any other file.
After refactoring, confirm the UI and behavior are identical.

How to fill it: name the file and the refactor goals; the "keep the public API the same" and single-file scope lines stop the change from cascading. Lock the file afterward.

11. Change the design vibe

Restyle [APP_NAME] to feel [NEW_VIBE, e.g. more premium and minimalist] — visual only, no logic or layout structure changes.

Apply these tokens everywhere via the Tailwind theme (not per component):
- Primary [#HEX], accent [#HEX], background [#HEX], text [#HEX], border [#HEX].
- Radius [VALUE], base spacing [VALUE], heading weight [VALUE], body weight [VALUE].
- Density: [comfortable / compact].

Reference feel: [DESCRIBE OR NAME A SITE]. Keep all content, routes, and data wiring exactly as they are.

How to fill it: describe the new vibe, fill the full token set, and name a reference feel; the "visual only" line keeps Bolt from rearranging working screens.

12. Iterate on one component

Change [COMPONENT / FILE_PATH] only:

- [CHANGE_1, e.g. move the CTA above the fold].
- [CHANGE_2, e.g. add a [FIELD] and validate it].
- [CHANGE_3, e.g. replace the [OLD] with [NEW]].

Keep everything else exactly as it is; do not restyle or remove anything I did not mention.
Only edit [FILE_PATH]. Preserve the current design tokens and layout.

How to fill it: list only the edits you want and the one file to touch; the "keep everything else" line prevents collateral redesigns. Right-click and Lock file on anything already finished.

Backend & Supabase templates

Bolt builds the backend through Supabase: Postgres tables, row-level security, and edge functions. Name the schema, the policies, and the function behavior so Bolt scaffolds data and UI together instead of guessing.

13. Design a Supabase schema

Create the Supabase schema for [APP_NAME].

Tables:
- [TABLE_1]: [col: type], [col: type], [col: type], created_at.
- [TABLE_2]: [col: type], [FK to TABLE_1], [col: type].
- [TABLE_3]: [col: type], [col: type].
Relationships: [DESCRIBE, e.g. one TABLE_1 has many TABLE_2].

Generate the SQL migration and connect it via Supabase (I will use the Connect Supabase button).
Add sensible defaults, not-null where appropriate, and indexes on [FIELDS I filter by].
Do not build UI yet — just the schema and types. This runs in WebContainer; use Supabase, not a local database.

How to fill it: list every table with typed columns and the relationships; the "schema only, no UI" line lets you review the data model before Bolt builds screens on top of it.

14. Add row-level security (RLS)

Add Supabase row-level security to [APP_NAME].

For table [TABLE_NAME]:
- Enable RLS.
- SELECT: a user can read rows where [CONDITION, e.g. user_id = auth.uid()].
- INSERT: allow when [CONDITION]; set [user_id] to the current user automatically.
- UPDATE / DELETE: only the [OWNER / ROLE] may modify their own rows.
- [ADMIN ROLE] can read/write all rows.

Write the policies as SQL and explain each in one line. Repeat for [OTHER_TABLES].
Do not change the app UI; only add the security policies.

How to fill it: state the read/write condition per operation and which role is the owner; the per-operation breakdown makes the policies auditable before you trust them.

15. Write a Supabase edge function

Write a Supabase edge function [FUNCTION_NAME] for [APP_NAME].

Trigger: [called from the client on ACTION / a webhook from SERVICE].
Input: [SHAPE OF THE REQUEST BODY].
It should: [STEP_1], [STEP_2], [STEP_3, e.g. write to TABLE, call [EXTERNAL API]].
Output: [RESPONSE SHAPE].

Use environment variables for secrets ([LIST]); never expose the service-role key to the client.
This is serverless (WebContainer has no local server). Add error handling and return proper status codes.
Only add the edge function and the client call site.

How to fill it: describe the trigger, input, steps, and output; the env-vars and "serverless" lines keep secrets safe and stop Bolt from spinning up a local server it cannot run.

16. Seed and connect data

Seed [TABLE_NAME] in Supabase with [N] realistic rows for [APP_NAME], covering [VARIETY, e.g. every status and edge case].

Then wire [PAGE / COMPONENT] to fetch and render this data from Supabase instead of the current mock array.
Handle loading and empty states. Keep the existing layout and styling.
Only edit [PAGE_FILE] and the data hook; do not change other screens.

How to fill it: name the table, row count, and the page to wire; swapping mock data for a real Supabase query is a small, scoped step once the schema exists.

Ship templates

Getting deploy-ready is a prompt; the deploy itself is a button. These prep the app, then you click Deploy (Netlify or Vercel) or use GitHub export — use the built-in actions rather than asking Bolt to do them in chat.

17. Prepare to deploy to Netlify

Get [APP_NAME] ready to deploy to Netlify.

- Confirm the production build works (Vite build, no errors).
- Move all secrets to environment variables and list which env vars I must set in Netlify: [KNOWN VARS].
- Add a [netlify.toml] if needed with the correct build command and publish directory.
- Handle SPA routing (redirects) so client routes work on refresh.
- Make sure the Supabase URL and anon key come from env vars.

Tell me exactly what to set before I click Deploy. Do not change app features.

How to fill it: list any env vars you already know; after Bolt reports what to set, use Bolt's Deploy button to publish to Netlify rather than asking it to deploy in chat.

18. Export to GitHub

Prepare [APP_NAME] for GitHub export.

- Add a clear README with setup steps, the stack, and required environment variables.
- Add a .gitignore covering node_modules, build output, and .env files.
- Add a .env.example listing every variable with placeholder values (no real secrets).
- Confirm nothing sensitive is committed.

Then I will use Bolt's GitHub export/sync to push this to a repo. Do not change app behavior.

How to fill it: just name the app; Bolt handles the housekeeping, then you click GitHub export or sync to push to a repo you can host anywhere.

19. Connect a custom domain

I deployed [APP_NAME] to [Netlify / Vercel] and want to connect the custom domain [DOMAIN].

- Tell me the exact DNS records to add at my registrar ([REGISTRAR]) to point [DOMAIN] (and www) at the deploy.
- Explain how to enable HTTPS and confirm the certificate is issued.
- List anything I should update in the app for the new domain (e.g. Supabase auth redirect URLs, allowed origins, canonical URL).

Do not change app features; this is deployment configuration only.

How to fill it: name the host, domain, and registrar; the last bullet catches the Supabase redirect URLs that break auth on a new domain if you forget them.

20. Pre-launch checklist pass

Do a pre-launch review of [APP_NAME] before I ship.

Check and fix, one file at a time:
- Broken links, dead buttons, and console errors.
- Loading, empty, and error states on every data-driven screen.
- Mobile responsiveness down to 360px.
- That no secrets are exposed to the client and RLS is on for every table.
- Basic accessibility: labels, focus states, alt text.

Report what you find as a list first; then fix items I approve, editing only the relevant file each time.

How to fill it: just name the app; the "report first, then fix what I approve, one file at a time" flow keeps a broad audit from turning into an unscoped rewrite.

Frequently Asked Questions

How do I use these Bolt.new prompt templates?

Copy a skeleton into the Bolt.new chat box, replace every [BRACKETED PLACEHOLDER] with your specifics (product, users, flows, data model, auth, pages), delete lines you do not need, then send. Each template follows an app-level brief structure and pins the stack Bolt emits, so you only fill the blanks. Bolt takes plain natural language, so there are no CLI flags or slash-commands to learn.

Why do the templates pin the tech stack?

Bolt.new generates real code and runs it in WebContainer, its in-browser Node.js runtime. Pinning the stack once (Vite + React + TypeScript + Tailwind, Supabase for DB and auth) means Bolt does not guess a framework and you get consistent output. Because every message spends tokens even when a build fails, a specific prompt is a cheaper prompt.

Should I ask Bolt to plan before it builds?

For anything larger than a small change, yes. Use the plan-first template so Bolt outlines a plan or spec and a file list you can approve before it writes code. This catches wrong assumptions cheaply. Discussion mode is being retired on August 3, 2026, so prefer asking Bolt to plan first in the prompt itself. See how to prompt Bolt.new for full-stack apps for the workflow.

What is the WebContainer note for?

Bolt.new runs entirely in WebContainer, a browser-based Node.js runtime with no native binaries, no Docker, and no local Postgres. The templates include a WebContainer line so Bolt favors JS-native and serverless approaches and uses a hosted database like Supabase instead of a local one, which avoids builds that cannot run in the browser.

How do I stop Bolt from editing files I did not mention?

Scope each message to named files. Bolt uses diff-based editing, so telling it to only edit src/components/Cart.tsx keeps changes contained and saves tokens. Right-click a finished file in the editor and choose Lock file so Bolt will not touch stable code. The fix and refactor templates above bake both habits in.

How do I deploy or export what Bolt builds?

Use Bolt's built-in buttons rather than asking in chat: Deploy publishes to Netlify (or Vercel) in a couple of clicks, and GitHub export/sync pushes the code to a repo for any host. The ship templates give you the prompt to get the app deploy-ready first, then you click Deploy or Export. See more finished examples in the best Bolt.new prompts roundup.

Can Bolt.new build a full backend?

Yes, through Supabase. Bolt wires a Postgres database, auth, row-level security policies, and edge functions via the Supabase integration. The backend templates name the tables, columns, RLS rules, and function behavior so Bolt scaffolds schema, policies, and UI together instead of guessing.

Do the templates need a paid Bolt plan?

No. They are tier-agnostic. Bolt.new has token-based plans (Pro at $20/mo for 10M tokens, Pro 50, Pro 100, Pro 200, and Teams pooling). Prompting technique matters more than tier, and a tight, specific brief is what saves tokens on every plan since every message spends them.

Advertisement