Reseña de Bolt.new: Precios, Límites y Alternativas (2026)

Bolt.new cuesta desde $25/mes. Analizamos a quién conviene, sus límites de tokens y bases de datos, y cuándo elegir Lovable, Replit o Cursor.

Thursday, September 3, 2026Omid Saffari
Reseña de Bolt.new: Precios, Límites y Alternativas (2026)

Bolt.new vale sus $25 al mes para un fundador en solitario que necesita transformar una idea acotada de aplicación web en un prototipo desplegado y está dispuesto a revisar el código generado. Evítelo para sistemas de producción maduros, flujos de trabajo no técnicos centrados primero en el diseño o cualquier proyecto cuya base de datos no pueda permitirse recuperar manualmente: la reversión de proyectos de Bolt todavía no restaura la base de datos.

Bolt.new de un vistazo: qué es

Bolt.new es un generador de aplicaciones basado en el navegador que convierte un informe escrito en código de aplicación editable, ejecuta ese código en un entorno de desarrollo en línea y puede añadir base de datos, autenticación y alojamiento sin obligarle a configurar esos servicios de antemano. Se sitúa a medio camino entre un constructor no-code y un editor de código con IA: se puede trabajar mediante conversación, pero el resultado final sigue siendo una base de código que puede trasladarse a GitHub. Esto lo hace especialmente eficaz para prototipos, herramientas internas y productos web muy delimitados, no para delegar cada decisión de ingeniería en un prompt.

Página de inicio de Bolt.new con su generador de aplicaciones a partir de prompts y opciones de importación
Página de inicio de Bolt.new

El producto actual es notablemente distinto de aquel con el que comenzaron muchos proyectos anteriores. Las notas de lanzamiento de Bolt señalan que v1 Agent y Discussion Mode se retiraron el August 3, 2026. Los proyectos restantes pasaron a Bolt Agent conservando sus archivos y el historial del chat, y Plan Mode se convirtió en el espacio para razonar la construcción sin alterar el código de inmediato. El dictado por voz también está activo, transcribiendo la voz en un prompt editable antes de su envío.

Bolt.new frente a sus alternativas de un vistazo: reseña de bolt new

Bolt.new encabeza la lista cuando se busca prompt, código, base de datos y un primer despliegue en un único flujo de navegador. Lovable gana cuando el acabado visual y la colaboración sin fricciones importan más que el control a nivel de código. Replit ofrece un entorno de desarrollo en navegador más amplio. Cursor resulta la opción idónea una vez que un desarrollador experimentado ya dispone de un repositorio y busca un editor de código nativo con IA en lugar de un constructor integral de aplicaciones.

HerramientaPerfil idealPrecio inicial de pagoDiferencia decisiva
Bolt.newPrototipos full-stack acotados y herramientas internasPro a $25/mesBase de datos, alojamiento y código portable en un flujo guiado por prompts
LovableFundadores centrados en el diseño y equipos mixtosPro a $25/mesUsuarios ilimitados que comparten un espacio de trabajo y un fondo común de créditos
ReplitDesarrollo en navegador más amplio y agentes en paraleloCore a $20/mes, o $18/mes con facturación anualDos agentes en paralelo, base de datos integrada y un entorno de desarrollo general
CursorDesarrolladores que amplían una base de código existenteIndividual Pro a $20/mesEdición directa de código con modelos de frontera, MCPs, skills, hooks y agentes en la nube

La tabla oculta un matiz relevante. Bolt.new, Lovable y Replit ayudan a poner en marcha una aplicación desde cero, mientras que Cursor asume que usted se desenvuelve con soltura en el código. Compararlos únicamente por la cuota de suscripción pasa por alto el coste de la transición técnica. Un fundador no técnico puede pagar los mismos $25 por Lovable Pro y ahorrarse horas inspeccionando código. Un desarrollador puede optar por los $20 de Cursor y evitar pagar a un generador de prompts para que relea un proyecto en constante crecimiento con cada mensaje.

Esa es la regla rectora de esta reseña: elija el entorno que mantenga visible la parte más compleja de su proyecto. Bolt mantiene la infraestructura lo bastante visible como para graduarse hacia GitHub. Lovable mantiene visibles el diseño y la colaboración. Replit mantiene visible un espacio de desarrollo más amplio. Cursor mantiene visible el código en sí.

Para quién es Bolt.new y quién debería descartarlo

Bolt.new está pensado para constructores que valoran obtener con rapidez una primera versión funcional sin confundirla con un sistema terminado. El usuario ideal tiene un flujo de trabajo bien delimitado, sabe describir los datos y los permisos, y revisará el código resultante o involucrará a alguien capacitado para hacerlo. El peor perfil llega con una idea de producto desmesurada, sin criterios de aceptación, con datos confidenciales y con la creencia de que añadir más prompts solucionará cualquier problema de arquitectura.

Buen encaje: un fundador en solitario que valida un flujo concreto

Bolt.new tiene sentido para un fundador individual que necesita validar un flujo acotado antes de contratar a un equipo de desarrollo. Pensemos en un producto de reservas para profesores particulares independientes. Una primera versión útil requiere perfiles de tutor, franjas horarias disponibles, formulario de reserva, correo de confirmación y una vista administrativa básica. Esas piezas encajan con naturalidad en una base de datos, autenticación y una interfaz desplegada.

El fundador puede detallar los roles de usuario, pedirle a Bolt que cree las tablas y el flujo de inicio de sesión, publicar una vista previa pública o privada y subir el código a GitHub antes de recibir a los primeros usuarios. El producto requerirá pruebas, decisiones sobre privacidad y mantenimiento continuo, pero Bolt acorta la distancia entre un flujo redactado y una interfaz donde el usuario puede hacer clic.

Este ajuste fracasa cuando el fundador no distingue si una comprobación de permisos corresponde a la interfaz o a la base de datos. Un botón que desaparece ante el usuario incorrecto no equivale a una política de seguridad por filas (RLS). Bolt puede generar ambas cosas, pero alguien debe verificar las dos.

