Lovable para agencias: webs de cliente sin plantilla de WordPress

Montar la web de un cliente en una tarde suena de maravilla. Hasta que ese cliente te escribe en marzo pidiendo un cambio y tú ya no te acuerdas ni de con qué cuenta lo hiciste.

Ahí es donde se decide si esto es un negocio o un truco de feria. Así que vamos a las cuentas de verdad: qué gastas, qué entregas y qué tienes que dejar cerrado antes de cobrar.

¿Se pueden hacer webs de cliente con Lovable?

Sí, y sin retorcer nada. Es de los casos donde más sentido tiene.

La razón no es la velocidad, aunque la velocidad esté. Es que te saltas la parte más aburrida del trabajo: elegir plantilla, pelearte con el maquetador de turno, instalar cinco plugins para hacer una cosa que debería venir de serie. Le describes la web al modelo, sale una primera versión, y a partir de ahí tu trabajo es de dirección, no de montaje.

Lo que cambia no es la herramienta. Es dónde pones tus horas.

El flujo completo, sin adornos

Briefing. Lo mismo de siempre: qué vende, a quién, qué tiene que hacer el visitante y qué tres cosas no pueden faltar. Cuanto más concreto sea el briefing, menos vueltas le vas a dar después. Y cada vuelta cuesta créditos, así que aquí el papeleo se paga solo.

Primera versión. Le pasas el briefing y sale algo completo. No perfecto, completo. Este es el momento en el que tú decides si sirve de base o si hay que reformular la petición entera. Decidirlo pronto es lo que separa un proyecto rentable de uno que se te come el mes.

Iteración con el cliente. Aquí está el gasto real. El cliente ve la web, pide cambios, tú los pides al modelo, vuelta a empezar. Cada ronda consume. Por eso yo agruparía los cambios: nada de ir pidiendo de uno en uno según le van llegando los correos al cliente. Una lista, una tanda.

Entrega. Y este paso merece su propio apartado, porque es donde la gente se estrella.

¿Cuántos créditos cuesta una web de cliente de verdad?

No hay una cifra oficial, y no te la voy a inventar.

Lovable no publica un consumo medio por proyecto, porque depende del tamaño de la web, de lo claro que sea tu briefing y de cuántas rondas de cambios te pida el cliente. Cualquiera que te suelte "una web son X créditos" está adivinando.

Lo que sí sabemos con certeza son los límites. En el plan gratis tienes 5 créditos de build al día con un tope de 30 al mes. Ese tope es la medida honesta: si te lo comes con un solo proyecto, ya tienes tu respuesta sobre si el gratis te sirve para trabajar.

Así que la primera web de cliente la haces midiendo. Apuntas cuántos créditos te ha costado del briefing a la entrega y ya tienes tu número, el tuyo, el que sirve para presupuestar el segundo proyecto. Es más fiable que cualquier tabla que te enseñe nadie.

¿Por qué el tramo de 100 créditos se queda corto con tres clientes?

Porque los planes de pago se compran por tramos de créditos mensuales, y el de entrada está pensado para una persona haciendo sus cosas, no para alguien que factura por esto.

Haz la cuenta de tu mes real. Tres clientes activos no son tres webs nuevas: son una web nueva, una en rondas de cambios y una entregada que pide un retoque. Los créditos de build son un saldo mensual del espacio de trabajo, no un saldo por proyecto. Los tres beben del mismo sitio.

Y aquí es donde el razonamiento cambia de bando. Quien cobra por hacer webs no compra créditos, compra capacidad de facturar. Si un proyecto de cliente te deja varios cientos de euros, subir al tramo de 400 créditos por 100 $ al mes (enlace de afiliado: así me ayudas a seguir creando contenido) se paga con medio proyecto y te quita el freno de tener que racionar cambios a mitad de mes.

Lo que no te recomiendo es lo contrario: entrar en el tramo grande "por si acaso" antes de tener el primer cliente pagando. Mide con uno, sube después. En ese orden.

Un detalle a favor que casi nadie menciona: los créditos de suscripción sin usar se transfieren al siguiente ciclo mientras la suscripción siga activa. O sea, un mes flojo no se evapora del todo. Los saldos de Cloud y de IA, esos sí que no se acumulan.

Miembros ilimitados del workspace, en todos los planes

Esto está en la tabla oficial y aplica también al plan gratis: los miembros del espacio de trabajo son ilimitados.

