Cuánto cuesta hacer una app con IA y qué no hace Lovable
Cuánto cuesta hacer una app con IA tiene dos respuestas muy distintas. En Lovable pagas una suscripción y los créditos que gastes. En unos días tienes pantallas que funcionan. Encargarla a Nimboo parte de 3.500 € por el diseño y de 36.000 € por un MVP en producción, por el trabajo de ingeniería que el generador no hace.
La respuesta corta
Cada camino entrega otra cosa.
| Camino | Qué tienes al terminar | Qué cuesta |
|---|---|---|
| La montas tú en Lovable | Pantallas que funcionan en días. La seguridad y los permisos quedan a tu cargo, según la documentación de Lovable | Suscripción y créditos. En el plan Pro, 50 créditos extra cuestan 15 $ y el alojamiento en Lovable Cloud gasta del mismo saldo |
| Encargas el diseño | Modelo de dominio y de datos, casos de uso, arquitectura, prototipo navegable de los flujos y presupuesto en firme del MVP | Desde 3.500 € en Nimboo. Se descuenta del MVP si lo contratas en los 60 días siguientes |
| Encargas un MVP en producción | Dos flujos de punta a punta y dos roles con usuarios reales, los datos de cada organización aislados, panel de administración y copias restauradas de verdad | Desde 36.000 € en Nimboo, con el diseño incluido |
La distancia entre la primera fila y la tercera sale casi entera del trabajo que no aparece en pantalla. Lo que entra exactamente en cada tramo está en los precios publicados.
Lo que Lovable resuelve bien
Lovable resuelve bien lo que se ve. Describes una pantalla con un mensaje y Lovable la genera. En una tarde tienes algo que enseñar a quien te lo tendría que comprar sin haber escrito una línea de código.
Tampoco te encierra. Según su documentación, Lovable sincroniza el código con un repositorio de GitHub en los dos sentidos y puedes desplegarlo fuera.
Antes de publicar, pasa un escaneo. La propia Lovable explica que ese escaneo encuentra fallos comunes pero no puede garantizar una seguridad completa. Deja por escrito que cumplir los requisitos de seguridad de la app es responsabilidad de quien la monta y para datos sensibles recomienda una revisión profesional.
El trabajo de ingeniería que hay detrás del precio
Lo que pagas al encargar una app es el trabajo que decide si aguanta clientes reales: el modelo del negocio, la arquitectura, las pruebas que protegen cada cambio y la forma de resistir los fallos. Casi todo pasa antes de la primera pantalla definitiva.
El modelo de dominio y los casos de uso
Empieza por el dominio. El modelo de dominio es el dibujo del negocio antes de programar, con las piezas que lo forman y las reglas que deciden quién puede tocar cada una. En un producto que usan varias empresas a la vez, sale algo muy parecido a esto.
Seis piezas y cómo se relacionan. Cada línea es una regla del negocio, y se acuerda antes de escribir código.
Cada línea es una decisión. Que un usuario pertenezca a una sola organización o a varias parece un detalle de nada, pero cambia el filtro de cada consulta del producto, de la primera a la última. Nimboo acuerda el modelo contigo antes de escribir código.
Moverlo después es reescribir.
Sobre ese modelo van los casos de uso, que describen cada cosa que alguien hace con el producto, paso a paso y con lo que hay que comprobar en cada uno. Un diagrama de secuencia enseña quién habla con quién y en qué orden. Así queda invitar a un compañero.
Invitar a un compañero, paso a paso. El rol se comprueba en el servidor, y el correo sale por una cola para que nadie espere a que se envíe.
El segundo paso no existe en una demo. El servidor comprueba el permiso, porque ocultar el botón en la pantalla no impide a nadie saltarse la pantalla y llamar directamente al servidor con la misma petición. Y el correo sale por una cola: si el proveedor tarda, quien invita no se queda esperando delante de la pantalla.
La arquitectura, con el negocio en el centro
La arquitectura decide dónde vive cada pieza. Nimboo usa arquitectura hexagonal, también llamada de puertos y adaptadores, que pone las reglas del negocio en el centro sin que sepan qué base de datos o qué pasarela de pago hay fuera.
Las reglas del negocio en el centro y todo lo de fuera enchufado a un puerto. Cambiar de pasarela de pago es cambiar un adaptador, y el dominio ni se entera.
Cada conexión con el exterior es un adaptador enchufado a un puerto. Si mañana cambias Stripe por otra pasarela, o llevas la facturación a Holded, basta un adaptador nuevo y las reglas del negocio siguen intactas. Las pruebas recorren el centro entero sin conectarlo a nada.
Pruebas que impiden que un cambio rompa lo anterior
Cualquier cambio puede romper otra cosa. Eso es una regresión: algo que funcionaba deja de funcionar por un cambio hecho en otra parte. Si nada comprueba el producto entero después de cada cambio, quien la encuentra es un usuario.
En los productos de Nimboo, cada cambio pasa pruebas automáticas antes de desplegarse. Las unitarias comprueban las reglas de una en una. Las de integración miran las piezas juntas. Si alguna falla, el cambio no sale. Cambiar la estructura de los datos con clientes dentro tiene su propio procedimiento, contado paso a paso en cambiar la base de datos sin parar el servicio.
Resiliencia: qué pasa cuando algo falla
Resiliencia es que el producto siga en pie cuando falla algo de fuera o cuando entra 10 veces más trabajo de golpe.
El trabajo pesado, como generar facturas o enviar mil correos, va a una cola que reparten varios trabajadores. Si uno cae, los demás siguen y repiten lo que quedó a medias. Si el uso sube, entran más máquinas. Si baja, se apagan y la factura baja con ellas. Un pago reintentado no puede cargar dos veces la tarjeta y la solución tiene nombre: idempotencia. Un proveedor lento no puede tumbar el producto entero; para eso están los cortacircuitos y los mamparos.
Antes de entregar, Nimboo restaura de verdad una copia de seguridad completa y deja las alertas configuradas para que lleguen al móvil de una persona concreta en cuanto algo falla.
Lo que no aparece en el precio de hacerla con IA
Falta la revisión de permisos. En el precio de Lovable no aparece nadie que revise quién puede leer cada dato y de ahí salen los fallos públicos de apps generadas con la herramienta.
En 2025, el investigador Matt Palmer revisó 1.645 apps publicadas con Lovable y encontró 170, el 10,3 %, que dejaban leer datos de sus usuarios a cualquiera. La causa eran reglas de acceso de la base de datos ausentes o mal configuradas. El fallo tiene su aviso de vulnerabilidad, el CVE-2025-48757, que Lovable disputa porque cada cliente responde de la seguridad de su propia app.
En febrero de 2026, The Register contó el caso de una sola app alojada en Lovable con 18.697 registros de usuarios expuestos, 16 vulnerabilidades y 6 de ellas críticas. El control de acceso estaba invertido: bloqueaba a quien debía dejar pasar y dejaba pasar a quien debía bloquear. Lovable respondió que su escaneo había avisado del problema y que aplicar las recomendaciones del escaneo quedaba en manos de quien había montado y publicado la app. Añadió que el proyecto incluía código que Lovable no había generado y que la base de datos vulnerable no estaba alojada en Lovable.
Ninguno de los dos casos compara con apps programadas a mano. Sirven para ver dónde fallan. Fallan en los permisos, cuando nadie los ha diseñado antes de construir la app.
Qué cuesta el segundo año
Una app hecha en Lovable sigue gastando créditos el segundo año, porque cada cambio que le pidas es un mensaje. Según su documentación, un mensaje en modo construcción consume entre 0,50 y 2 créditos en los ejemplos que publica. El alojamiento en Lovable Cloud sale del mismo saldo.
Encargada, necesita a alguien pendiente. En Nimboo, el mantenimiento va de 390 a 1.600 € al mes: el primer nivel cubre monitorización, parches de seguridad y respuesta en 48 horas laborables; el último suma 10 horas al mes de evolutivos y respuesta en 4 horas. Las demás partidas recurrentes están en cuánto cuesta desarrollar un SaaS.
Cuándo no compensa encargarla
Si todavía no has enseñado la idea a nadie que la fuera a pagar, no encargues un MVP a nadie, tampoco a Nimboo, porque todavía no sabes qué hay que construir. Móntala en Lovable y enséñasela.
Un generador sirve de sobra para comprobar si una idea interesa. Dejarlo no tiene fecha fija. Llega el momento cuando la app va a guardar datos de clientes reales o a cobrar por usarla, porque desde ese día un fallo de permisos expone los datos de alguien que confió en ti.
Si ya la tienes montada y empieza a fallar, el diagnóstico de prototipo dice en una semana qué aguanta y qué no. Nimboo conserva lo que ya validaron tus usuarios y sustituye el código generado.
Cómo comparar dos presupuestos
Compara respuestas antes que cifras. Estas seis preguntas separan a quien construye con método de quien entrega tal cual lo que sale del generador y un proveedor serio las contesta sin pensarlo mucho:
- ¿Quién dibuja el modelo de dominio y te lo enseñan antes de programar?
- ¿Te entregan la documentación de la arquitectura? En Nimboo va dentro de la entrega, junto con la de despliegue, escrita para que la entienda alguien de fuera que no haya visto nunca el proyecto.
- ¿Qué pruebas pasa cada cambio antes de desplegarse y qué ocurre si una falla?
- ¿Dónde comprueba el producto los permisos? La única respuesta buena es el servidor.
- ¿Qué le pasa al producto si cae un proveedor externo, como la pasarela de pago o el correo, justo el día que más clientes tienes dentro?
- ¿De quién son el código y la infraestructura? En Nimboo, el repositorio y la infraestructura están a tu nombre desde el primer día y el código pasa a ser tuyo desde el pago final del proyecto.
Todo este trabajo se paga el día que alguien que no eres tú confía sus datos a la app. Ni un día antes.
Qué entra en cada precio. El diseño de producto y el MVP están desglosados en /precios/. Si tienes una idea y quieres saber cuánto costaría construirla así, el diseño de producto de SaaS a medida le pone precio en firme antes de escribir código de producción.