Buen encaje: un gestor de producto que valida un flujo antes del compromiso técnico

Bolt.new también encaja con un product manager que necesita un prototipo convincente y respaldado por datos reales en lugar de otra maqueta estática. Una herramienta de aprobación de devoluciones, por ejemplo, puede incorporar una cola de gestión, registros de clientes, códigos de motivo y acciones específicas según el rol. Los interesados pueden probar el flujo e identificar estados ausentes antes de iniciar un sprint de desarrollo.

El gestor de producto debe concebir la aplicación generada como un ejercicio de descubrimiento ejecutable. El beneficio no reside en que el prototipo pase a producción sin cambios, sino en comprobar si el flujo funciona cuando modificarlo resulta barato. Conectar GitHub entrega un recurso valioso para que un ingeniero lo examine, pero no convierte el prototipo en una arquitectura aprobada.

Buen encaje: una agencia pequeña con una política clara de traspaso

Bolt.new puede respaldar a una agencia pequeña en la creación de herramientas de campaña, calculadoras, portales y prototipos, siempre que cada proyecto siga la misma disciplina de salida. La agencia debe determinar desde la contratación si el entregable permanecerá en el alojamiento de Bolt, se trasladará al repositorio del cliente o evolucionará hacia un desarrollo a medida. Esa decisión fija quién asume dominios, claves secretas, recuperación de base de datos y modificaciones futuras.

Las funciones de Teams facilitan el acceso centralizado, el uso compartido en la organización y el contexto de sistemas de diseño, pero el contador por usuario es determinante. Cada miembro de pago recibe una asignación individual de tokens que no se comparte. Una agencia con un constructor intensivo y varios revisores puede terminar pagando por capacidad ociosa mientras el constructor principal agota su saldo.

Descarte Bolt.new para un equipo no técnico centrado en el diseño: elija Lovable

Lovable representa la alternativa adecuada cuando el equipo prioriza interfaces muy pulidas, capacidad de construcción compartida y menos decisiones orientadas al código. Lovable Pro cuesta $25 al mes con 100 créditos mensuales, usuarios ilimitados, acumulación de créditos sobrantes, recargas, dominios personalizados, roles, límites de crédito por miembro, soporte por correo y sistemas de diseño.

Página de precios de Lovable con los planes Free, Pro, Business y Enterprise
Precios de Lovable

Ese modelo de usuarios ilimitados contrasta frontalmente con Bolt Teams a $30 por usuario cada mes. Los créditos compartidos de Lovable no son automáticamente más cuantiosos, ni su consumo equivale de forma directa a los tokens de Bolt. La ventaja es estructural: fundador, diseñador y responsable de marketing colaboran en un único espacio Pro sin multiplicar la suscripción base por el número de integrantes.

Opte por Lovable cuando la primera duda sea: «¿Puede todo el equipo moldear esta interfaz?». Elija Bolt cuando la prioridad sea: «¿Podemos obtener una base de código funcional, infraestructura y traspaso a GitHub desde el mismo navegador?». Si nadie en el equipo va a inspeccionar el código, el control añadido que aporta Bolt es una capacidad que difícilmente aprovecharán.

Descarte Bolt.new si busca un espacio de trabajo en la nube más amplio: elija Replit

Replit es la opción indicada cuando se requiere un entorno de desarrollo general en el navegador, concurrencia de agentes y una trayectoria fluida desde pequeños experimentos hasta un espacio técnico gestionado. Replit Core cuesta $20 mensuales o $18 al mes con facturación anual, e incluye dos agentes en paralelo, espacios ilimitados y $20 para usar en sus modelos más avanzados.

Página de precios de Replit mostrando los planes Starter, Core, Pro y Enterprise
Precios de Replit

La diferencia más ilustrativa se observa en la gama superior de Replit. Replit Pro cuesta $100 al mes o $90 mensuales en facturación anual, e incluye diez agentes en paralelo, hasta quince colaboradores, hasta cincuenta visualizadores y reversión de base de datos de hasta veintiocho días. La función integrada Version History de Bolt no restaura la base de datos en absoluto.

Esto no convierte a Replit en una solución superior por defecto. Significa que quien valore el trabajo simultáneo de agentes o una reversión documentada de la base de datos debe anteponer esos requisitos al punto de partida más económico de $25 de Bolt. Elija Bolt para una ruta directa desde el prompt hasta la app. Elija Replit cuando el producto que busca sea el propio espacio de desarrollo.

Descarte Bolt.new para un repositorio preexistente: elija Cursor

Cursor es la alternativa lógica para un desarrollador con experiencia cuya aplicación ya está en marcha. Cursor Individual Pro cuesta $20 al mes y amplía los límites de su Agent añadiendo modelos de frontera, MCPs, skills, hooks y agentes en la nube.

Página de precios de Cursor con los planes Hobby, Individual, Teams y Enterprise
Precios de Cursor

Cursor no evita tener que resolver el alojamiento, la autenticación o la base de datos, y precisamente por eso resulta superior una vez que esas decisiones ya se han tomado. El desarrollador edita el repositorio directamente, sin obligar a un generador de aplicaciones a sincronizar y reinterpretar todo el proyecto en cada iteración.

Dé el salto a Cursor cuando el trabajo pase de «definir la forma del producto» a «modificar esta base de código concreta bajo normas consolidadas de arquitectura y revisión». La comparativa amplia entre Codex, Claude Code y Cursor es la lectura recomendada una vez que la propiedad directa del código pasa al centro de la operativa.

Capacidad 1: prototipos web full-stack con base de datos y alojamiento

La cualidad más diferencial de Bolt.new no es generar una pantalla, sino mantener la interfaz, la base de datos, la autenticación y el primer despliegue lo bastante integrados para que una sola persona modele un flujo completo. Por eso resulta más práctico para un portal de recepción o un sistema de reservas que para una simple maqueta promocional con pantallas vistosas.

Documentación de Bolt Database con ajustes de autenticación, almacenamiento, registros y seguridad
Bolt Database