Para un equipo pequeño es más importante de lo que parece. Significa que no pagas por asiento. Pagas por consumo. Si sois tres personas tocando proyectos, no multiplicas la factura por tres: seguís bebiendo del mismo saldo de créditos.

Cambia la forma de organizarse. En herramientas que cobran por usuario acabas compartiendo una cuenta, que es una guarrada y un riesgo. Aquí cada uno entra con lo suyo y la contabilidad es una sola.

¿Qué le entregas al cliente exactamente?

La pregunta del millón, y la que hay que responder antes de firmar, no después.

Lo que está documentado y puedes prometer sin miedo es el código. La sincronización con GitHub funciona en dos direcciones y está disponible en todos los planes, y la documentación dice que puedes clonar el repositorio y seguir trabajando en tu editor. Con un plan de pago, además, te lo descargas directamente. Así que "te entrego el repositorio con el código" es una promesa que se cumple.

Lo que yo no pondría en un presupuesto es el traspaso limpio de la cuenta y del proyecto de un espacio de trabajo a otro. No lo he verificado y no voy a hacer que te comprometas a algo que no sé si existe tal cual. Si vas a vendérselo al cliente, compruébalo tú antes en tu cuenta.

Y ojo con la diferencia entre entregar archivos y entregar un producto en marcha. No es lo mismo, y lo desmenucé en la deuda técnica que arrastran las apps hechas con IA. Un cliente que recibe un repositorio y no sabe qué hacer con él no ha recibido nada.

El problema del backend cuando el proyecto ya no es tuyo

Si la web del cliente usa el backend integrado de Lovable, hay una bomba de relojería silenciosa.

La documentación es explícita: los servicios de backend se pausan poco después de quedarte sin créditos, y las funciones de IA de las apps desplegadas dejan de funcionar. Los datos no se pierden, eso también lo dice, pero el servicio se para.

Ahora piénsalo con la web de un cliente dentro de tu espacio de trabajo. Si un mes te descuidas, o cierras la suscripción porque ese trimestre no hay proyectos, la web de tu cliente puede caerse. Y el teléfono que suena es el tuyo.

Hay dos salidas razonables. Una: si la web no necesita base de datos ni usuarios registrados, no le metas backend, y así no depende de ningún contador. Dos: en proyectos nuevos la documentación permite elegir Supabase en lugar del backend integrado, con lo que la parte crítica vive fuera y en una cuenta que puede ser del cliente. La segunda opción hay que decidirla al principio del proyecto, no cuando ya está entregado. Si quieres el detalle de cómo se reparten los saldos, lo tienes en los tres tipos de créditos de Lovable.

¿Cuándo NO usar Lovable para un cliente?

Cuando el cliente tiene un equipo que va a mantener la web por su cuenta con otra tecnología. Le vas a entregar algo que nadie de dentro sabe tocar.

Cuando el proyecto es de esos que crecen durante años y cambian de manos varias veces. Ahí quieres control total del código desde el minuto uno y un flujo de trabajo normal, no una herramienta en medio.

Y cuando el cliente no quiere ni oír hablar de servicios de terceros para sus datos. Esa conversación se tiene antes de construir, no después.

Para el resto, que es la mayoría de webs de negocio pequeñas y medianas, la combinación que a mí me parece más sensata es hacer la primera versión rápido y bajar al código para lo serio. Es justo el planteamiento que conté en cómo montar la web de un cliente combinando Lovable y Claude Code.

Qué dejar por escrito en el presupuesto

Cuatro líneas que te ahorran cuatro discusiones:

Rondas de cambios incluidas. Un número. Dos, tres, las que sean. Sin esto, el cliente cree que los cambios son infinitos porque "si lo hace la IA es gratis".

Qué se entrega. El repositorio con el código, la web publicada, y quién es el dueño de la cuenta a partir de la entrega.

Quién paga el mantenimiento. Si la web usa backend, alguien tiene que sostener el saldo cada mes. O es una cuota tuya, o es del cliente en su cuenta. Nunca "ya lo vemos".

Qué pasa si el cliente quiere irse. Con el código en un repositorio suyo, esta cláusula es fácil y te hace quedar bien. Aprovecha.

Los precios y tramos que menciono son los publicados en la documentación oficial en el momento de escribir esto, y conviene mirarlos en su página de planes antes de contratar nada, porque los mueven.

Si lo que estás montando es un negocio de una sola persona vendiendo este tipo de trabajo, el sistema completo para llevarlo sin morir en el intento es lo que enseño en Yo S.A..