Bolt.new: cómo crear una app funcional en una tarde

Escribes lo que quieres, le das a enter, y a los cuarenta segundos tienes una aplicación funcionando en el navegador. Con su base de datos, su login y su pantalla de listado.

Eso es Bolt.new y la primera vez impresiona bastante. La segunda vez ya empiezas a ver dónde está el truco.

He montado varias cosas con él, incluida una que sigue en uso. Te cuento el proceso real, no la demo de marketing.

¿Qué se puede hacer con Bolt.new en una tarde?

Una aplicación web pequeña con una función clara y completa. Un panel para gestionar algo, una herramienta interna de esas que en tu equipo se hacen con una hoja de cálculo compartida, un formulario con lógica y una pantalla de resultados.

Lo que no vas a tener en una tarde: un producto para vender a clientes, con pagos, cuentas de usuario bien hechas, permisos y todo lo demás. Eso son semanas, y llega un punto en que necesitas entender lo que hay debajo.

La distinción importa porque la mayor parte de la frustración con estas herramientas viene de esperar lo segundo y recibir lo primero.

Qué es exactamente Bolt y en qué se diferencia

Bolt escribe código de verdad. No monta bloques prefabricados: genera un proyecto entero con su código fuente, lo ejecuta en el navegador y te lo enseña funcionando en directo, a la izquierda el chat y a la derecha la aplicación.

Eso tiene dos consecuencias, una buena y una mala.

La buena: lo que sale es tuyo y te lo puedes llevar. Descargas el proyecto, lo subes a tu propio sitio, y no dependes de Bolt para nada. Eso es una diferencia enorme frente a las herramientas donde tu aplicación vive dentro de la plataforma para siempre.

La mala: como es código real, cuando algo se rompe, se rompe como se rompe el código. Con un error rojo que no entiendes y que hay que arreglar dentro del propio código.

Paso 1: el primer prompt, que decide media tarde

Aquí es donde la gente lo hace mal, yo el primero.

El impulso es escribir "hazme una aplicación para gestionar mis clientes". Y te la hace. Con veinte campos que no querías, un diseño genérico y una estructura que no encaja con lo que tenías en la cabeza. Luego pasas dos horas corrigiendo, y corregir cuesta más que construir bien de entrada.

Lo que funciona es describir tres cosas antes de pedir nada:

Qué datos hay. "Hay clientes, con nombre, correo, empresa y estado. El estado puede ser: contactado, propuesta enviada, cerrado."

Qué pantallas hay. "Una lista con filtro por estado, una ficha de cliente y un botón para crear."

Qué hace la aplicación que no sea guardar y mostrar. "Cuando un cliente lleva más de quince días en propuesta enviada, sale marcado en rojo."

Con eso, el primer resultado se parece bastante a lo que querías. Sin eso, empiezas a negociar con la máquina.

Paso 2: ir por partes, no de golpe

El segundo error clásico es pedirlo todo en el mismo mensaje.

Bolt lo intenta, y en un proyecto grande empieza a tocar cinco archivos a la vez. Cuando algo falla, no sabes qué cambio lo rompió, y la conversación se convierte en un juego de arreglar lo que se acaba de romper mientras se rompe otra cosa.

La forma que funciona: una función por mensaje. Primero la lista. Compruebo que funciona. Luego el formulario de crear. Compruebo. Luego el filtro. Compruebo.

Es más lento sobre el papel y bastante más rápido en la realidad.

Paso 3: los datos

En algún momento vas a querer que los datos se guarden de verdad y no desaparezcan al recargar. Bolt se lleva bien con Supabase, que es una base de datos con su sistema de cuentas de usuario incluido.

Se lo pides directamente ("conecta esto a Supabase y guarda los clientes ahí"), te pide las claves, y lo monta. Este es el paso que más impresiona a quien no ha programado nunca, porque es exactamente el punto donde antes tenías que llamar a alguien.

Ojo con los permisos de acceso. Por defecto puede quedar todo abierto, y "abierto" significa que cualquiera con la dirección puede leer tus datos. Pregúntale explícitamente por las reglas de seguridad y revisa que estén puestas antes de meter nada real.

Paso 4: publicarlo

Le das al botón de desplegar y en un minuto tienes una dirección pública funcionando. Puedes conectarle tu propio dominio.

Para una herramienta interna o un prototipo que enseñar, con eso vas servido. Para algo serio, yo me llevaría el código a mi propio servidor.

Cuánto cuesta esto de verdad

El plan gratuito sirve para probar y para hacerte una idea. Para montar algo de principio a fin, se te acaba en una tarde larga, y no porque sean tacaños: es que cada mensaje del agente consume de verdad.

La cuenta que yo haría antes de pagar nada: monta el proyecto pequeño con lo gratis, apunta cuántos mensajes te ha costado tenerlo funcionando, y multiplica por lo que quieres construir. Si te sale un mes de suscripción, adelante. Si te salen tres, replantea el alcance del proyecto, porque probablemente estés intentando construir algo demasiado grande para esta herramienta.

Y una cosa que ahorra dinero de verdad: cuando el agente se atasca, cambiar de estrategia en lugar de insistir. Cuatro mensajes de "sigue sin funcionar" cuestan lo mismo que cuatro mensajes construyendo, y no dejan nada.

Lo que se te va a atascar

Los tokens. Este es el gran tema. Cada mensaje consume, y los mensajes en los que Bolt está peleando con un error consumen igual que los productivos. Si te metes en un bucle de arreglar fallos, te fundes la cuota del día sin haber avanzado nada. Cuando veas que van tres intentos y el error sigue ahí, para. Empieza una sesión nueva describiendo el problema desde cero, o dile que revierta al punto anterior y ataca por otro lado.

El bucle de errores. Es el fallo clásico de todas estas herramientas: arregla A y rompe B, arregla B y vuelve A. La salida es siempre la misma: retroceder a la versión que funcionaba y pedir el cambio de otra manera, más pequeño.

El diseño por defecto. Todo lo que sale de Bolt se parece entre sí. Si no le das indicaciones de estilo, tu aplicación tiene la misma cara que las otras cien mil. Dile colores, tipografía y densidad desde el principio.

El techo. Llega. Cuando el proyecto se hace grande, Bolt empieza a perderse entre sus propios archivos. Ahí es donde a mí me toca cambiar de herramienta y seguir en un entorno con más control, normalmente Claude Code, que es lo que uso para las cosas que van en serio.

¿Y frente a las alternativas?

Bolt no es la única y no es la mejor para todo. La comparo cara a cara con las dos que compiten directamente en Lovable frente a Bolt y en Replit frente a Bolt, con precios reales y en qué caso elegiría cada una.

Resumen apresurado por si no vas a leerlas: Bolt para prototipar rápido y llevarte el código, Lovable si te importa mucho que quede bonito sin pelearte, Replit si quieres que además viva y se ejecute en algún sitio sin montar nada.

El mapa completo de este tipo de herramientas está en crear apps sin programar.

Y ahora qué

Coge la cosa más pequeña y aburrida que hagas hoy con una hoja de cálculo. Esa. No la aplicación de tus sueños.

Móntala en Bolt esta tarde, úsala una semana de verdad, y luego decide si merece la pena hacerla bien. La mayoría no lo merece, y descubrirlo en una tarde en vez de en tres meses ya es ganar.

Antes de meterte a montar nada, igual te viene bien saber qué tipo de herramienta encaja con lo que haces tú. Hice un test corto que lo resuelve en dos minutos.

Hacer el test de IA