Pensemos en una empresa de servicios para el hogar que sustituye un proceso basado en correos y hojas de cálculo. El producto necesita un formulario de clientes, un registro de solicitudes, una cola para despachadores, asignación de técnicos e historial de estados. Un flujo provechoso en Bolt arranca nombrando esas entidades y permisos, no solicitando «una aplicación de servicios moderna».

  1. Definir el flujo de trabajo y los roles

    Describa los roles de cliente, despachador y técnico. Concrete los estados por los que pasa una solicitud, qué información visualiza cada rol y qué acciones la hacen avanzar. Así dotará a Bolt de un modelo de comportamiento en lugar de una simple pauta estética.

  2. Solicitar el modelo de datos de forma explícita

    Pida tablas para clientes, solicitudes de servicio, asignaciones y eventos de estado. Bolt puede aprovisionar una base de datos de manera automática cuando el proyecto la necesita, pero especificar el modelo facilita inspeccionar el resultado y reduce el riesgo de que información crítica resida solo en la interfaz.

  3. Especificar la autenticación y la autorización

    Solicite registro por correo, inicio de sesión, restablecimiento de contraseña y control de acceso basado en roles. La documentación de Bolt indica que la autenticación puede no incorporarse automáticamente, incluso cuando se añade una base de datos. Verifique las URLs de redirección y las reglas de permisos antes de compartir un enlace público.

  4. Publicar una vista previa desechable

    Tanto los usuarios de Free como de Pro pueden publicar bajo una dirección .bolt.host. Mantenga los datos iniciales como desechables. Invite a un despachador a recorrer el circuito de alta, asignación y cierre mientras registra cualquier estado ausente.

  5. Migrar el código antes de que los datos tengan valor

    Conecte GitHub en cuanto cuente con el primer flujo estable. No espere a acumular registros de clientes reales para definir cómo desacoplar el proyecto, la base de datos y el despliegue.

Bolt Database simplifica la puesta en marcha inicial. Puede aprovisionar una base de datos si la aplicación la requiere, incluye controles de autenticación, expone registros y variables secretas, y permite seleccionar Supabase durante la configuración. La protección contra contraseñas filtradas viene activada por defecto cuando Bolt crea la base de datos. Si esta se vincula o reclama mediante Supabase, dicha protección dependerá del plan de Supabase y estará desactivada en Supabase Free.

Conviene distinguir con claridad entre funcionalidad generada y comportamiento verificado. Una pantalla de acceso puede parecer completa mientras las redirecciones de restablecimiento de contraseña apuntan a destinos erróneos. La cola del despachador puede ocultar en la interfaz el registro de otro cliente mientras la política de la base de datos sigue permitiendo el acceso directo. Los ajustes de autenticación de Bolt muestran URLs del sitio, listas blancas de URIs, proveedores y plantillas, pero alguien debe examinarlos.

El alojamiento ofrece una agilidad similar pero cuenta con límites claros. El alojamiento Free brinda un subdominio .bolt.host, 10GB de ancho de banda y 333,333 peticiones al mes a nivel de cuenta. El plan Pro amplía esto a 30GB y 1 millón de peticiones mensuales, admite dominios personalizados mediante la suscripción de pago y permite tráfico facturado por uso. Estos márgenes cubren la validación inicial de muchas aplicaciones pequeñas, pero al aplicarse a toda la cuenta, varios proyectos consumen la misma cuota global.

El obstáculo crítico surge en la recuperación. La función Version History de Bolt no restaura la base de datos. Revertir los archivos de la aplicación al estado de ayer mantiene intacta la base de datos de hoy. Esta discrepancia puede ser más perjudicial que carecer de botón de reversión, ya que induce a asumir erróneamente que código y datos viajan a la par.

En el ejemplo de servicios del hogar, imagine restaurar el código previo al cambio de nombre de un campo de estado mientras la base de datos conserva el esquema nuevo: la interfaz y los datos entrarán en conflicto. Antes de que un proyecto asuma responsabilidades críticas, defina copias de seguridad de la base de datos, control de migraciones y un procedimiento de recuperación probado al margen del historial de Bolt.

Capacidad 2: propiedad del código mediante GitHub

Bolt.new aventaja a los constructores no-code cerrados porque el proyecto puede residir en GitHub y trasladarse a otro proveedor de alojamiento o flujo de desarrollo. Sin embargo, la portabilidad solo es útil si se practica desde el inicio. Decir que «el código se puede exportar» no constituye un plan de recuperación si el repositorio nunca se vinculó y nadie sabe qué commit corresponde a la base de datos en producción.

Documentación de integración de GitHub en Bolt cubriendo repositorios, ramas y sincronización
Integración de GitHub en Bolt

La documentación de GitHub de Bolt explica que un repositorio generado desde Bolt se crea inicialmente privado en la rama main. Bolt guarda automáticamente los cambios que no rompen el proyecto, consulta GitHub cada treinta segundos en busca de actualizaciones externas y permite crear ramas o alternar entre ellas.

Un flujo de traspaso sensato se estructura así:

  1. Conectar tras el primer estado estable

    Genere el repositorio mientras el proyecto sea aún desechable. Asegúrese de que aparezcan los archivos esperados, los ejemplos de entorno y los manifiestos de dependencias. Las credenciales secretas deben quedar fuera del repositorio.

  2. Crear una rama para cada cambio sustancial

    Utilice una rama distinta para añadir una pasarela de pago, modificar permisos o renovar el diseño. Bolt aísla el contexto de las ramas, lo que previene mezclas involuntarias entre el trabajo en curso y la línea principal.

  3. Revisar y fusionar en GitHub

    Bolt permite crear y cambiar de rama, pero no fusionarlas desde su interfaz. Abra el pull request y realice la fusión directamente en GitHub, donde un desarrollador pueda inspeccionar el cambio y donde la decisión quede registrada en el historial.

  4. Sincronizar antes de introducir nuevos prompts

    Espere a que el estado fusionado se refleje en Bolt, abra la rama correspondiente y confirme la vista previa. Bolt consulta GitHub cada treinta segundos, pero un intervalo automático no sustituye la verificación manual del estado que se va a editar.

