Bolt.new Review (Verified August 2026)

Bolt.new is worth $25 a month for a solo founder who needs to turn a scoped web-app idea into a hosted prototype and is willing to inspect the generated code. Skip it for a mature production system, a design-first non-technical workflow, or any project whose database you cannot afford to recover manually: Bolt's project rollback still does not restore the database.

Bolt.new at a glance: what it is

Bolt.new is a browser-based app builder that turns a written brief into editable application code, runs that code in an online development environment, and can add a database, authentication and hosting without making you assemble those services first. It sits between a no-code builder and an AI coding editor: you can work through conversation, but the output is still a codebase that can move to GitHub. That makes it strongest for prototypes, internal tools and tightly scoped web products, not for outsourcing every engineering decision to a prompt.

The current product is materially different from the one many earlier projects started with. Bolt's release notes say v1 Agent and Discussion Mode were retired on August 3, 2026. Remaining projects moved to Bolt Agent while retaining files and chat history, and Plan Mode became the place to reason through a build without immediately changing code. Voice dictation is also live, with speech transcribed into an editable prompt before it is sent.

Bolt.new vs the alternatives at a glance

Bolt.new wins the shortlist when you want the prompt, code, database and first deployment in one browser workflow. Lovable wins when visual polish and low-friction collaboration matter more than code-level control. Replit is the broader browser development workspace. Cursor is the better fit once an experienced developer already has a repository and wants an AI-native code editor rather than an all-in-one app builder.

The table hides one important distinction. Bolt.new, Lovable and Replit can all help start an application, while Cursor assumes you are comfortable living in code. Comparing them only by subscription price misses the cost of the handoff. A non-technical founder may pay the same $25 for Lovable Pro and avoid hours of code inspection. A developer may pay $20 for Cursor and avoid paying a prompt builder to reread a growing project on every message.

That is the review's governing rule: choose the environment that keeps the difficult part of your project visible. Bolt keeps infrastructure visible enough to graduate into GitHub. Lovable keeps design and collaboration visible. Replit keeps the broader development workspace visible. Cursor keeps the code itself visible.

Who Bolt.new is for, and who should skip it

Bolt.new is for builders who value a fast first working version but do not confuse that version with a finished system. The best buyer has a narrow workflow, can describe the data and permissions, and will inspect the resulting code or involve someone who can. The worst buyer arrives with a large product idea, no acceptance criteria, sensitive data and the belief that more prompts will resolve every architecture problem.

Good fit: a solo founder validating one workflow

Bolt.new makes sense for a solo founder who needs to validate a bounded workflow before hiring a development team. Consider a scheduling product for independent tutors. The useful first version needs tutor profiles, available time slots, a booking form, confirmation email and a small admin view. Those pieces map cleanly to a database, authentication and a hosted interface.

The founder can describe the user roles, ask Bolt to create the tables and login flow, publish a private or public preview, and put the code in GitHub before inviting early users. The product still needs testing, privacy decisions and maintenance, but Bolt compresses the distance between a written workflow and something a user can click.

This fit breaks when the founder cannot tell whether a permission check belongs in the interface or the database. A button that disappears for the wrong user is not the same as a secure row-level policy. Bolt can generate both, but somebody must verify both.

Good fit: a product manager proving a flow before engineering commits

Bolt.new also fits a product manager who needs a convincing, data-backed prototype rather than another static mockup. A returns-approval tool, for example, can include a queue, a customer record, reason codes and role-specific actions. Stakeholders can use the flow and find missing states before an engineering sprint begins.

The product manager should treat the generated application as executable product discovery. The payoff is not that the prototype becomes production unchanged. The payoff is that the team learns whether the workflow makes sense while changes are cheap. Connecting GitHub provides a useful artifact for an engineer to inspect, but it does not turn the prototype into an approved architecture.

Good fit: a small agency with a clear handoff policy

Bolt.new can help a small agency build campaign tools, calculators, portals and prototypes when every project follows the same exit discipline. The agency should decide at intake whether the deliverable stays on Bolt hosting, moves to a client-owned repository, or becomes a custom build. That decision determines who owns domains, secrets, database recovery and future changes.

