How to Use Bolt.new to Ship a Full-Stack App in an Afternoon

April 15, 2026 · Editorial Team · 5 min read · bolt-new full-stack deployment

Bolt.new is the tool that gets the most "wait, it does that?" reactions from developers who haven't tried it. You describe an app, it scaffolds the code in a browser-based environment with a live preview, you connect a database, and you deploy. No local setup. For the right kind of project, especially an internal tool or a quick MVP, that speed is real.

The honest version: Bolt is excellent for getting to a working first version fast, and it has specific failure modes you need to know about before you rely on it for anything production-facing. Here's both sides.

What Bolt.new actually is

Bolt.new is a browser-based development environment powered by WebContainers, the same technology behind StackBlitz. It runs a real Node.js process in your browser tab. When you describe an app, Bolt's AI agent scaffolds files, installs packages, and starts a dev server, all without touching your local machine.

This means you get a live preview of your app within 60-90 seconds of a good starting prompt. You can edit the code directly (there's a file tree and editor), or keep prompting the agent to make changes.

The stack Bolt defaults to is React + Vite + Tailwind on the front end, with support for Node/Express or Next.js for the back end. It has integrations for Supabase (for database and auth) and Netlify/Vercel for deployment.

Writing a starting prompt that actually works

The quality of your initial prompt determines whether you spend 10 minutes tweaking or 2 hours correcting. A good Bolt prompt includes:

What the app does (one sentence).
The main entities/data models.
The specific screens you need.
Any specific tech requirements (e.g., Supabase, TypeScript).

A weak prompt: "Build a task manager."

A good prompt:

Build a task manager web app with these features:
- Create, edit, and delete tasks
- Tasks have a title, description, due date, and status (todo/in-progress/done)
- Tasks list view with filtering by status
- Simple auth: email/password login using Supabase Auth
- Store tasks in a Supabase postgres table
Stack: React, TypeScript, Tailwind CSS, Supabase

The more specific you are about data models and screens, the less back-and-forth you'll do. Bolt will scaffold the Supabase schema, the auth flow, and the CRUD operations from a prompt like the one above. In testing, a prompt with this level of detail gets me to a working app in under 30 minutes.

Connecting a Supabase database

Bolt has a dedicated Supabase integration that handles the connection automatically. Here's the sequence:

Start a new project at bolt.new and enter your initial prompt.
Once the scaffold is generated, look for the Supabase icon in the left sidebar.
Click "Connect to Supabase" and either create a new Supabase project or connect to an existing one.
Bolt will generate the SQL migrations for any tables described in your prompt and run them against your Supabase instance.
It also writes the Supabase client initialization code and injects your project URL and anon key as environment variables automatically.

The automatic migration generation is genuinely useful. For simple schemas (tasks, users, posts, comments), Bolt gets the SQL right. For anything involving foreign keys, RLS (Row Level Security) policies, or more than 3-4 tables, review the generated migrations before running them.

One thing to check: RLS policies. Bolt often creates tables but leaves RLS disabled or creates permissive policies that allow all authenticated users to read all rows. For a personal tool or internal app, that's fine. For anything where users should only see their own data, you need to add proper RLS policies. Bolt won't do this automatically unless you specifically ask for it in your prompt.

Iterating on the app

After the initial scaffold, you interact with Bolt through the chat panel to make changes. The workflow is: describe the change, Bolt edits the relevant files, the preview updates.

For UI changes, be specific about which component and what behavior:

In the task list, add a badge showing the task status. 
Use a green badge for done, yellow for in-progress, and gray for todo.

For logic changes, describe the business rule:

When a task's due date is in the past and the status is not done, 
show the due date text in red.

For schema changes, describe the new field and its behavior:

Add a priority field to tasks: values are low, medium, high. 
Default to medium. Show the priority as a colored dot in the task list.

Each change goes through the same cycle: Bolt edits files, preview updates, you check it. The preview is live; you can interact with it (create tasks, log in, etc.) to verify the behavior, not just the appearance.

Deploying from Bolt

Bolt has one-click deployment to Netlify. The button is in the top-right of the Bolt interface. Clicking it:

Builds the app (Vite build or Next.js build, depending on your stack).
Deploys to a Netlify subdomain (yourapp.netlify.app).
Sets up a CI/CD pipeline so future changes you make in Bolt auto-deploy.

The Netlify deployment is free for hobby projects. For a custom domain, you need a Netlify account and domain setup (standard Netlify custom domain flow).

For Vercel deployment, the process is manual: download the code from Bolt (there's an export/download button), push it to a GitHub repo, and connect that repo to Vercel. It's more steps but gives you more control.

Environment variables (your Supabase URL and keys) are handled automatically for the Netlify integration. For Vercel or any other host, you'll need to set them manually in the platform's environment variable settings.

Where Bolt struggles

Being direct about the limitations saves time:

Large codebases. Bolt is excellent for projects under about 30-40 files. Beyond that, the agent loses track of the full context, and you'll start seeing changes that break other parts of the app. At that point, export the code and continue in a local environment.

Complex state management. If your app needs something beyond basic React state (Zustand, Redux, complex server state), Bolt's scaffolded solutions tend to be fragile. It works for simple CRUD; it doesn't work well for real-time features, complex optimistic updates, or multi-step workflows.

Custom authentication flows. Bolt handles Supabase's email/password auth well. Social auth (OAuth with Google, GitHub) works if you ask for it explicitly. Anything custom like magic links with custom email templates, multi-tenant auth, or enterprise SSO will require manual work after exporting.

Testing. Bolt doesn't generate tests. If your project needs tests, plan to add them after exporting the code to a local environment.

Debugging. The error messages in Bolt's console are less detailed than a local dev environment. For runtime errors that aren't obvious from the UI, you'll want to export and debug locally.

For a 4-6 hour MVP where you need something functional and deployable, Bolt is hard to beat. For anything you're planning to maintain and grow over months, treat Bolt as a scaffolding tool and plan to graduate to a local setup once the initial version is working.