Este enfoque convierte a Bolt en un punto de partida y no en un entorno cerrado. Un desarrollador puede desvincularse de Bolt, trabajar en el repositorio, desplegar en otra infraestructura y regresar más adelante. Esto cobra especial valor cuando el prototipo evoluciona y exige pruebas automatizadas, observabilidad, revisión de infraestructura o un backend diferente.

Conviene asumir dos limitaciones antes de considerar esto «Git convencional». En primer lugar, la fusión (merge) se realiza fuera de Bolt, lo que exige que un equipo no técnico entienda el uso de pull requests o cuente con alguien que los gestione. En segundo lugar, el proveedor documenta un caso infrecuente de concurrencia: si Bolt y GitHub reciben cambios casi simultáneos, Bolt preserva su versión y sobreescribe la de GitHub.

La respuesta operativa no es el temor, sino la disciplina. Evite editar la misma rama en Bolt y en otro entorno al mismo tiempo. Trabaje con ramas, gestione las fusiones en GitHub y haga del repositorio el registro oficial de cambios. Si el proyecto llega a un punto donde varios desarrolladores intervienen continuamente, Bolt debe considerarse un colaborador puntual y no la fuente canónica de verdad.

Capacidad 3: aplicaciones móviles mediante Expo

Bolt.new puede iniciar aplicaciones móviles multiplataforma apoyándose en Expo, pero el prompt inicial condiciona por completo el proceso. La guía de Expo de Bolt advierte que un proyecto comenzado como web no se convierte con facilidad a móvil. Por tanto, «adaptar esto a móvil» representa un cambio de arquitectura y no una simple instrucción de acabado.

Documentación de la integración de Expo en Bolt para apps móviles y publicación en tiendas
Bolt con Expo

Tomemos como ejemplo una aplicación de planificación de comidas. El prompt inicial debe especificar que se trata de una app móvil para iOS y Android, describir los datos de recetas y miembros del hogar, y detallar las interacciones táctiles clave. Bolt empleará entonces Expo, un framework que permite apuntar con una sola base de código tanto a plataformas móviles como a la web.

El ciclo de previsualización es ágil: abra el proyecto móvil, seleccione Device Preview, escanee el código QR desde la app Expo Go e interactúe con el desarrollo en su propio teléfono. Esto permite detectar problemas de teclado, diseño de interfaz, navegación y gestos táctiles que un navegador de escritorio pasa por alto.

El ciclo de publicación, en cambio, no se resuelve dentro de Bolt. Publicar en las tiendas oficiales requiere descargar el código, abrirlo en un editor, contar con un equipo con Node.js LTS y Git, configurar Expo Application Services y mantener cuentas activas de desarrollador en Apple o Google. La compilación puede fallar además por certificados, dependencias de plataforma o normativas de cada tienda.

Esta separación define con claridad quién debe liderar el proyecto. Un fundador puede utilizar Bolt para validar un flujo móvil sin necesidad de aprender Swift o Kotlin, pero seguirá necesitando a alguien responsable del lanzamiento que gestione firmas de código, fichas de tienda, políticas de privacidad, registros de errores y revisiones de plataforma. Expo evita duplicar código entre sistemas; no elimina la operativa de publicación.

Siga estos pasos:

  1. Declarar el entorno móvil en el primer prompt

    Especifique iOS y Android, las interacciones táctiles básicas, el comportamiento offline y cualquier necesidad de cámara, notificaciones o ubicación antes de generar el código.

  2. Validar en un teléfono real

    Utilice Expo Go desde el principio. Pruebe el recorrido básico completo: elegir platos, añadir ingredientes y verificar que el plan guardado persista tras cerrar y reabrir la app.

  3. Exportar antes de trabajar con las tiendas

    Lleve el código a GitHub y a un entorno local antes de configurar credenciales de publicación. El repositorio debe ser la base auditada que entre al proceso de compilación oficial.

  4. Asignar la gestión del lanzamiento

    Determine quién administrará certificados, pruebas en TestFlight o Google Play, notas de versión, privacidad y control de caídas. Si nadie asume estas tareas, el proyecto seguirá siendo un prototipo y no un lanzamiento móvil real.

Recurra a Bolt para móvil cuando el riesgo principal a validar sea el flujo de producto. Evítelo como entorno único si la complejidad del proyecto radica en funciones nativas profundas, servicios en segundo plano o un canal riguroso de publicación en tiendas.

Capacidad 4: compilación en equipo guiada por sistemas de diseño

La integración de sistemas de diseño en Bolt.new está pensada para equipos que ya cuentan con componentes, reglas de espaciado y directrices de marca documentadas. No convierte por arte de magia una guía de estilo dispersa en componentes reutilizables de producción. La calidad del origen determina si Bolt asimila una biblioteca real de componentes o solo replica colores y tipografías.

Documentación de Bolt para añadir un sistema de diseño de equipo desde código y documentación
Sistemas de diseño en Bolt

El uso de sistemas de diseño propios exige un plan de pago Teams. Un equipo puede conectar Bolt a un repositorio de GitHub, un paquete de NPM, un Storybook, un sitio web de documentación o archivos locales. Bolt procesa estas fuentes y genera un Storybook interno para que los constructores exploren los componentes que el sistema ha interpretado.

El caso de uso más sólido corresponde a una empresa de software B2B que distribuye sus botones, formularios, navegación y tablas como un paquete NPM. El equipo vincula el paquete, enlaza su Storybook e introduce directrices para el agente, como omitir componentes en desuso o apegarse a un tema concreto. Así, un gestor de producto puede prototipar apoyándose directamente en el sistema de diseño oficial.

La propia documentación de Bolt es transparente sobre la calidad de las fuentes. Los repositorios de GitHub y paquetes NPM arrojan mejores resultados que un sitio de documentación aislado. Una web con capturas y notas de uso ilustra la estética, pero un paquete de componentes proporciona a Bolt el código ejecutable que puede reutilizar.