Teams features help with centralized access, organization sharing and design-system context, but the per-member meter matters. Each paid member receives an individual token allowance, and those tokens are not shared. An agency with one heavy builder and several reviewers can pay for unused capacity while the primary builder still needs more.

Skip Bolt.new for a design-first, non-technical team: choose Lovable

Lovable is the better skip-route when the team wants polished interface output, shared building capacity and fewer code-facing decisions. Lovable Pro is $25 per month with 100 monthly credits, unlimited users, credit rollover, top-ups, custom domains, roles, per-member credit limits, email support and design systems.

That unlimited-user model is a sharp contrast with Bolt Teams at $30 per member each month. Lovable's shared credits are not automatically more generous, and its meter is not directly equivalent to Bolt tokens. The advantage is organizational: a founder, designer and marketer can collaborate in one Pro workspace without multiplying the base subscription by headcount.

Choose Lovable when the first question is “Can the whole team shape this interface?” Choose Bolt when the first question is “Can we get a working codebase, infrastructure and GitHub handoff from the same browser?” If nobody on the team will inspect code, Bolt's added control is capacity you are unlikely to use well.

Skip Bolt.new for a broader cloud workspace: choose Replit

Replit is the better skip-route when you want a general browser development environment, agent concurrency and a wider path from small experiments to a managed developer workspace. Replit Core costs $20 monthly or $18 monthly billed annually and includes two parallel agents, unlimited workspaces and $20 toward its most capable models.

The more telling comparison appears higher up Replit's range. Replit Pro costs $100 monthly or $90 monthly billed annually and includes ten parallel agents, up to fifteen collaborators, up to fifty viewers and database rollback up to twenty-eight days. Bolt's built-in project Version History does not restore the database at all.

That does not make Replit universally better. It means a buyer who values concurrent agent work or documented database rollback should put those requirements above Bolt's simpler $25 starting point. Choose Bolt for a focused prompt-to-app path. Choose Replit when the development workspace itself is the product you are buying.

Skip Bolt.new for an existing repository: choose Cursor

Cursor is the better skip-route for an experienced developer whose application already exists. Cursor Individual Pro costs $20 per month and extends its Agent limits while adding frontier models, MCPs, skills, hooks and cloud agents.

Cursor does not remove the need to choose hosting, authentication or a database, which is precisely why it is the better tool after those decisions are already made. The developer edits the repository directly instead of asking an app builder to repeatedly synchronize and reinterpret the whole project.

Move to Cursor when the work changes from “create the product shape” to “modify this known codebase under established architecture and review rules.” The broader Codex, Claude Code and Cursor comparison is the better next read once direct code ownership becomes the center of the job.

Capability 1: full-stack web prototypes with database and hosting

Bolt.new's most valuable capability is not generating a page. It is keeping the interface, database, authentication and first deployment close enough that one person can model a complete workflow. That is why Bolt is more useful for an intake portal or booking product than for a marketing mockup that only needs attractive screens.

Consider a regional home-services company replacing an email-and-spreadsheet intake process. The product needs a customer form, a request record, a dispatcher queue, assignment to a technician and status history. A useful Bolt workflow starts by naming those entities and permissions, not by asking for “a modern service app.”

1. 1

   Define the workflow and roles

   Describe the customer, dispatcher and technician roles. Name the states a request can enter, what each role can see, and which actions move a request forward. This gives Bolt a behavioral model instead of a mood.

2. 2

   Ask for the data model explicitly

   Request tables for customers, service requests, assignments and status events. Bolt can create a database automatically when the project needs one, but an explicit model makes the result easier to inspect and reduces the chance that important state lives only in the interface.

3. 3

   Specify authentication and authorization

   Ask for email signup, login, password reset and role-based access. Bolt's documentation says authentication may not be added automatically, even when a database is. Verify the redirect URLs and permission rules before using a public preview.

4. 4

   Publish a disposable preview

   Both Free and Pro users can publish to a .bolt.host address. Keep the first dataset disposable. Invite a dispatcher to walk through an intake, assignment and closure while you record every missing state.

