Photo by Christina Morillo on Pexels

How to Build an App with Bolt.new: Step-by-Step Tutorial

By Kevin Amayi · May 12, 2026 · 10 min read

A client needed a working prototype before a Monday presentation. It was Thursday evening. I had the backend done but needed a frontend that wouldn’t embarrass either of us. I opened Bolt.new, described the app in a single paragraph, and had a working UI running in the browser in about forty minutes. Functional enough to demo. The client never asked what stack I used.

That is what building an app with Bolt.new looks like in practice: not a revolution, just a genuine shortcut to a first working version. This guide covers how to do it — from the initial setup and how to prompt effectively, through iterating past errors, connecting a database, and getting to a live URL. It also covers the three situations where Bolt.new is the wrong tool.

What Is Bolt.new

Bolt.new is an AI-powered full-stack app builder from StackBlitz. You describe what you want — in plain English — and it generates a complete web application in a browser-based IDE. No local environment. No npm install. No blank vite.config.ts to configure.

The default output is a React frontend with Vite and Tailwind CSS, TypeScript, and — depending on what your prompt asks for — a Node.js backend and a Supabase-connected database. You can edit the generated code directly in the built-in editor, push follow-up prompts to change specific behavior, or export the whole project to GitHub and continue in a local environment.

Bolt.new sits somewhere between a no-code builder and a traditional IDE. You write no boilerplate — you write prompts. The difference from tools like Webflow is that Bolt.new produces actual code you can read, modify, and take with you. The output isn’t locked in a proprietary format.

For more on how Bolt.new compares to other AI app builders, the Bolt.new tutorial for developers covers the tool’s strengths and limitations in more depth.

Setting Up Your First Project

Go to bolt.new. You don’t need an account for your first session, but you will hit a usage limit quickly on anything non-trivial. Sign up — the free tier is enough to test a concept and run through a few iterations.

The home screen shows a chat input. Type your first prompt there. Three panels appear after the first generation:

• Chat — where you give instructions and see Bolt.new’s responses
• Code editor — the generated files, editable directly like a normal IDE
• Preview — a live browser preview that updates as the code changes

Before building anything serious, do three things:

1. Connect GitHub. Bolt.new can sync your project to a repository. Do this early. Once you have something worth keeping, you want version control.
2. Add environment variables. Click the Environment tab in the editor to add API keys, Supabase connection strings, and anything else your app needs to talk to the outside world.
3. Consider a starting template. Bolt.new offers blank projects and pre-configured templates. If you know you want React with Supabase, starting from the right template saves a round of prompting.

Writing Prompts That Actually Work

The quality of your Bolt.new project correlates almost directly with the quality of your first prompt. Vague inputs produce vague apps. Specific inputs produce usable ones.

Compare these two prompts:

Vague:

Build me a task management app.

Specific:

Build a task management app. Users can create tasks with a title and optional description,
mark them complete, and filter by status: all, active, completed. Use Supabase for the
database. The UI should use Tailwind CSS — white background, dark text, blue accent (#4a6cf7).
Include form validation: the title field is required, max 120 characters. Show an error
message below the field if validation fails.

The second prompt gives Bolt.new the feature list, data storage choice, design direction, and edge cases to handle. You’ll still iterate, but you start much closer to what you wanted.

After the initial generation, use short, focused follow-up prompts. One change at a time:

• “Add a delete button to each task.”
• “The filter buttons should be pill-shaped with a border.”
• “The task list should scroll independently from the header.”

Multi-part requests get partially applied often enough that debugging them is annoying. One request, one result, confirm it works, move on. (This is not Bolt.new-specific — it is annoying everywhere.)

Iterating and Debugging

Bolt.new will generate code that doesn’t work. This is not a knock — every AI coding tool does it, and the fix is almost always the same: tell the tool exactly what broke.

When something breaks, paste the error message directly into the chat. The full error — copy it from the browser console or the terminal panel, not a paraphrase you wrote from memory. Bolt.new reads the stack trace and usually identifies the fix without you explaining anything further.

When the same error comes back after two attempts, change your approach. Instead of repeating the error, describe the expected behavior:

When I click "Add Task", nothing happens. The task should appear in the list immediately
without a page reload. No errors in the console — it just doesn't respond to the click.

That gives Bolt.new a different angle. Repeating the same prompt twice produces the same result. (Worth saying once, apparently.)

A few other patterns that work:

• Ask for one change at a time. Bolt.new handles focused requests better than broad refactors.
• Start a new session if things go sideways. It is faster to start fresh than to talk Bolt.new out of a structural choice it has committed to.
• Edit the code directly for small fixes. Prompting Bolt.new to change a single CSS property is slower than changing it yourself in the editor. Both work — one of them takes fifteen seconds.
• Check the preview panel after every change. Not every generation succeeds silently. Bolt.new sometimes makes changes that break something else without flagging it.

For developers already comfortable with a code editor, the Cursor AI tutorial shows how to bring that same AI-assisted iteration into a local environment — which is where most Bolt.new projects end up eventually.

Connecting a Database and Going Full Stack

Bolt.new’s default output is a frontend-only app. If you need persistent data — user records, uploaded files, anything that survives a page refresh — you need to connect a backend service.

The recommended path is Supabase. Bolt.new has built-in Supabase integration: connect your Supabase project directly from the Bolt.new interface and Bolt.new generates the schema, the client setup, and the component changes.

Step by step:

1. Create a Supabase project at supabase.com
2. In Bolt.new, click the Supabase integration icon in the toolbar
3. Paste your Supabase project URL and anon key
4. Tell Bolt.new what data to store: "Add a Supabase table called tasks with columns: id (uuid, primary key), title (text, not null), completed (boolean, default false), created_at (timestamp with time zone, default now())"
5. Bolt.new generates the migration, the Supabase client configuration, and updates components to read from and write to the table

The generated Supabase calls work. The security rules sometimes don’t. Bolt.new occasionally generates Row Level Security policies that let any authenticated user read any other user’s records. Check the RLS settings in the Supabase dashboard before making anything public-facing.

If your app needs authentication, include it in the initial prompt rather than adding it after:

Add user authentication using Supabase Auth. Only authenticated users can create and view
tasks. Each user should only see their own tasks — add Row Level Security to the tasks
table so users can only access rows where user_id matches their auth.uid().

Adding authentication after you’ve already built the data model is possible. It is also annoying. Starting with it baked in is the better call.

If your workflow needs more than a database — automated emails, webhooks, integrations with other services — the Make.com tutorial covers connecting those kinds of services to a web app without writing the integration code yourself.

Deploying Your Bolt.new App

Bolt.new includes one-click deployment to Netlify, available from the toolbar. Connect your Netlify account, click deploy, and the app is live in about ninety seconds. No configuration required for a frontend-only project.

For Vercel:

1. Use the GitHub sync to export the project to a repository
2. Import the repository in Vercel — it auto-detects React plus Vite and sets the build settings
3. Add environment variables in the Vercel project dashboard before deploying

The environment variables matter. Bolt.new generates references to VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY (and whatever else you’ve added). If those aren’t set on the deployment platform, the deployed app fails to connect to Supabase and you get blank screens instead of data.

Bolt.new does not handle custom domains, SSL beyond the platform default, or CDN configuration. Those are Netlify and Vercel concerns — both platforms handle them through their dashboards with minimal friction.

The Cost of Shipping Code You Don’t Understand

The generated code works. It was not written by someone who knows your team’s conventions, your error-handling patterns, or your security requirements. Treat it as a first draft from a contractor who’s fast but has never worked in your codebase before.

Specific things to check in every Bolt.new project before going live:

• Input validation on the server side. Bolt.new often validates on the frontend only. A motivated user can bypass that and write anything to your database.
• Row Level Security in Supabase. Open the Supabase dashboard, go to Authentication → Policies, and verify that each table has policies that restrict access to the right users.
• Error boundaries. Generated React components often have no error boundaries. An unhandled API failure crashes the whole component tree rather than showing a graceful error state.
• Accessibility. Form labels, ARIA attributes, and keyboard navigation are hit-or-miss in generated output. Run the browser’s accessibility checker before calling it done.

Using Bolt.new to go faster is sensible. Using it to avoid understanding what you’re building is a different thing, and the difference shows up in production.

When NOT to Build with Bolt.new

Three situations where Bolt.new is the wrong tool:

You already have a codebase

Bolt.new builds apps from scratch in its own browser environment. It cannot add a feature to your existing Laravel API, modify your company’s Next.js monorepo, or drop into an existing project structure. For existing codebases, use a context-aware coding assistant instead. The Cursor AI tutorial covers that workflow in detail.

Security is the primary constraint

If you’re building something that handles health records, financial data, or authentication for a large number of users, the generated code needs a proper security review before it goes anywhere near production. Bolt.new is optimized for speed of generation. Security hardening is a separate pass that the tool does not do for you.

More than one developer needs to work on it

The Bolt.new editor is single-user. There is no branching, no pull request workflow, and no code review inside the tool. Once the project is complex enough that multiple people need to contribute simultaneously, export to GitHub and move to a standard development environment. The export is clean — this is not a trap, just a natural transition point.

If none of those apply — a prototype, a solo project, an internal tool, a client demo — Bolt.new is a reasonable choice. If you’re weighing it against Lovable, the practical difference comes down to UI polish: Lovable tends to produce more refined default output, Bolt.new gives you slightly more control over the code directly. See the Bolt.new vs Lovable comparison for a side-by-side breakdown.

Conclusion

A working frontend in forty minutes. The client presentation went well. I spent the weekend doing something other than hand-rolling Tailwind components for a page the stakeholders would click through exactly once.

Key things to carry forward:

• Write a detailed first prompt — scope, data storage, design direction, edge cases. The quality of the output reflects the quality of the input.
• Connect Supabase early if you need persistence. Adding it after the data model is already built is more work than it sounds.
• Read the generated code before shipping it to real users. Check RLS policies, server-side validation, and error boundaries at minimum.
• Use GitHub sync before the project gets complex. That is the moment to move it into a real development workflow.
• Netlify and Vercel both deploy Bolt.new projects without friction — add environment variables before the first deploy or the app ships broken.

One last thing Bolt.new cannot do: make the code yours just because it wrote it fast. That still requires reading it.