Existen restricciones operativas. Un equipo en plan de pago puede añadir o sincronizar hasta diez sistemas de diseño por semana en total. La carga manual admite un máximo de diez archivos entre PDFs, imágenes u otros formatos. Mezclar frameworks incompatibles, componentes antiguos y pautas contradictorias degrada el resultado, por lo que acumular fuentes sin depurar resulta contraproducente.

  1. Definir la fuente canónica de componentes

    Comience con el repositorio o paquete NPM que el equipo de desarrollo considere normativo. No combine librerías obsoletas y vigentes en el mismo lote de origen.

  2. Aportar documentación funcional y no solo visual

    Incluya pautas sobre cuándo emplear cada componente, criterios de accesibilidad y restricciones temáticas. Las capturas de pantalla no le explican al agente el comportamiento esperado.

  3. Fijar instrucciones estrictas para el agente

    Indique con exactitud el framework, tema y versión del paquete a utilizar, señalando qué componentes ignorar. Una exclusión clara suele ser más efectiva que otra carpeta repleta de ejemplos.

  4. Construir un flujo representativo

    Genere un formulario con estados de validación, vistas vacías y presentación de resultados. Compare los componentes generados frente al sistema oficial antes de estandarizar la configuración en más proyectos.

Esta función compensa el coste de Bolt Teams cuando los prototipos alineados con la marca evitan rehacer el trabajo y la empresa ya mantiene código de diseño estructurado. En cambio, no justifica pagar $30 por usuario para quien solo cuenta con un logotipo, una selección tipográfica y ningún componente real. Lovable Pro incluye sistemas de diseño a $25 con usuarios ilimitados; la prima de Bolt se amortiza cuando el control de código y su entorno global de desarrollo resultan imprescindibles.

Precios de Bolt.new: planes y coste por resultado

La escala pública de precios mensuales de Bolt.new es directa: $0 Free, $25 Pro, $30 por miembro en Teams y un plan Enterprise a medida. Lo complejo reside en calcular cómo los tokens, los límites compartidos de alojamiento y el número de usuarios transforman la cuota base en el coste final por prototipo completado.

Página de precios de Bolt.new mostrando los planes Free, Pro, Teams y Enterprise
Precios de Bolt.new

Los precios y límites señalados a continuación se verificaron en la página oficial de precios de Bolt el August 27, 2026. La plataforma anuncia descuentos de hasta el 28% con facturación anual. Dado que «hasta» no define una tarifa plana general, la comparativa mensual constituye la referencia más clara, manteniéndose la pasarela de pago como el valor definitivo para cotizaciones anuales.

PlanPrecio mensual actualAsignación pública principalPerfil ideal
Free$01M de tokens al mes, 300K al día, subidas de 10MB, 10GB de ancho de banda, 333,333 peticiones, marca de BoltFamiliarizarse con el flujo y previsualizaciones desechables
Pro$25Desde 10M de tokens, sin límite diario de tokens, subidas de 100MB, 30GB de ancho de banda, 1M de peticiones, dominio propio, rolloverConstructores individuales con prototipos formales
Teams$30 por miembroTodo lo de Pro más facturación centralizada, controles de administración, acceso para organizaciones, registros NPM privados y sistemas de diseñoEquipos que requieren gestión centralizada y estándares de diseño compartidos
EnterpriseA medidaSeguridad avanzada, SSO, registros de auditoría, soporte de conformidad, SLAs personalizados, gobernanza, onboarding y soporte prioritario 24/7Empresas con requisitos formales de seguridad, soporte y contratación

Free es una prueba funcional con límites reales de alojamiento

El plan Free incluye proyectos públicos y privados, bases de datos ilimitadas, despliegues bajo .bolt.host, 1 millón de tokens mensuales y un tope diario de 300,000 tokens. Permite evaluar cómo planifica, programa y publica la herramienta. No obstante, no es una opción viable para concluir aplicaciones complejas, ya que el límite diario puede detener el avance antes de agotar la cuota mensual.

El alojamiento presenta una restricción tajante: incluye 10GB de ancho de banda y 333,333 peticiones mensuales agregadas a nivel de cuenta. Si la cuenta alcanza ese límite, los sitios dejan de responder hasta la siguiente renovación mensual. Esto es admisible en una prueba desechable, pero inasumible para un flujo comercial que debe permanecer accesible.

Pro es la elección habitual para constructores independientes

Pro cuesta $25 al mes y parte de 10 millones de tokens sin restricciones diarias. Elimina la marca de Bolt, amplía las cargas de archivos a 100MB, suma proyectos compartidos de forma privada, dominios personalizados, SEO Boost, selección del proveedor de base de datos y edición de imágenes por IA. El alojamiento Pro abarca 30GB de ancho de banda y 1 millón de peticiones mensuales por cuenta.

Los tokens no consumidos en planes de pago se acumulan durante un mes adicional y pueden utilizarse hasta un máximo de dos meses mientras la suscripción continúe activa. Esto desmiente la idea obsoleta de que los tokens de Bolt caducaban de inmediato. Los tokens del plan Free, en cambio, no son acumulables.

Los usuarios Pro pueden mantener un sitio en línea por encima de la cuota incluida mediante tráfico de pago por uso sujeto a un límite de gasto mensual. La web pública no detalla la tarifa unitaria de ese exceso; se puede acotar el gasto total, pero no calcular previamente el coste exacto de un pico de tráfico solo con los datos públicos.

Las recargas de tokens tienen requisitos concretos. Bolt indica que están disponibles únicamente en el plan Pro mensual de mayor importe o en cualquier modalidad anual de Pro. El coste de recarga varía según el plan y se consulta internamente en la cuenta, por lo que el precio inicial de $25 no cubre por sí solo un uso intensivo continuado.

Teams factura por usuario y no mediante un fondo común