5. 5

   Move the code before the data matters

   Connect GitHub once the first stable workflow exists. Do not wait until customer records are valuable to discover how the project, database and deployment need to be separated.

Bolt Database reduces setup work. It can provision a database when the app needs one, includes authentication controls, exposes logs and secrets, and lets the user select Supabase instead during setup. Leaked-password protection is on by default when Bolt creates the database. If the database is claimed or connected through Supabase, that protection depends on the Supabase plan and is off on Supabase Free.

The important distinction is between generated functionality and verified behavior. A login screen can look complete while password-reset redirects point to the wrong location. A dispatcher queue can hide another customer's record in the interface while the database policy still permits access. Bolt's authentication settings expose site URLs, URI allow lists, providers and templates, but somebody must inspect them.

The deployment path is similarly convenient but bounded. Free hosting provides a .bolt.host address, 10GB of bandwidth and 333,333 monthly requests across the account. Pro hosting raises that to 30GB and 1 million monthly requests, adds custom domains through the paid plan and permits pay-as-you-go traffic. Those limits cover the first proof for many small apps, but they are account-wide, so several projects compete for the same allowance.

The wall appears at recovery. Bolt's project Version History does not restore the database. Rolling application files back to yesterday leaves today's database in place. That mismatch can be worse than having no rollback button because it invites a false assumption that code and data move together.

For the home-services example, imagine restoring application code from before a status field was renamed while the database retains the new schema. The interface and data can now disagree. Before a project becomes consequential, define database backups, schema migrations and a tested recovery route outside the comfort of the project timeline.

Capability 2: code ownership through GitHub

Bolt.new earns its place above a closed no-code builder because the application can live in GitHub and move to another host or development workflow. Portability is valuable only when you use it early. “The code can be exported” is not a recovery plan if the repository was never connected and nobody knows which commit matches the live database.

Bolt's GitHub documentation says a repository created from a Bolt project begins private on the main branch. Bolt automatically commits changes that do not break the project, checks GitHub every thirty seconds for outside updates, and supports creating or switching branches.

A sensible handoff workflow looks like this:

1. 1

   Connect after the first stable state

   Create the repository while the project is still disposable. Confirm that the expected files, environment examples and dependency manifests appear. Secrets should stay out of the repository.

2. 2

   Create a branch for each meaningful change

   Use a branch for a new payment flow, permissions change or redesign. Bolt keeps branch context separate, which reduces accidental crossover between unfinished work and the live line.

3. 3

   Review and merge in GitHub

   Bolt can create and switch branches but cannot merge them in-app. Open the pull request and merge in GitHub, where a developer can inspect the change and where the decision remains visible in repository history.

4. 4

   Reconcile before prompting again

   Wait for the merged state to return to Bolt, open the intended branch and verify the preview. Bolt checks GitHub for outside changes every thirty seconds, but a timer is not a substitute for confirming the state you are about to modify.

This workflow makes Bolt a starting environment rather than a cage. A developer can leave Bolt, work directly in the repository, deploy elsewhere and return later. That is especially useful when a prototype becomes valuable enough to need tests, observability, infrastructure review or a different backend.

There are two limits a team should name before calling this “normal Git.” First, merging happens outside Bolt. That means a non-technical team still needs to understand pull requests or rely on someone who does. Second, the vendor documents a rare concurrency case: if Bolt and GitHub update nearly simultaneously, Bolt keeps its changes and overwrites the GitHub version.

The practical response is not fear. It is ownership. Do not edit the same branch from Bolt and another environment at the same time. Use branches, merge through GitHub and make the repository the review record. If a project has reached the point where several developers change it continuously, Bolt should be one contributor to the workflow, not the source of truth.

Capability 3: mobile apps through Expo

Bolt.new can start a cross-platform mobile app through Expo, but the first prompt determines whether that path is smooth. Bolt's Expo guide says a project started for the web does not easily switch to mobile. “Make this mobile” is therefore an architecture change, not a finishing instruction.

Take a meal-planning product. A useful first prompt should say that it is a mobile app for iOS and Android, name the household and recipe data, and specify the phone interactions that matter. Bolt then uses Expo, a framework that lets one codebase target both mobile platforms and the web.

