Lovable — Generador de Aplicaciones Full-Stack con IA

¿Qué hace Lovable — Generador de Aplicaciones Full-Stack con IA?

Descripción general

Lovable (lovable.dev) genera y edita aplicaciones web a partir de prompts de chat en el navegador. Los proyectos usan Tailwind CSS y shadcn/ui; las aplicaciones creadas desde mayo de 2026 usan TanStack Start (renderizado del lado del servidor), las más antiguas usan React + Vite. Para el backend puedes elegir entre Lovable Cloud (base de datos, autenticación, almacenamiento, tiempo real y funciones integradas, basado en el stack de código abierto de Supabase) o tu propio proyecto de Supabase. El código se puede sincronizar de dos maneras con GitHub, y las aplicaciones se publican en una URL de Lovable o un dominio personalizado. No hay nada que instalar ni CLI; un agente ayuda escribiendo buenos prompts, revisando el resultado y trabajando en el repositorio sincronizado.

Instrucciones

1. Planificar antes del primer prompt

Responde cuatro preguntas: ¿qué es?, ¿quién lo usa?, ¿por qué?, y ¿cuál es la acción clave? Describe la aplicación sección por sección con contenido real, no con marcadores de posición. La guía de Lovable: un prompt de página completa da ruido, un prompt basado en secciones da señal. Nombra una dirección de diseño ("minimal", "premium", "divertido") para guiar la tipografía y el espaciado.

2. Elegir el backend

• Proyectos nuevos: Lovable Cloud (por defecto) o Supabase, elegido cuando se habilita el backend por primera vez.
• Los proyectos existentes conectados a Supabase siguen funcionando. No hay migración de Supabase a Cloud, ni movimiento con un solo clic de Cloud a tu propio proyecto de Supabase, así que decide al principio.

3. Trabajar en modos

Lovable tiene un modo Agente (construye y cambia cosas) y un modo Chat (discutir, planificar, sin ediciones). El modo Plan cuesta 1 crédito por mensaje; las ediciones normales cuestan aproximadamente 0.5-1.7 créditos dependiendo de la complejidad. Añade "Hazme cualquier pregunta que necesites antes de construir" para obtener preguntas aclaratorias. Pon reglas duraderas (stack, nomenclatura, tono) en el conocimiento del proyecto o del espacio de trabajo para que persistan entre chats.

4. Revisar la seguridad

Las tablas generadas deben tener Seguridad a Nivel de Fila. Lee cada política, ejecuta el escaneo de seguridad integrado y prueba con dos usuarios diferentes antes de publicar.

5. Sincronizar y poseer el código

Conecta GitHub desde la configuración del proyecto. La sincronización es bidireccional para una rama a la vez (la rama por defecto a menos que se cambie); las nuevas ramas comienzan desde la activa. Solo puedes exportar proyectos de Lovable a GitHub, no importar un repositorio existente, y los archivos de más de 10 MB no pueden ser editados por Lovable. Desconectar mantiene ambas copias, pero volver a conectar crea un nuevo repositorio.

6. Planes

Gratuito, Pro, Empresarial y Business; el precio es por créditos, no por asientos. Gratuito incluye 5 créditos de construcción diarios (hasta 30 al mes) más pequeños créditos de Cloud. Consulta lovable.dev/pricing para los precios actuales.

Ejemplos

Ejemplo 1: Aplicación de lista de espera con referidos

Solicitud: "Usa Lovable para construir una lista de espera SaaS: formulario de registro con un contador, enlaces de referido, un ranking y una página de administración."

Prompt para pegar:

Construye un sitio de lista de espera para "Parcelly", una herramienta de etiquetas de envío para vendedores de Etsy.
Secciones: hero ("Imprime etiquetas en 10 segundos") con un formulario de correo electrónico y un contador
 de registros en vivo; un ranking de los 10 mejores referidores; página /admin detrás de
 inicio de sesión por correo electrónico que liste los registros y exporte a CSV.
Cada registro obtiene un enlace de referido único (?ref=código) que acredita al referidor.
Estilo: minimalista, modo oscuro. Usa Lovable Cloud para datos y autenticación.
Hazme cualquier pregunta que necesites antes de construir.

Resultado: Lovable pregunta sobre correos de invitación, luego crea páginas, una tabla signups y políticas, y una URL de vista previa. Un conjunto razonable de tabla y políticas para comparar con el generado:

create table public.signups (
  id uuid primary key default gen_random_uuid(),
  email text not null unique,
  referral_code text not null unique default encode(gen_random_bytes(6), 'hex'),
  referred_by uuid references public.signups(id),
  created_at timestamptz not null default now()
);
alter table public.signups enable row level security;
create policy "cualquiera puede unirse" on public.signups for insert to anon with check (true);
-- leer todas las filas debe limitarse a administradores, por ejemplo, mediante una tabla user_roles

Ejemplo 2: Iterar y sincronizar con GitHub

Solicitud: "Añade un gráfico de registros a lo largo del tiempo, luego obtén el código en mi repositorio para poder seguir trabajando en Cursor."

Prompt de chat: "Añade un gráfico de líneas de registros por día en /admin usando los datos existentes; muestra un estado vacío cuando no haya registros." Luego: Configuración del proyecto, GitHub, Conectar, elige la cuenta y crea el repositorio. Después:

git clone [email protected]:parcelly-dev/parcelly-waitlist.git
cd parcelly-waitlist && npm install && npm run dev

Los envíos a la rama sincronizada aparecen en Lovable; mantén las ediciones locales en esa rama (o cambia la rama en la configuración del proyecto).

Directrices

• Pon cada característica principal en el primer prompt, luego cambia una cosa por seguimiento para que el historial de versiones siga siendo útil; marca las versiones que funcionan.
• No pegues claves de API en el chat; usa los cuadros de diálogo de secretos/integración. Las claves del lado del servidor pertenecen a las funciones del backend, nunca al código del cliente.
• Nunca confíes ciegamente en la RLS generada: una política insert ... with check (true) está bien para un formulario público, una política select no.
• Los créditos se consumen al construir, alojar y usar funciones de IA, y no son reembolsables; prefiere el modo Chat/Plan para preguntas.
• No es adecuado para aplicaciones móviles nativas, backends altamente personalizados o monorepositorios complejos existentes: usa un agente de codificación en el repositorio en su lugar.