Teams tiene un coste de $30 mensuales por miembro. Cada integrante recibe su propio saldo individual de tokens, el cual queda vinculado a su cuenta y no se comparte con el resto del equipo. Centralizar la facturación no equivale a centralizar los recursos.

Esta estructura funciona si todos los miembros desarrollan con frecuencia, pero resulta costosa si uno programa y los demás solo revisan. Un equipo de cuatro personas abona $120 al mes y $1,440 al año antes de contemplar consumos adicionales de tráfico, paquetes superiores de tokens o servicios externos.

Lovable Pro admite usuarios ilimitados por $25 al mes ($300 al año), frente a los $1,440 anuales de base para cuatro personas en Bolt. La diferencia es de $95 al mes y $1,140 al año. Las condiciones de uso difieren: en Lovable los usuarios comparten 100 créditos mensuales, mientras que en Bolt cada miembro dispone de su propio cupo de tokens y accede a un entorno de infraestructura integrado. Aun así, la comparación esclarece la decisión de compra: asuma el sobrecoste por usuario únicamente si varios integrantes van a construir activamente en Bolt o si sus controles de equipo y sistemas de diseño compensan un coste técnico real.

Enterprise: el nivel donde la gobernanza se formaliza

Enterprise opera con presupuesto a medida. Añade seguridad avanzada, SSO, registros de auditoría, soporte para marcos de conformidad, flujos y acuerdos de nivel de servicio (SLA) personalizados, gobernanza y retención de datos, acompañamiento técnico inicial y soporte prioritario 24/7.

Las compañías que requieran estas garantías no deben planificar su presupuesto tomando como base los $30 de Teams asumiendo que compras añadirá el resto después. Conviene solicitar el presupuesto de Enterprise antes de plantear pruebas en torno a exigencias que solo este nivel satisface.

El cálculo del coste por resultado

El coste de suscripción por prototipo validado es simple: divida la cuota base entre el número de prototipos que superan una prueba formal de aceptación. El volumen de prompts mide la actividad, no el resultado de negocio.

Para un constructor en Pro, la suscripción base es de $300 anuales. Si completa cuatro prototipos validados en un mes, el coste de suscripción es de $6.25 por prototipo terminado. Si solo culmina uno, asciende a $25. Este cálculo deja al margen tráfico, base de datos, servicios externos y horas de trabajo, pero revela la variable determinante: la tasa de finalización.

Para un equipo de cuatro miembros en Teams ($120 al mes), ocho prototipos aceptados suponen $15 por unidad en suscripción; dos prototipos la elevan a $60 por unidad. La herramienta no se encarece: el proceso produce menos entregables válidos.

Las limitaciones que determinan la compra

Las limitaciones de Bolt.new no son meros detalles estéticos. Aparecen en un momento crítico: cuando el prototipo gana relevancia, intervienen más personas, la base de datos es indispensable y la factura debe mantenerse predecible. Es ahí donde comprar más tokens puede maquillar un problema de arquitectura como si fuera una simple falta de saldo.

1. El consumo de tokens aumenta con el tamaño del proyecto

Bolt señala que la mayor parte del consumo de tokens proviene de leer y sincronizar los archivos del proyecto, lo que implica que una base de código más amplia consume más saldo por cada mensaje. La misma instrucción costará más tokens en fases avanzadas que al inicio del desarrollo.

Por esta razón, estimar el gasto calculando únicamente el número de prompts resulta poco fiable. Un ajuste visual menor puede requerir cargar un contexto extenso. Una petición funcional ambigua puede desencadenar fases de planificación, modificaciones y correcciones en múltiples archivos. La acumulación mensual en planes de pago ayuda en periodos tranquilos, pero no vuelve predecible el gasto en proyectos que crecen.

La estrategia adecuada consiste en redactar prompts específicos, mantener el proyecto desacoplado y trasladar la edición ordinaria a un editor local cuando explicar el cambio por chat consuma más recursos que aplicarlo directamente. Ampliar el plan de tokens tiene sentido si las tareas están acotadas; resulta ineficiente si el agente pierde el hilo de la arquitectura o sobreescribe código intacto sin necesidad.

2. La reversión del proyecto no restaura la base de datos

La función Version History de Bolt restaura los archivos del proyecto, pero no la base de datos. Volver a una versión anterior de la aplicación mantiene la base de datos en su estado actual. Esta es la limitación más determinante para quien interprete «constructor full-stack» como «recuperación full-stack».

El código y el esquema evolucionan en paralelo. Si un cambio modifica el nombre de una columna, ajusta una regla de autorización o migra registros, revertir únicamente el código puede provocar inconsistencias críticas. Cualquier proceso de producción requiere copias de seguridad de la base de datos, registro de migraciones y pruebas de recuperación que abarquen ambas partes.

Existe además una particularidad operativa durante el desarrollo: una base de datos con poco uso que no esté publicada puede suspenderse tras seis días o más de inactividad, tardando algunos minutos en reactivarse. Las bases de datos en proyectos publicados no se suspenden. Es una gestión lógica de recursos, pero puede generar sorpresas si se retoma un prototipo inactivo justo antes de una demostración en vivo.

3. La integración con GitHub no sustituye un flujo Git integral

Bolt permite ramificar y cambiar entre ramas, pero no realizar la fusión (merge) dentro de la herramienta. La integración de ramas debe resolverse directamente en GitHub. Esto es metodológicamente correcto porque la revisión pertenece al repositorio, pero choca con la expectativa de que un usuario no técnico pueda gestionarlo todo desde la interfaz de Bolt.

El comportamiento ante conflictos simultáneos es más delicado: Bolt consulta GitHub cada treinta segundos, pero si se realizan cambios casi al mismo tiempo en ambos extremos, Bolt conserva los suyos y sobreescribe la versión de GitHub. Los equipos deben evitar modificar la misma rama simultáneamente desde entornos distintos. Trabaje con ramas secundarias, mantenga una sola fuente canónica y asigne un responsable claro para las fusiones.