The preview loop is accessible. Open the mobile project, select Device Preview, scan the QR code in Expo Go and interact with the application on a phone. That catches layout, keyboard, navigation and touch problems that a desktop browser preview will hide.

The launch loop is not contained entirely inside Bolt. Publishing through official app stores requires downloading the code, opening it in a code editor, using a computer with Node.js LTS and Git, configuring Expo Application Services, and maintaining Apple or Google developer accounts. The build can also fail on certificates, platform-specific dependencies or store rules.

This is a useful boundary because it reveals who should own the product. A founder can use Bolt to prove a mobile flow without learning Swift or Kotlin. The same founder still needs a release owner who understands signing, store listings, privacy declarations, crash logs and platform review. Expo reduces platform duplication; it does not remove platform operations.

Use this workflow:

1. 1

   Declare mobile in the first prompt

   Name iOS and Android, the primary phone interaction, offline expectations and any camera, notification or location requirement before code is generated.

2. 2

   Validate on a physical phone

   Use Expo Go early. Test the smallest complete path, such as choosing meals, adding ingredients and returning to the saved plan after reopening the app.

3. 3

   Export before store work

   Move the code into GitHub and a local development environment before configuring store credentials. The repository should be the reviewed artifact that enters the release process.

4. 4

   Assign the store handoff

   Name who owns certificates, TestFlight or Google Play testing, release notes, privacy details and crash review. If nobody owns those tasks, the project is a prototype, not a mobile launch.

Choose Bolt for mobile when proving the product flow is the current risk. Skip it as the sole environment when native platform behavior, background services, deep device integrations or a disciplined app-store pipeline are already the hard part.

Capability 4: design-system-guided team builds

Bolt.new's design-system capability matters for teams that already have components, spacing rules and brand documentation. It does not magically turn a loose style guide into reusable production components. Source quality determines whether Bolt gets a true component library or merely imitates the colors and typography.

Custom design systems require a paid Teams plan. A team can point Bolt at a GitHub repository, NPM package, Storybook, documentation website or uploaded files. Bolt reads those sources and generates a Storybook inside Bolt so builders can browse the components it understands.

The strongest workflow is for a B2B software company that already publishes its button, form, navigation and data-display components as an NPM package. The team adds the package, links the supporting Storybook and gives agent instructions such as excluding deprecated components or using one theme. A product manager can then start a prototype from the design system rather than from generic UI.

Bolt's own guidance is candid about input quality. GitHub repositories and NPM packages often produce better results than a documentation website alone. A site with screenshots and usage notes may teach the visual theme, while a component package gives Bolt the implementation it can reuse.

There are operational limits. A paid team can add or sync a combined total of ten design systems per week. A local source upload accepts up to ten PDFs, images or other files. Conflicting frameworks, old components and mixed guidelines reduce quality, so adding more sources is not always better.

1. 1

   Choose the canonical component source

   Start with the repository or NPM package that the product team already treats as authoritative. Do not mix deprecated and current libraries in the same source set.

2. 2

   Add documentation for decisions, not decoration

   Include guidance that explains when to use a component, accessibility rules and theme constraints. Visual screenshots alone do not tell an agent how the component should behave.

3. 3

   Set narrow agent instructions

   Tell Bolt which framework, theme and package version to follow, and which components to ignore. A short exclusion is often more valuable than another folder of examples.

4. 4

   Build one representative flow

   Generate a form, validation state, empty state and results view. Compare the actual components and behavior with the system before rolling the setup across projects.

This capability justifies Bolt Teams when on-brand prototypes save repeated rework and the organization already maintains component code. It does not justify $30 per member for a founder with a logo, a font list and no reusable components. Lovable Pro includes design systems at $25 with unlimited users; Bolt's premium pays back when component-level source control and the wider Bolt build environment both matter.

Bolt.new pricing: every current tier and cost per outcome

Bolt.new's public monthly ladder is straightforward: $0 Free, $25 Pro, $30 per member for Teams and custom Enterprise. The difficult part is forecasting how tokens, shared hosting limits and headcount turn that base price into a cost per finished result.

