Lovable: qué es y cuándo se te queda corto

Lovable es una herramienta que construye aplicaciones web a partir de instrucciones en texto. Le describes lo que quieres, genera el código, y la aplicación queda publicada en una URL en cuestión de minutos. Por debajo monta un proyecto de React con una base de datos de Supabase, y tú no tocas ninguna de las dos cosas: hablas con un chat y el resultado aparece.

Eso es todo lo que es, y es bastante. En la práctica significa que una persona sin base de programación puede tener funcionando en una tarde algo que antes costaba semanas y un presupuesto.

La pregunta interesante no es qué es. Es hasta dónde llega.

Para qué sirve de verdad

Lovable resuelve muy bien un problema concreto: averiguar si la idea vale algo antes de gastar dinero en construirla.

Sirve para enseñarle a alguien una pantalla real en vez de un dibujo. Sirve para que diez personas usen algo durante dos semanas y te digan qué sobra. Sirve para descubrir que la función que creías central no la usa nadie, que es el descubrimiento más barato que vas a hacer en todo el proyecto.

Para eso es difícil que se le gane hoy. Si estás en esa fase, úsalo y no le des más vueltas.

Dónde empieza el problema

El problema no aparece cuando el prototipo falla. Aparece cuando funciona.

En el momento en que la gente empieza a usar la aplicación de verdad, deja de ser un experimento y pasa a ser un sistema del que alguien depende. Y ahí las decisiones que Lovable tomó por ti, que eran las correctas para ir rápido, empiezan a pasar factura.

Las tres que más pesan:

Tu aplicación y tus datos viven en la cuenta de otro. El código está en Lovable, la base de datos en Supabase. Mientras todo va bien no se nota. Se nota el día que cambia un precio, cambia un límite del plan gratuito, o necesitas algo que el proveedor no ofrece.

No hay sitio donde probar antes de publicar. En un proyecto normal existe un entorno local donde rompes cosas sin que lo vea nadie, y una rama que se revisa antes de entrar. En un flujo de chat, cada cambio va directo a lo que la gente está usando.

El chat no recuerda tu arquitectura. Le pides un ajuste, te lo hace, y de paso reescribe una parte que funcionaba. Con quince pantallas es molesto. Con cincuenta y usuarios reales dentro es un problema serio, porque nadie tiene el mapa completo de qué depende de qué.

Las cinco señales de que se te quedó corto

No hay un número mágico de usuarios. Hay síntomas:

1. Pides un cambio y se rompe otra cosa. Ya no es una casualidad, pasa casi siempre. Es la señal más clara de que el proyecto creció por encima de lo que cabe en una conversación.
2. Tienes miedo de tocarlo. Funciona, hay gente usándolo, y prefieres no pedir nada nuevo por si acaso. Un sistema que da miedo tocar ya dejó de ser una ventaja competitiva.
3. Necesitas algo que la herramienta no hace. Conectar con el software que ya usa tu cliente, procesar un archivo pesado, mandar un informe cada noche a las tres.
4. Alguien te pregunta dónde están los datos. Un cliente grande, un contrato, una revisión de seguridad. Si la respuesta es «en la cuenta de una herramienta que uso», la conversación se complica.
5. El coste crece con el uso y no lo controlas. Empezó gratis, ahora es una cifra mensual que sube sola y no sabes en función de qué.

Si te reconoces en tres o más, el prototipo ya hizo su trabajo. Lo que falta no es más prompt, es infraestructura debajo.

Qué NO hay que hacer

Tirarlo y empezar de cero.

Es el error caro y el más común, porque suena a lo correcto. Pero el prototipo que la gente usa ya resolvió la parte difícil del proyecto, que es saber qué hay que construir. Todas esas decisiones están dentro: qué pantallas hacen falta, qué campos importan, en qué orden hace las cosas la gente. Eso vale más que el código.

Empezar de cero significa volver a descubrirlo todo, y con una fecha de entrega encima.

Cómo se hace en la práctica

Lo cuento con un caso, porque es el único modo de que esto signifique algo.

peak-athletiks tenía una aplicación construida en Lovable que estaban usando equipos reales. Funcionaba. Y colgaba de dos proveedores: Lovable para el código, Supabase para los datos. El desarrollo iba por chat, con archivos zip de por medio, y cada tanda de cambios daba un resultado distinto sin que se supiera bien por qué.

Lo que hicimos no fue reescribirla. Fue ponerle suelo:

• El frontend y el backend se separaron, con Spring Boot y Postgres detrás en vez de la base de datos del proveedor.
• Todo se movió a Azure, a cuentas de la empresa.
• Se montó un entorno de desarrollo local, para que probar algo dejara de significar publicarlo.
• Se conectó el despliegue automático: cada commit que pasa las comprobaciones sube solo.
• Se añadió RAG, que era una de las cosas que la herramienta original no permitía hacer.

El resultado no es «una aplicación más rápida». Es que el equipo puede cambiar algo un martes sin que nadie contenga la respiración, y que si mañana Azure deja de convenirles, se la llevan.

Entonces, ¿Lovable sí o no?

Sí, para lo que es: descubrir si la idea funciona, con el menor gasto posible.

Lo que no conviene es confundir esa fase con la siguiente. Un prototipo que nadie usa no necesita arquitectura, y ponérsela es tirar el dinero. Un prototipo del que ya dependen personas la necesita, y no ponérsela es acumular una deuda que se paga entera y de golpe, normalmente en el peor momento.

La señal para cruzar de una fase a la otra no es técnica. Es que alguien se enfade si la aplicación no funciona por la mañana.

Si estás en ese punto

Cada semana escribo sobre un sistema que está corriendo en un negocio real: qué hace, cómo está montado y qué se rompió por el camino. Incluidos los casos en los que la respuesta correcta era no construir nada. Si estás en este punto, suscríbete a la newsletter.