4. El desarrollo móvil arranca con facilidad y culmina en herramientas locales

Bolt utiliza Expo cuando el prompt inicial solicita una app móvil, y Expo Go permite previsualizarla rápidamente en un teléfono real. Sin embargo, un proyecto concebido como web no se migra a móvil con un simple comando: esa decisión arquitectónica debe tomarse desde el primer momento.

A partir de ahí, la publicación en tiendas se traslada fuera del navegador. El código debe descargarse y gestionarse con Node.js LTS, Git, herramientas de Expo, cuentas de desarrollador, certificados y el proceso de revisión de cada plataforma. Sigue siendo más ágil que programar aplicaciones nativas por separado, pero dista de ser un lanzamiento móvil en un solo clic.

5. El alojamiento puede interrumpirse o resultar difícil de presupuestar

Las webs en el plan Free dejan de estar disponibles si se agota la cuota global de alojamiento de la cuenta. En Pro es posible habilitar tráfico adicional de pago por uso con un tope de gasto, pero la documentación pública no muestra el precio por unidad. Un fundador puede topar el riesgo tras registrarse, pero no modelar con exactitud el impacto económico de un pico de tráfico antes de contratar el servicio.

Asimismo, los recursos de alojamiento se comparten entre todos los desarrollos de la cuenta. Publicar varias demos para clientes o utilidades de marketing implica que un proyecto con mucho tráfico restará margen a los demás. Las agencias deben gestionar los proyectos en cuentas separadas o vigilar el consumo global en lugar de considerar cada despliegue como un entorno aislado.

6. El soporte técnico se segmenta en el momento crítico

Bolt ofrece soporte mediante la comunidad de Discord para usuarios Free. Los usuarios de pago disponen de asistencia por correo electrónico de lunes a viernes en horario comercial. El soporte prioritario 24/7 y la atención técnica dedicada quedan reservados para el plan Enterprise.

Esta estructura es habitual en el sector, pero influye en la regla de decisión: una aplicación en producción que requiera compromisos de respuesta contractuales en fines de semana no está cubierta por los $25 de Pro ni por los $30 de Teams. Esa exigencia obliga a presupuestar el plan Enterprise o a gestionar la infraestructura de forma independiente.

Centro de ayuda de Bolt con documentación y opciones de asistencia técnica
Centro de ayuda de Bolt

7. La gobernanza de equipo no coincide con la economía de equipo

El plan Teams incorpora controles útiles, sistemas de diseño y facturación agrupada, pero las funciones críticas de cumplimiento y seguridad se reservan para Enterprise: SSO, registros de auditoría, soporte de conformidad, retención de datos y SLAs personalizados. Una organización puede requerir estas garantías mucho antes de que su volumen de constructores activos haga rentable el coste por usuario de Teams.

El reparto individual de tokens acentúa esta diferencia. Quienes solo revisan no pueden transferir su saldo a un constructor intensivo. Un equipo debe evaluar qué perfiles construirán realmente, cómo participarán los revisores y contrastar el coste total frente a modelos de créditos compartidos antes de subir de plan.

Lo bueno
Lo que hace bien
11 points

  • Pro ($25) aúna generación por prompts, base de datos, autenticación, alojamiento y exportación a GitHub.
  • El código puede extraerse de Bolt, asegurando una transición viable hacia un desarrollador u otro proveedor.
  • Bolt Database y el despliegue bajo .bolt.host permiten validar un flujo funcional completo sin dar de alta múltiples servicios externos.
  • Expo ofrece una vía pragmática para prototipos móviles multiplataforma, y los sistemas de diseño en Teams aceptan código real y no solo referencias visuales.
  • Los tokens de pago no consumidos se acumulan durante un mes adicional, corrigiendo una limitación del pasado.
  • El consumo de tokens aumenta al crecer el contexto del proyecto, restando previsibilidad al presupuesto en fases avanzadas.
  • La función Version History no restaura las bases de datos.
  • La fusión de ramas de GitHub se realiza fuera de la herramienta, y un conflicto de sincronización simultánea puede sobreescribir la versión de GitHub.
  • Publicar en tiendas móviles exige un entorno de desarrollo local y cuentas externas de desarrollador.
  • Las tarifas públicas de alojamiento por uso no se detallan en la página de precios.
  • El soporte en Free es solo por comunidad; en planes de pago es por correo en días laborables y el 24/7 prioritario exige Enterprise.

Veredicto: Bolt.new es un potente generador de prototipos pensado para un traspaso temprano

Bolt.new merece la inversión cuando una persona necesita transformar un flujo de trabajo concreto en una base de código desplegada y auditable, asumiendo un traspaso temprano a GitHub. Pro a $25 es el plan de entrada adecuado para ese perfil, ya que el tope diario de tokens y el corte total de alojamiento en Free limitan cualquier desarrollo riguroso.

La perspectiva varía si el proyecto ya cuenta con arquitectura previa, varios programadores en activo, datos sensibles o requisitos estrictos de servicio. Cursor es superior para intervenir directamente sobre repositorios consolidados. Replit encaja mejor cuando se busca un entorno de desarrollo integral en la nube, agentes simultáneos o reversión documentada de base de datos. Lovable resulta preferible si la prioridad es el diseño colaborativo y el acceso de usuarios ilimitados por encima del control de infraestructura de Bolt.

La regla de parada es igualmente tajante: no intente resolver fallos recurrentes de arquitectura, carencias de restauración o conflictos de sincronización comprando paquetes adicionales de tokens. Si la aplicación exige revisiones constantes de código, fusiones coordinadas, migraciones estrictas y operaciones continuadas, traslade el núcleo del trabajo a un flujo clásico sobre el repositorio. Bolt podrá seguir generando prototipos o aportando cambios en ramas secundarias, pero no debe retener la gobernanza del sistema.

El plan de trabajo para la semana