The prices and limits below were verified on Bolt's live pricing page on August 27, 2026. The page also advertises savings of up to 28% with yearly billing. “Up to” is not a universal annual rate, so the exact monthly table is the clean comparison and the account checkout remains the authority for an annual quote.

Free is a product trial with a usable hosting allowance

Free includes public and private projects, unlimited databases, a .bolt.host deployment, 1 million monthly tokens and a 300,000-token daily limit. It is enough to learn how Bolt plans, generates and publishes. It is not a dependable way to finish a prompt-heavy app because the daily meter can stop work before the monthly allowance is gone.

Hosting has a harder consequence. Free includes 10GB of bandwidth and 333,333 monthly requests across the account. When the account reaches its monthly data limit, its sites stop serving content until the allowance resets. That is acceptable for a disposable preview and unacceptable for a business route that must stay online.

Pro is the default purchase for a solo builder

Pro is $25 monthly and starts at 10 million tokens without a daily cap. It removes Bolt branding, raises uploads to 100MB, adds private sharing, custom domains, SEO Boost, a choice of database provider and AI image editing. Pro hosting includes 30GB of bandwidth and 1 million monthly requests across the account.

Unused paid tokens roll over for one additional month and can remain valid for up to two months while the paid subscription stays active. That corrects the outdated claim that paid Bolt tokens never roll over. Free tokens do not roll over.

Pro users can keep a site online beyond the included traffic through pay-as-you-go bandwidth and requests, with a spending cap. The public hosting page does not publish the unit rate. You can control the maximum but cannot model an exact traffic-spike bill from the public page alone.

Token top-ups have their own gate. Bolt says reloads are available on the highest individual monthly Pro plan or any annual Pro plan. The reload cost varies by plan and appears inside the account, so the public $25 starting price is not a complete heavy-usage budget.

Teams charges for people, not a shared pool

Teams costs $30 per member each month. Every paid member receives an individual token allowance, and the tokens stay linked to that person instead of pooling across the team. Centralized billing does not mean centralized capacity.

That design is good when each member builds regularly. It is inefficient when one person builds and several people mostly review. A four-person team pays $120 each month and $1,440 each year before extra traffic, higher token allowances or third-party services.

Lovable Pro provides unlimited users for $25 monthly, or $300 yearly, against that four-person Bolt base of $1,440 yearly. The gap is $95 monthly and $1,140 yearly. The usage envelopes are not equivalent: Lovable users share 100 credits, while Bolt members receive separate token allowances and the Bolt platform includes its own build and infrastructure workflow. The comparison still exposes the purchase decision. Pay the seat premium only if multiple people need to build in Bolt or its team controls and design-system sources replace a meaningful handoff cost.

Enterprise is where governance becomes explicit

Enterprise uses custom pricing. It adds advanced security, SSO, audit logs, compliance support, custom workflows and SLAs, data governance and retention policies, hands-on onboarding and 24/7 priority support.

A company that requires those controls should not budget from the $30 Teams price and assume procurement can add the rest later. Ask for the Enterprise quote before building the proof around a requirement that only Enterprise claims to satisfy.

The cost-per-outcome calculation

Subscription cost per completed prototype is simple: divide the base subscription by the number of prototypes that reach a pre-defined acceptance test. Prompt count is an activity measure, not an outcome.

For a solo builder on Pro, the base subscription is $300 per year. If four prototypes reach an acceptance test in a month, the base subscription cost is $6.25 per completed prototype. If only one reaches it, the same subscription costs $25 per completed prototype. This calculation excludes traffic, database, third-party and labor costs, but it makes the hidden variable visible: completion rate.

For a four-seat Teams workspace, the base is $120 monthly. Eight completed prototypes make the subscription component $15 each. Two completed prototypes make it $60 each. The tool did not become more expensive; the process produced fewer accepted outcomes.

The limitations that decide the purchase

Bolt.new's limitations are not cosmetic. They cluster around the same moment: the prototype becomes important, several people touch it, the database matters and the bill must be predictable. That is also when buying a larger token allowance can disguise an architecture problem as a capacity problem.

1. Token use grows with the project

Bolt says most token use comes from reading and synchronizing project files, which means a larger project consumes more tokens per message. The same instruction can therefore cost more later than it did early in the build.

That makes the meter difficult to forecast from prompt count alone. A small styling change can require broad context. A vague feature request can trigger planning, edits and corrections across many files. Paid rollover softens a quiet month, but it does not make a growing project predictable.

The response is to narrow prompts, keep the project modular and graduate routine file-level work to a code editor when describing the edit costs more than making it. Buying another token tier is rational when the work remains well scoped. It is waste when the agent repeatedly loses the architecture or redoes unchanged code.

2. Project rollback does not restore the database

Bolt's Version History restores project files, not the database. Restoring an earlier application version leaves the current database untouched. This is the most serious limitation for a buyer who reads “full-stack builder” as “full-stack recovery.”

Code and schema evolve together. If a generated change renames a column, modifies an authorization rule or migrates data, rolling back only the application can create a version mismatch. A production process needs database backups, migration tracking and a recovery test that covers both sides.

There is a smaller development inconvenience too. An unpublished low-usage database may pause after six days or more and take a few minutes to restore. Published databases are exempt. That behavior is reasonable resource management, but it can surprise someone returning to a dormant prototype for a live demo.

3. GitHub integration is not a complete Git workflow

Bolt creates branches and switches among them, but it cannot merge branches in-app. The merge happens in GitHub. That is healthy because review belongs in the repository, but it contradicts the expectation that a non-technical user can keep every operation inside Bolt.

The rare sync-conflict behavior is sharper. Bolt checks GitHub every thirty seconds, yet if Bolt and GitHub update nearly simultaneously, Bolt keeps its own changes and overwrites the GitHub version. Teams should not edit the same branch concurrently across environments. Use branches, one source of truth and an explicit merge owner.

4. Mobile starts easily and finishes in a developer toolchain

Bolt uses Expo when the first prompt requests a mobile app, and Expo Go gives a fast phone preview. A project started for the web does not easily switch to mobile. The architecture decision belongs at the beginning.

App-store release then moves outside the simple browser flow. The code must be downloaded and handled with Node.js LTS, Git, Expo tools, developer accounts, certificates and store review. That is still easier than writing separate native apps, but it is not a one-click mobile launch.

5. Hosting can stop or become hard to price

Free sites stop serving when the account-wide hosting allowance is exhausted. Pro allows pay-as-you-go traffic with a spending cap, but the public plan page does not expose a unit rate. A founder can cap risk after signing in but cannot calculate an exact public traffic curve before purchase.

The allowances are also shared across the account. Publishing several client previews or campaign tools means a busy project can reduce the headroom for every other one. Agencies should separate client ownership or monitor account-level use rather than treating each deployment as independently provisioned.

6. Support is tiered around the moment failure matters

Bolt provides Discord community support to Free users. Paid users can email support Monday through Friday during business hours. Enterprise adds 24/7 priority support and a dedicated account relationship.

That division is normal for software, but it matters for the decision rule. A production application that requires a contractual response at night is not covered by the $25 Pro plan or the $30 Teams headline. The support requirement moves the buyer into a custom Enterprise conversation or a separately owned operating stack.

7. Team governance and team economics do not arrive together

Teams adds useful controls, design systems and centralized billing, but the most consequential governance features on the pricing page sit under Enterprise: SSO, audit logs, compliance support, data governance, retention policies and custom SLAs. A company can therefore need Enterprise controls before its number of active builders makes Teams economical.

The per-member token model adds another mismatch. Reviewers cannot donate unused capacity to a heavy builder. A team should map seats to actual builders, decide how reviewers participate, and compare the total with a shared-credit alternative before upgrading.

Verdict: Bolt.new is a strong prototype system with an early handoff date

Bolt.new is worth paying for when one person needs to turn a defined workflow into a hosted, inspectable codebase and the organization accepts an early GitHub handoff. Pro at $25 is the right starting tier for that buyer because the Free daily cap and hard hosting stop are poor foundations for a serious sprint.

The decision changes when the project already has architecture, several active developers, consequential data or a strict operating contract. Cursor is better for direct work in an existing repository. Replit is better when the broader cloud workspace, parallel agents or documented database rollback matters. Lovable is better when design-first collaboration and unlimited users matter more than Bolt's code and infrastructure controls.