Dedique cinco días laborales a validar el encaje sobre un flujo desechable, nunca sobre su base de datos definitiva.

  1. Lunes: definir un único resultado aceptado

    Documente el usuario, el estado inicial, el estado final, los datos requeridos y los accesos restringidos. Seleccione un flujo lo bastante acotado para que una sola persona lo recorra de principio a fin.

  2. Martes: construir con infraestructura explícita

    Solicite la base de datos, autenticación, roles y recuperación de contraseña de forma directa. Utilice el plan Free mientras la información sea prescindible y anote qué instrucciones obligan a corregir código.

  3. Miércoles: conectar GitHub

    Cree un repositorio privado, abra una rama de funcionalidad y aplique la fusión en GitHub. Compruebe que la previsualización en Bolt y el repositorio coincidan plenamente tras la integración.

  4. Jueves: forzar los casos de error

    Pruebe a iniciar sesión con el rol incorrecto, fuerce sesiones expiradas, enlaces rotos, una modificación del esquema y la reactivación tras una pausa. Registre qué pasos de recuperación exigen intervenir fuera de la interfaz generada.

  5. Viernes: aplicar la regla de decisión

    Pase a Pro solo si el flujo superó las pruebas, el responsable técnico aprueba el código y el consumo de tokens guarda proporción con el valor obtenido. De lo contrario, opte por la alternativa especializada en la parte crítica de su proyecto.

Si desea ampliar su comparativa, consulte la guía actualizada sobre las mejores herramientas de vibe coding. Si Replit encaja en su enfoque pero busca opciones sin coste, la comparativa de alternativas a Replit para crear aplicaciones con IA gratis le ayudará a resolver el siguiente paso.

Preguntas frecuentes

¿Es Bolt New un sitio web legítimo?

Sí. Bolt.new es una plataforma operativa desarrollada por StackBlitz con precios oficiales, documentación pública, notas de versiones y canales de soporte técnico. Esto avala la solvencia del proveedor, aunque no garantiza que el código que genere sea apto para cualquier propósito. Conecte GitHub, audite los permisos y defina un procedimiento de recuperación de datos antes de gestionar información sensible.

¿Realmente funciona Bolt New?

Bolt ofrece flujos documentados y funcionales para aplicaciones web, bases de datos, sistemas de autenticación, alojamiento, sincronización con GitHub y proyectos móviles con Expo. Por ello, permite construir sistemas funcionales y no simples maquetas estáticas. Al tratarse de un análisis basado en especificaciones y condiciones del servicio, no se calcula una tasa de éxito cuantitativa ni se presupone que desarrollos complejos alcancen nivel de producción sin revisión de ingeniería.

¿Es Bolt New mejor que Cursor?

Bolt resulta más eficaz para convertir un informe inicial en una primera aplicación desplegada con infraestructura asociada dentro del navegador. Cursor es la herramienta adecuada para un programador experimentado que edita directamente una base de código preexistente. Elija Bolt antes de fijar la arquitectura y pase a Cursor cuando la propiedad del código y la disciplina del repositorio pasen a ser la tarea principal.

¿Es seguro Bolt New?

Bolt incorpora controles de acceso, listas blancas de URIs, detección de contraseñas vulneradas, configuración de seguridad y opciones de gobernanza en su plan Enterprise. No obstante, la seguridad real depende de las reglas de autorización, la custodia de credenciales, las dependencias, el modelo de datos, los respaldos y la operativa de la aplicación generada. Que Version History no restaure bases de datos obliga a diseñar un plan de recuperación independiente.

¿Es Bolt New totalmente gratis?

Bolt cuenta con un plan Free a $0 que incluye proyectos públicos y privados, 1 millón de tokens mensuales, un límite diario de 300,000 tokens, bases de datos ilimitadas y alojamiento básico. Mantiene la marca comercial de Bolt, limita los archivos a 10MB y detiene los sitios publicados si se alcanza el cupo compartido de 10GB de transferencia o 333,333 peticiones mensuales.

¿Es Bolt.new gratis durante 1 año?

La lista actual de precios recoge una modalidad Free a $0 de forma permanente y no como una promoción temporal de un año para planes de pago. Dicho plan gratuito está restringido por límites de tokens, tamaño de subidas, presencia de marca y cuotas de alojamiento. La capacidad de pago comienza formalmente en el plan Pro a $25 al mes en facturación mensual.

¿Cuáles son los precios de Bolt New?

Bolt estructura su oferta en Free ($0), Pro ($25 al mes), Teams ($30 por miembro al mes) y Enterprise con tarificación a medida. Anuncia hasta un 28% de descuento en el pago anual. El plan Pro parte de 10 millones de tokens mensuales, y el saldo no consumido en planes de pago se puede acumular durante un mes adicional mientras la suscripción permanezca activa.

Bolt New vs Lovable: ¿cuál elegir?

Elija Bolt si prioriza un flujo directo de prompt a código con Bolt Database, alojamiento integrado y salida temprana a GitHub. Seleccione Lovable si busca un diseño muy cuidado y trabajo en equipo: su plan Pro de $25 admite usuarios ilimitados que comparten el cupo de créditos. En Bolt Teams se abonan $30 por cada usuario, por lo que el tamaño del equipo puede decantar la balanza económica aunque el coste individual sea idéntico.

Obtenga la lista de comprobación de auditoría de flujos con IA

La lista de comprobación gratuita de auditoría de flujos empresariales con IA le ayuda a seleccionar un proceso, evaluar sus datos y el impacto de posibles fallos, designar un responsable y fijar una regla de parada antes de contratar otra herramienta de generación. Suscríbase para recibir la próxima edición verificada.

Última actualización

3 sept 2026

CategoríaBuild

Prefiera este sitio en Google

Añadir omidsaffari.com como fuente preferida en la Búsqueda de Google

Marque omidsaffari.com como fuente preferida y Google lo destacará para usted en Top Stories, AI Overviews y AI Mode.

Newsletter

Una carta, cada domingo. Sistemas que funcionan, no opiniones calientes.

Build logs, sistemas en producción y notas de campo de un portafolio de ventures de IA.

Semanal. Sin spam. Cancele cuando quiera.