The stop rule is equally important. Do not respond to repeated architectural confusion, recovery gaps or cross-environment conflicts by buying more tokens. If the project needs frequent manual code review, coordinated merges, controlled migrations and continuous operations, move the center of work to a conventional repository workflow. Bolt can still generate a prototype or contribute a branch, but it should no longer own the system.

The Monday move

Use one working week to test the fit on a disposable workflow, not on the product database.

1. 1

   Monday: define one accepted outcome

   Write the user, starting state, final state, required data and forbidden access. Choose a workflow small enough that one person can complete it from beginning to end.

2. 2

   Tuesday: build with explicit infrastructure

   Ask for the database, authentication, roles and reset flow by name. Use Free while the data remains disposable, and note which instructions create rework.

3. 3

   Wednesday: connect GitHub

   Create the private repository, make one feature branch and merge it through GitHub. Confirm that the Bolt preview and repository match after the merge.

4. 4

   Thursday: force the failure cases

   Try the wrong role, an expired session, a broken redirect, a schema change and a dormant-database return. Record which recovery steps require work outside the generated interface.

5. 5

   Friday: apply the decision rule

   Upgrade to Pro only if the workflow passed, the handoff owner accepts the code and the token meter appears proportional to the value. Otherwise choose the named alternative that owns the difficult part.

For a wider shortlist, use the current vibe-coding tools guide. If Replit is the likely route but its paid plans do not fit, the Replit alternatives for free AI app building comparison narrows the next decision.

Frequently asked questions

Is Bolt New a legit website?

Yes. Bolt.new is an operating product from StackBlitz with public pricing, product documentation, release notes and support channels. That establishes the vendor and product, not the fitness of generated code for every use. Connect GitHub, review permissions and define database recovery before the application handles valuable data.

Does Bolt New actually work?

Bolt documents working paths for web apps, databases, authentication, hosting, GitHub and Expo mobile projects. It can therefore produce more than a static mockup. This review did not exercise the tool, so it does not claim an independent success rate or promise that a complex application will be production-ready without engineering review.

Is Bolt new better than Cursor?

Bolt is better for turning a scoped brief into a first hosted application with infrastructure in the same browser workflow. Cursor is better for an experienced developer modifying an existing codebase directly. Choose Bolt before the architecture is settled and Cursor when code ownership and precise repository work have become the main job.

Is Bolt New safe?

Bolt provides authentication controls, URI allow lists, leaked-password protection, security settings and Enterprise governance features. Safety still depends on the generated application's authorization rules, secrets, dependencies, data model, backups and operating process. The lack of database restore inside project Version History is a reason to define recovery separately.

Is Bolt New completely free?

Bolt has a $0 Free plan with private and public projects, 1 million monthly tokens, a 300,000-token daily limit, unlimited databases and hosting. It keeps Bolt branding, limits uploads to 10MB and stops Free sites when the shared 10GB bandwidth or 333,333-request monthly allowance is reached.

Is Bolt.new free for 1 year?

The current public pricing page lists a $0 Free tier and does not describe it as a one-year paid-plan promotion. The free allowance is limited by tokens, uploads, branding and hosting. Paid capacity currently starts with Pro at $25 per month billed monthly.

Bolt new pricing

Bolt currently lists Free at $0, Pro at $25 per month, Teams at $30 per member per month and Enterprise at a custom price. The page advertises up to 28% savings on yearly billing. Pro starts at 10 million monthly tokens; paid unused tokens can roll over for one additional month while the subscription stays active.

Bolt new vs Lovable

Choose Bolt for a prompt-to-code workflow with Bolt Database, hosting and an early GitHub handoff. Choose Lovable for design-first output and collaboration: its $25 Pro plan supports unlimited users sharing the workspace's credits. A multi-builder Bolt team pays $30 per member, so headcount can reverse the decision even when the solo prices match.

Get the AI Business Workflow Audit Checklist

The free AI Business Workflow Audit Checklist helps you choose one process, define its data and failure cost, assign an owner, and set a stop rule before buying another builder. Subscribe to get the next verified edition.