En marzo de 2026, Lovable llegó a $400 millones de ARR con 146 empleados. 8 millones de usuarios activos, 200,000 proyectos por día, Serie B de $330 millones a una valoración de $6.6 mil millones respaldada por Nvidia y Salesforce. Proyectos en la plataforma han generado revenue real: Lumoo €700K ARR, ShiftNex $1M ARR, Q Group $3M en 48 horas.
Esta guía cubre todo para usar Lovable como power user: prompting que ahorra créditos, Supabase bien configurado, deployment sin sorpresas, y los patrones de seguridad que previenen CVE-2025-48757 (170+ apps expuestas). Con datos y ejemplos verificables, sin teoría vacía.
1. Prompting avanzado: los 4 niveles y 7 comandos que usan los mejores builders
Los 4 niveles de prompting oficial
La Lovable Prompting Bible define cuatro niveles de sofisticación para interactuar con la plataforma.
Nivel 1 - Training Wheels: usas la IA para escribir el prompt inicial. Ideal para quien no sabe por dónde empezar:
You are a world-class prompt engineer. Write me a prompt that will generate
a full-stack app taking an input of name, number, and company, and generate
a company report.Nivel 2 - No Training Wheels: prompts conversacionales directos pero bien estructurados, donde describes claramente lo que necesitas sin intermediarios.
Nivel 3 - Meta Prompting: usas la IA para refinar los propios prompts antes de ejecutarlos:
Rewrite this prompt to be more concise and detailed: 'Create a secure login
page in React using Supabase, ensuring role-based authentication.'Nivel 4 - Reverse Meta Prompting: guardas las sesiones de debugging para optimizar prompts futuros, creando una biblioteca de patrones probados:
Summarize the errors we encountered while setting up JWT authentication and
how they were resolved. Create a detailed prompt I can use next time.Framework Context / Task / Guidelines / Constraints
La estructura jerárquica más recomendada por power users, según la Lovable Prompting Bible:
# Context
Estoy construyendo un SaaS de gestión de inventario para restaurantes B2B.
Task
Crea el módulo de gestión de productos con CRUD completo.
Guidelines
- Usa React con TypeScript
- Supabase para autenticación y base de datos
- Tailwind CSS + shadcn/ui para estilos
- Diseño tabla con filtros y búsqueda en tiempo real
#### Constraints
- No toques las páginas de autenticación existentes
- Mantén la paleta de colores actual (#1E293B primario)
- Solo modifica el componente ProductList, no el layout globalEsta estructura funciona porque prioriza la información de mayor nivel y desciende hacia las restricciones específicas. La IA de Lovable procesa mejor el inicio y el final del prompt, así que la información más importante va al principio.
Los 7 comandos de power users
Basado en el análisis de 500+ prompts reales documentado en Reddit r/lovable:
| Comando | Propósito | Ejemplo |
|---|---|---|
| CLARIFY | Eliminar suposiciones antes de codificar | "Request three clarifying questions about [feature] before any code is generated. Focus on: data, user, and edge cases." |
| ATOMIC | Construir componente por componente | "Don't build the entire [page] at once. Start with just the [button/card] and add the next component after." |
| SQL | Separar UI de datos | "For now, mock the UI, but give me the precise Supabase SQL for a table that handles [feature]. Include: all required fields, Row Level Security, key relationships." |
| NO AUTOPILOT | Evitar jerga corporativa y contenido vago | "Avoid: vague adjectives (seamless, robust, innovative), marketing phrases, filler content. If something is complex, explain why directly." |
| ACT AS | Dar contexto de rol específico | "Act as a solo founder who just got burned by technical debt from their last MVP. You're suspicious of anything that looks like a shortcut." |
| COMPARE | Evaluar opciones antes de decidir | "Show me two versions of [component]: Version A: [style 1], Version B: [style 2]. Highlight differences in Tailwind classes and performance implications." |
| ELI5 | Simplificar UX para usuarios no técnicos | "Describe this [feature/flow] as if I'm a high-school student who has never used a SaaS product before." |
Plantillas por tipo de aplicación
Para landing pages, la documentación oficial recomienda construir sección por sección, nunca la landing completa de una vez. Prompt 1 define el diseño visual (colores, tipografía, tono), Prompt 2 construye el hero, Prompt 3 el feature grid, y así sucesivamente. Cada sección debe revisarse y aprobarse antes de avanzar.
Para dashboards, la estructura recomendada incluye: propósito claro, lista de features, user flow explícito, data model con tablas y campos, y estilo de UI. Especificar todo eso en un solo prompt inicial ahorra créditos en iteraciones posteriores.
Para apps SaaS completas, construir primero el PRD con ChatGPT o Claude y después pasarlo a Lovable por secciones:
You are an AI developer building the [Feature Name] for a SaaS platform.
Here's the PRD for this component: [PEGAR CONTENIDO DEL PRD]
Implement it using Tailwind, React, and Supabase.
Follow accessibility and performance best practices.
Start with the [primera pantalla específica] only.Errores comunes al escribir prompts
Según lovable-prompts.com, los errores más frecuentes y cómo evitarlos:
| Error | Incorrecto | Correcto |
|---|---|---|
| Ser demasiado vago | "Make a landing page that looks good." | "Create a SaaS landing page with hero, 3-column feature grid, pricing table (Free/Pro/Team), and email signup form." |
| Pedir todo a la vez | "Build a complete e-commerce platform..." | "Start with: 'Create the product catalog page with a grid of product cards.'" |
| Olvidar responsividad | "Build a dashboard with sidebar navigation." | "On desktop: fixed sidebar. On mobile: sidebar converts to bottom navigation." |
| Dejar que reescriba todo | No especificar alcance | "Only alter this component. Maintain core functionality." |
Un error particularmente costoso: usar datos placeholder. Lovable funciona mal con "lorem ipsum" o "feature 1 / feature 2", el texto real revela problemas de diseño que el placeholder oculta.
Chat Mode vs Agent Mode
| Modo | Cuándo usarlo |
|---|---|
| Chat Mode | Planificar, depurar, analizar errores, brainstorming, revisar el Knowledge Base |
| Agent Mode | Ejecutar cambios reales al código |
La regla fundamental según Reddit Power Users Guide: planificar en Chat Mode, implementar en Agent Mode. Para tareas complejas con edge functions, Supabase o múltiples archivos, usar Chat Mode para discutir la estrategia primero:
Don't change code. For this issue, please identify the top five potential
causes in order of likelihood and explain how to test each one.Knowledge Files y AGENTS.md
Lovable permite definir contexto persistente a través del Knowledge Base (Lovable Docs). Existen tres niveles: Workspace Knowledge (todos los proyectos, límite 10,000 chars, solo admins), Project Knowledge (un proyecto, mismo límite) y el archivo AGENTS.md en el root del repositorio GitHub, que no tiene límite definido y Lovable lo lee en cada sesión.
El truco del AGENTS.md es el más poderoso: supera el límite del Knowledge Base nativo y persiste sin importar cuánto contexto haya en la conversación. Instrucciones recomendadas para incluir:
- Prioritize straightforward, clean, and maintainable solutions over clever ones.
- Make the smallest necessary adjustments. Always seek approval before overhauling.
- Do not implement mock modes. We always use real data and APIs.
- When addressing a bug, do not discard the existing implementation without explicit permission.
- Always request clarification instead of making assumptions.Try to Fix es gratuito, úsalo siempre primero
El botón "Try to Fix" no consume créditos y debe ser siempre el primer paso ante cualquier error. Según la Lovable Prompting Bible, intentar "Try to Fix" hasta 3 veces antes de gastar créditos en un prompt de corrección. Si después de 3 intentos no resuelve, copiar el error al Chat Mode y pedir: "Use chain-of-thought reasoning to identify the root cause."
2. Supabase: conectar bien desde el principio o pagar el precio después
Guía de conexión paso a paso
Lovable orquesta Supabase de forma integral: lee el schema completo, accede a secrets, lee logs de edge functions para auto-depurar, y despliega edge functions via CLI interno (Lovable Blog). Conexión: crear proyecto en supabase.com, abrir Settings → Integrations → Supabase → Connect Supabase, autorizar vía OAuth.
Orden de construcción crítico: conectar Supabase antes de construir features. Las apps construidas con datos mock frecuentemente se rompen completamente al conectar Supabase después (Reddit).
Configuración de autenticación
Prompt recomendado para email/password (Lovable Blog): pedir login con email/password, tabla profiles vinculada a auth.users, proteger todas las rutas con redirect a /login para no autenticados, manejo de estados de error (contraseña incorrecta, sesión expirada, fallo de red). Lovable auto-genera el SQL con trigger on_auth_user_created.
Para OAuth (Google, GitHub): configurar el proveedor en Supabase Authentication → Providers con Client ID y Secret, y agregar la URL de redirect exacta (https://yourapp.lovable.app/auth/callback). El mismatch de redirect URL es el error más común.
Diseño de base de datos antes de construir
La práctica más importante según constructores experimentados: diseñar el schema antes de empezar a construir con Lovable. Usar GPT o Claude para refinar el schema y luego proporcionarlo como contexto. Otras prácticas clave:
- Usar Plan Mode antes de cambios de schema, es más confiable que Agent Mode para modificaciones de base de datos
- Rastrear cambios de schema manualmente, Lovable puede modificar el schema silenciosamente durante adiciones de features
- Nunca dejar que Lovable modifique archivos .env
Row Level Security: hallazgos críticos de auditoría
Una auditoría de marzo 2026 sobre 29 apps Lovable+Supabase reveló un score promedio de seguridad de 56/100, con 23 de 29 apps por debajo de 70. El 28% tenía credenciales de Supabase visibles en código del cliente (Reddit r/lovable).
El bug de recursión infinita es el error de RLS más común: "infinite recursion detected in policy for relation 'profiles'". Ocurre cuando una política llama a una función que consulta la misma tabla:
-- INCORRECTO: crea recursión
CREATE POLICY "bad_policy" ON profiles FOR SELECT
USING (company_id = get_user_company_id());
-- CORRECTO: comparación directa
CREATE POLICY "good_policy" ON profiles FOR SELECT
TO authenticated
USING (auth.uid() = id);Storage: políticas separadas y límite de 50MB
Los buckets de Storage no heredan las políticas RLS de las tablas, las políticas deben configurarse por separado en storage.objects. Esta es una fuente frecuente de errores "permission denied" en uploads:
-- Permitir uploads autenticados
CREATE POLICY "Users can upload their own files"
ON storage.objects FOR INSERT
TO authenticated
WITH CHECK (bucket_id = 'avatars' AND auth.uid()::text =
(storage.foldername(name))[1]);Edge Functions: no se auto-despliegan
Las Edge Functions no se auto-despliegan con actualizaciones de código en Lovable, problema ampliamente reportado en Reddit. Soluciones:
- Deploy manual desde Supabase Dashboard → Edge Functions → Deploy
- Prompt: "Deploy the edge function for [function-name]"
- CLI directa:
supabase functions deploy <function-name> - Opción nuclear: eliminar la función y recrear desde cero
7 patrones de error documentados con soluciones
- App se congela post-login: deadlock en
onAuthStateChangecon async callbacks. UsarsetTimeoutpara diferir llamadas Supabase dentro del callback - Recursión infinita en RLS: políticas que consultan la misma tabla que protegen. Usar
auth.uid()directo, sin funciones helper - Datos vacíos por UUID mismatch: RLS usa UUID pero código usa ID numérico. Asegurar que
user_iduse UUID - "Thinking..." al conectar: OAuth handshake comprometido. Desconectar, limpiar caché, reconectar
- Todo se rompió al conectar Supabase: features construidas con datos mock. Conectar Supabase antes de construir
- Edge Functions no se despliegan: no hay auto-deploy. Deploy manual desde dashboard
- Credenciales expuestas: keys en video o GitHub público. Rotar keys en Supabase y reconectar en Lovable
Performance: el problema N+1
El código generado por Lovable frecuentemente produce patrones N+1: una query por cada registro en vez de un JOIN. Identificar con EXPLAIN ANALYZE y corregir usando la sintaxis de join nativa de Supabase: supabase.from('orders').select('*, users(name, email)') en vez de iterar con queries individuales por usuario.
Multi-tenancy con Clerk y advertencia sobre Lovable Cloud
El patrón más avanzado para apps B2B según el Clerk Blog: combinar Clerk para organizaciones con una función de contexto en Supabase que primero verifica el org_id del JWT y cae al auth.uid() si no existe. Esto permite políticas RLS que sirven tanto a usuarios individuales como a organizaciones.
Advertencia sobre Lovable Cloud: una vez activado, no se puede desactivar. La migración requiere crear un proyecto nuevo. La comunidad recomienda usar Supabase externo para cualquier proyecto que pueda llegar a producción.
3. Deployment y producción: las tres rutas y cómo escalar
Las tres opciones de deployment
Las apps de Lovable son proyectos estándar Vite + React (SPA / Client-Side Rendered). Existen tres opciones según la documentación oficial:
Opción 1 - Lovable Cloud (recomendado para la mayoría): publicar, configurar URL, metadata, OG image, Review security, Publish. Incluye hosting con dominios custom, SSL automático, CDN global, certificación SOC 2 Type 2 e ISO 27001. Las actualizaciones no se publican automáticamente, requieren Publish → Update.
Opción 2 - Hybrid: Lovable para desarrollo y previews, frontend en producción en Netlify, Cloudflare Pages o Vercel.
Opción 3 - Fully self-managed: código sincronizado vía GitHub, frontend en containers o plataformas propias, backend en Supabase self-hosted.
Growth MarketingEl 95% de los pilotos de IA fallan. Este sistema es para el otro 5%.
Inmersión presencial con tus datos, tus campañas y tu equipo. Salen operando agentes desde la primera sesión, no con apuntes.
Ver si aplica para mi equipo →Configuración de dominio personalizado
Disponible en planes pagos (Pro desde $25/mes). La configuración automática usa Entri para actualizar DNS (documentación oficial):
| Tipo | Host | Valor |
|---|---|---|
| A | @ o vacío | IP provista por Lovable |
| TXT | _lovable_verify.tudominio | String de verificación |
Notas críticas: no agregar registros AAAA, pueden interferir con el routing. Si se usa CDN como Cloudflare, no conectar el dominio vía Project Settings. El primer dominio conectado se convierte en el primary domain.
SEO para apps Lovable: el problema CSR
Las apps Lovable son Client-Side Rendered: los motores de búsqueda reciben HTML vacío en el primer crawl. Google puede indexarlas pero en dos etapas, tomando días en vez de horas. Las plataformas sociales y crawlers de IA no ejecutan JavaScript (Lovable Docs). Checklist esencial: XML sitemap, robots.txt con acceso a AI bots (GPTBot, PerplexityBot, Claude-Web), page titles únicos menores a 60 caracteres, meta descriptions únicas, structured data JSON-LD, Open Graph tags con imagen 1200×630px, custom domain (no .lovable.app), y página /llm.html con resumen estático para IA. Para crawlers sin JS: LovableHTML, proxy que sirve HTML/CSS estático.
Exportar a Vercel y Netlify
En Netlify (guía oficial): conectar Lovable a GitHub, Import existing project, build command npm run build, output dist, Node 22, variables de entorno, y crear _redirects en /public con /* /index.html 200 para SPA routing. Auto-deploy en cada push a GitHub.
En Vercel: proceso similar, con vercel.json que contenga {"rewrites": [{"source": "/(.*)", "destination": "/index.html"}]}.
GitHub integration
Cada cambio en Lovable genera un commit en rama main. Solo se sincroniza la rama default. No se puede importar un repo existente, renombrar el repo rompe la conexión, y no se puede cambiar la cuenta de GitHub vinculada.
Workflow para reducir costos 90%: Lovable → GitHub → Codespaces → Claude Code CLI ($20/mes) → Test local con Supabase local → Push commits → Lovable auto-sync.
Comparación de costos de hosting
| Solución | Costo aprox. | Pros | Contras |
|---|---|---|---|
| Lovable Cloud | Incluido ($25-50/mes) | All-in-one, managed, SSL, CDN | Menor control |
| Netlify (Free) | $0 (100GB bandwidth) | Fácil CI/CD, preview deploys | Límites en free tier |
| Vercel (Free) | $0 / $20/mes (pro) | Performance excelente | Hobby no para uso comercial |
| Cloudflare Pages | $0 (generoso free tier) | CDN ultra-rápido | Más setup manual |
| AWS S3+CloudFront | ~$1-5/mes | Escala infinita | Setup complejo |
Ruta de escalabilidad en 4 etapas
Etapa 1: Lovable Cloud completo → MVP, <100 usuarios → $25/mes
Etapa 2: Frontend externalizado → Netlify/Cloudflare + Supabase Cloud → $25-45/mes
Etapa 3: Backend propio → Supabase managed independiente → según proveedor
Etapa 4: Custom development → Claude Code + Vercel + Supabase → ~$20-50/mesChecklists de producción
Pre-deployment: favicon personalizado, site title y meta description configurados, Lovable badge removido, Review security completado, RLS habilitado en Supabase, testing manual en Chrome/Firefox/Safari y móvil, Lighthouse score 90+.
Post-deployment: Sentry para tracking de errores en tiempo real, Google Analytics o alternativa, monitoreo de uptime (UptimeRobot, Better Uptime), GitHub sync desde el día 1.
4. Lovable vs competidores: dónde gana y dónde pierde
Panorama del mercado
El mercado de herramientas de código IA se proyecta en $26 mil millones para 2030. Cursor pasó de $0 a $1B+ ARR en ~24 meses. Lovable: $400M ARR, $6.6B valoración, respaldado por Nvidia, Salesforce y Deutsche Telekom. Replit: $253M ARR estimado.
| Herramienta | Tipo | Target | Stack output |
|---|---|---|---|
| Lovable | AI App Builder full-stack | No-técnicos, fundadores, PMs | React + Vite + Supabase |
| Bolt.new | AI App Builder browser IDE | Developers + builders | React, Vue, Svelte, Next.js |
| v0 (Vercel) | UI Component Generator | Frontend developers | React + shadcn/ui |
| Cursor | AI Code Editor (IDE) | Developers profesionales | Cualquier stack |
| Replit Agent | Cloud IDE + AI Agent | Developers, educators | 50+ lenguajes |
Lovable vs Bolt.new
Bolt es más rápido. Lovable produce mejor diseño y código más limpio. Según DesignRevision:
| Métrica | Bolt | Lovable |
|---|---|---|
| Tiempo a primera render | 2 min | 3 min |
| App completa | 20 min | 35 min |
| Calidad de diseño (1-10) | 5 | 8 |
| Organización del código | Desordenado | Organizado |
Bolt ofrece terminal access y soporta múltiples frameworks (React, Next.js, Svelte, Vue, Astro), mientras Lovable solo genera React + Vite. Lovable tiene Supabase auto-provisionado y GitHub sync nativo.
Lovable vs v0 by Vercel
v0 no es un app builder, es un generador de componentes UI. No tiene backend, base de datos, autenticación ni deployment propio. Lovable construye aplicaciones full-stack completas. v0 gana en calidad de componentes individuales y soporte SSR vía Next.js.
Lovable vs Cursor
Esta es la comparación más importante: Lovable reemplaza el proceso de codificación, Cursor lo acelera. Lovable no requiere saber programar. Cursor sí, de forma obligatoria.
| Aspecto | Cursor | Lovable |
|---|---|---|
| Requiere saber codificar | Sí | No |
| Control del código | Total | IA decide |
| Lenguajes soportados | Cualquiera | JavaScript/React |
| Precio | $20/mes | $25/mes |
Lovable vs Replit Agent
Replit soporta 50+ lenguajes y puede publicar apps iOS y Android, pero su sistema de precios effort-based ha sido criticado por cargos sorpresa. Lovable es más accesible para no-técnicos y tiene precios más predecibles.
El workflow híbrido: Lovable → GitHub → Cursor
El stack más recomendado por la comunidad según Reddit r/ClaudeCode: Lovable para el 70% inicial (UI, wireframes, prototipo), GitHub sync, Cursor + Claude Code para el 30% restante (lógica compleja, producción), Supabase directo para Edge Functions y SQL complejo.
5. Integraciones y APIs: Stripe, OpenAI, Twilio, PostHog
Stripe: integración nativa
Lovable tiene soporte nativo de primera clase para Stripe (documentación oficial):
- Conectar Supabase al proyecto (obligatorio)
- Usar el formulario "Add API Key" para agregar el Stripe Secret Key
- Describir en el chat: "Create a one-time checkout for my Digital Course at $29"
- Lovable auto-genera Edge Functions, tablas con RLS y componentes UI
Para webhooks y modelos complejos de suscripción, configurar en Stripe Dashboard → Developers → Webhooks. La integración no funciona en modo preview, debe desplegarse para probar.
OpenAI y APIs de IA vía Edge Functions
El patrón estándar para cualquier API de IA (Lovable Blog): crear una Supabase Edge Function que acceda a la API key vía Deno.env.get("OPENAI_API_KEY"). El frontend llama a la Edge Function, nunca directamente a OpenAI. Esta arquitectura aplica a cualquier servicio externo: OpenAI, Anthropic, Gemini, o APIs propias.
Twilio: conector nativo desde marzo 2026
Lanzado el 18-19 de marzo de 2026 como Shared Connector (docs oficiales). Soporta SMS, MMS, llamadas de voz, WhatsApp y validación de números. Ejemplo de prompt: "Build an order tracking app that sends customers a text when their order ships".
Email: Resend vs SendGrid
Resend es el proveedor de email preferido oficialmente (docs oficiales). Ventajas: integración directa con Supabase Auth (reemplaza el límite de 4 emails/hora), hasta 3,000 contactos en tier gratuito. Limitación: no soporta drip campaigns ni secuencias automatizadas nativamente.
Analytics: PostHog
PostHog tiene integración MCP oficial con Lovable. Un usuario de Reddit confirma que obtener el tracking code y pedirle a Lovable que lo inserte en el header es todo lo que hace falta para configurarlo. PostHog incluye autocapture automático, A/B testing vía feature flags, y session replays.
Seguridad de API keys: CVE-2025-48757
Lovable bloquea ~1,200 API keys privadas de ser insertadas en código por día. Pero en 2025 se descubrió CVE-2025-48757: 170+ apps expuestas por RLS insuficiente (Superblocks). Arquitectura correcta: Frontend (React) nunca contiene keys secretas → HTTP calls → Edge Functions acceden a Secrets cifrados vía Deno.env.get() → Servicios externos.
Matriz de integraciones
| Servicio | Tipo | Facilidad | Requiere Supabase | Requiere plan pago |
|---|---|---|---|---|
| Stripe | Nativa (chat-driven) | 5/5 | Sí | No |
| Resend | Nativa (documentada) | 4/5 | Recomendado | No |
| Twilio | Nativa (Shared Connector) | 4/5 | No | No |
| OpenAI | Via Edge Functions | 4/5 | Sí | No |
| Google Auth | Nativa (Lovable Cloud) | 5/5 | No | No |
| GitHub | Nativa bidireccional | 4/5 | No | Sí |
| PostHog | MCP + script | 4/5 | No | MCP requiere paid |
| n8n | MCP prebuilt + webhooks | 3/5 | No | MCP requiere paid |
| Make | Via webhooks | 4/5 | No | No |
6. Para marketers y no-coders: casos reales con números
Landing pages: el caso de 5 páginas a $4,140 MRR
Un founder construyó 5 landing pages en Lovable para testear conceptos SaaS. Después de 90 días: la mejor trajo 840 visitantes orgánicos y 86 email signups con una tasa de conversión del 10.2%. Después de 6 meses: 23 clientes pagos, $4,140 MRR, sin marketing pago (Reddit r/lovable).
Según Lovable Landing Page Best Practices, los cambios de mayor impacto en conversión:
- Reducir campos del formulario de 11 a 4: +120% en conversiones
- Cambiar "Sign up for free" por "Trial for free": +104% en tasa de trial
- +0.1 segundos de mejora en velocidad: +8-10% en conversiones
Dashboards de analytics
Lovable genera dashboards completos con charts, conexión a Supabase, APIs externas y actualizaciones en tiempo real. Tipos documentados en Lovable Solutions: Campaign Performance, Pipeline, Social Media Insights, Business Intelligence, ROI Calculator.
Herramientas internas por departamento
Según Lovable Internal Tools, cualquier persona puede construir herramientas internas sin soporte de ingeniería: ventas (generadores de decks, calculadoras ROI, portales de enablement), marketing (dashboards de campañas, herramientas de eventos), producto (roadmaps, portales de feedback), finanzas (planificación de presupuesto, workflows de aprobación) y personas (handbooks, portales de onboarding).
Framework de validación rápida
Según Lovable: 1) landing page test con $50-100 en tráfico pagado, apuntar a 2-5% conversión, 2) prototipo funcional con solo el flujo core, sin cuentas de usuario ni pagos, 3) señales de validación fuertes: 70%+ de entrevistas con mismo dolor, conversión 3-5%+.
A/B testing: workarounds
Lovable no tiene A/B testing nativo. Dos workarounds: duplicar proyecto + VWO/Optimizely para traffic splitting, o PostHog feature flags para proyectos avanzados. Regla: con menos de 1,000 visitantes semanales, no hacer A/B testing.
Caso AppDirect: 80+ apps, $120K ahorros
AppDirect, plataforma B2B con millones de suscriptores, construyó 80+ aplicaciones con Lovable. Usuarios no técnicos de marketing generaron 200,000 líneas de código. Dos proyectos proyectan ahorros de $120,000 en el primer año (AppDirect Case Study).
"Podríamos haberle pagado a una empresa externa $80,000, y habría tardado seis meses. Con Lovable, tardó menos de un mes." - Laura Stevenson, SVP de Marketing, AppDirect
Lovable vs Webflow vs Framer vs Carrd
| Criterio | Lovable | Webflow | Framer | Carrd |
|---|---|---|---|---|
| Backend/DB | Full-stack | Solo CMS | No | No |
| Código exportable | GitHub | Propietario | No | No |
| Tiempo de setup | ~30 min | ~4 horas | ~2 horas | ~15 min |
| Costo Pro | ~$25/mes | ~$29-80/mes | ~$15-30/mes | ~$9/mes |
| Ideal para | Apps, MVPs, SaaS | Marketing + CMS | Landing premium | Páginas simples |
7. Pricing y créditos: lo que pagas, lo que consumes, lo que ocultan
Planes de precios actuales
| Plan | Precio | Créditos mensuales | Para quién |
|---|---|---|---|
| Free | $0 | 5 diarios (máx. 30/mes, sin rollover) | Exploración |
| Pro | desde $25/mes | 100/mes + 5/día (máx. 150) | Freelancers, fundadores |
| Business | desde $50/mes | 100/mes + 5/día | Equipos con SSO |
| Enterprise | Custom | Flexible | Organizaciones grandes |
Escala de precios Pro (facturación mensual):
| Créditos/mes | Precio mensual | Precio anual (~16% descuento) |
|---|---|---|
| 100 | $25 | $250 ($21/mes) |
| 200 | $50 | $500 ($42/mes) |
| 400 | $100 | $1,000 ($84/mes) |
| 1,200 | $294 | $2,940 ($245/mes) |
| 5,000 | $1,125 | $11,250 ($938/mes) |
Sistema de créditos explicado
Los créditos diarios (5/día) se resetean a medianoche UTC y no acumulan. Los créditos mensuales sí hacen rollover hasta el límite del plan. Top-ups: $15 por 50 créditos en Pro ($0.30/crédito).
Costo por tipo de acción:
| Acción | Créditos aproximados |
|---|---|
| Cambiar color de botón | ~0.50 |
| Eliminar el footer | ~0.90 |
| Agregar autenticación | ~1.20 |
| Construir landing con imágenes | ~2.00 |
| Code review en Agent Mode | Hasta 12 |
Créditos estimados por tipo de proyecto:
| Tipo de proyecto | Créditos estimados |
|---|---|
| Link-in-bio / landing simple | 10-15 |
| App skeleton básico | 15-25 |
| App con auth + dashboard | 50-100 |
| App mediana (auth + DB + APIs) | 70-90 en 2 semanas |
| Bug que no se resuelve en loops | 60+ desperdiciados |
Estrategias de optimización de créditos
Las más efectivas: 1) pre-procesar prompts con ChatGPT o Claude antes de enviarlos (un usuario pasó de 60 créditos en un bug a menos de 10), 2) "Try to Fix" es gratuito, siempre primero hasta 3 intentos, 3) Visual Editor es gratuito para mover elementos y cambiar colores, 4) Lock Files con prompts tipo "no alteres las páginas X o Y, solo cambia Z", 5) una tarea por prompt para agrupar cambios relacionados, 6) exportar a GitHub y trabajar localmente para cambios de código puro, 7) descuento estudiante 50% (Pro a $12.50/mes).
Costos ocultos de Lovable Cloud
Lovable Cloud tiene facturación separada por uso de hosting y backend. Cada workspace incluye gratis $25/mes de Cloud y $1/mes de AI, pero esto es temporal. Un usuario reportó gastar $25-35 en Lovable Cloud solo por trabajar localmente, ya que la app local llama a la misma base de datos de producción.
Sentimiento de la comunidad
"El modelo de crédito de Lovable, que opera como una caja negra, es increíblemente inteligente desde un punto de vista de negocios. Pueden ajustar los settings en cualquier momento, aumentando el costo sin que te des cuenta." - Reddit r/lovable
"Gasté créditos en un error del AI, luego más para el fix. Es como ir a un restaurante, que te traigan el plato equivocado y te cobren por él." - Reddit r/lovable
Análisis ROI
| Caso de uso | ROI vs contratar dev | Recomendación |
|---|---|---|
| Validar idea / MVP | 40-100x | Muy recomendado |
| Freelancer para clientes | 10-50x | Recomendado |
| Startup activa | 5-20x | Estrategia mixta |
| Dev técnico productivo | 2-5x | Evaluar Cursor/Claude Code |
Lovable típicamente cuesta 1-5% de lo que cuesta contratar developers, con plazos 3-5x más rápidos.
8. Limitaciones reales: lo que Lovable no puede hacer
Lo que Lovable absolutamente no puede hacer
Sin SSR/SSG (solo React SPAs con Vite, si se intenta migrar a Next.js el preview se rompe), sin apps nativas móviles (solo PWAs con limitaciones severas en iOS Safari), sin frameworks alternativos (solo React + Tailwind + Vite, no Vue, Angular, Svelte ni Next.js), sin importar proyectos existentes (solo crear desde cero o templates), sin backend independiente de Supabase por defecto.
Proyectos de mal fit
| Tipo de proyecto | Por qué es mal fit |
|---|---|
| Apps enterprise con lógica compleja | Sin control granular sobre arquitectura |
| Industrias reguladas (HIPAA, GDPR-strict) | Sin compliance hardening |
| Apps con millones de usuarios | Scalability ceiling real |
| SEO agresivo como canal principal | React SPA sin SSR |
| Apps que necesitan Bluetooth/NFC en iOS | No soportado en PWA |
Techo de ~100 usuarios concurrentes
El código generado por Lovable es excelente para hasta 100 usuarios simultáneos, pero puede acumular anti-patterns y APIs deprecadas que crean deuda técnica silenciosa. Con aproximadamente 10k vistas diarias ya se generan bottlenecks según la comunidad. La solución es el workflow híbrido con Cursor para refactoring antes de escalar.
Problemas de gestión de estado
Síntomas documentados: estado que se resetea inesperadamente, cambios que se revierten silenciosamente, modificar una funcionalidad rompe otra. La causa raíz: Lovable usa React + Zustand por defecto, sin la estructura rígida de Redux. La IA no mantiene un "mapa mental" persistente del estado entre sesiones de prompts.
Workaround: crear Project Knowledge con reglas explícitas como "Nunca usar variables globales sin Zustand. Nunca modificar [feature X] cuando trabajas en [feature Y]."
Vulnerabilidad CVE-2025-48757 (CVSS 8.26)
La vulnerabilidad más grave documentada: 170 apps con endpoints vulnerables descubiertas de 1,645 escaneadas (10.3% de tasa). Datos expuestos: emails, teléfonos, estado de pago, API keys de Google Maps y Gemini, credenciales de desarrolladores (Matt Palmer, Semafor).
En febrero 2026, un investigador encontró 16 vulnerabilidades (6 críticas) en una app destacada en la página Discover de Lovable, con 18,697 registros de usuarios accesibles sin autenticación (The Register). La prevención requiere auditar manualmente las políticas RLS antes de cualquier lanzamiento.
El "Last 30% Problem"
Lovable llega al 60-70% de un proyecto funcional. El 30-40% restante (lógica compleja, performance tuning, seguridad, edge cases) siempre requiere ingenieros humanos. La IA dice "bug resuelto" cuando el build está fallando, y pequeños cambios rompen features grandes sin warning. Este no es un defecto temporal, es una limitación estructural del enfoque de generación de código por IA.
Limitaciones PWA en iOS
| Capacidad | Android | iOS Safari |
|---|---|---|
| Push Notifications | Completo | Solo si app instalada |
| Background Sync | Sí | No soportado |
| Bluetooth | Chrome | No |
| Storage persistence | Sí | Borrado agresivo por inactividad |
Vendor lock-in: lo que puedes y no puedes exportar
El código frontend sí es portable (React estándar exportable a GitHub). El verdadero lock-in es en Lovable Cloud: no se puede exportar la base de datos completa de forma self-service, ni auth user records como entidad propia (LovableMigration.com).
Mitigación: conectar GitHub desde el día 1, usar propio proyecto Supabase (no Lovable Cloud) desde el inicio, documentar todas las integraciones antes de cualquier migración.
9. Proyectos reales: revenue, empresas y lecciones
Proyectos con revenue documentado
| Proyecto | Revenue | Detalles |
|---|---|---|
| Lumoo | €700K ARR en 9 meses | Plataforma de contenido IA para moda. 60 empresas. "100% powered by Lovable" (Lovable Blog) |
| ShiftNex | $1M ARR en 5 meses | Staffing para salud. 5,000+ usuarios |
| QuickTables | $100K+/año | Gestión de restaurantes. Dos amigos sin código |
| Hado SEO | $1,137 MRR en 45 días | Fix SEO para apps Lovable. 460 usuarios |
| Q Group | $3M en 48 horas | Edtech brasileña, plataforma premium (Lovable Blog) |
| Brickwise | YC W26 + $500K | Proptech. Demo en Lovable impresionó a Paul Graham. >$3M funding total |
Agencias y revenue extremo
- Harry Roper (Imaginary Space): $100K/mes, triplicó ingresos con agencia sobre Lovable
- Jacob Klug: $250K/mes, 22 años, fundador no técnico (YouTube)
Enterprise
| Empresa | Uso | Resultado |
|---|---|---|
| Zendesk | Rapid prototyping | "De 6 semanas a 3 horas" - Jorge Luthe, Sr. Director of Product |
| Uber AI | Prototipos interactivos | PM creó prototipo en 30 min que antes tomaba 3 meses |
| Delivery Hero | Aprobación de features | 66% más rápido (Lovable Blog) |
| ElevenLabs | Demos de ventas | 50% menos tiempo. Demo construido en taxi en 6 minutos |
| Sentry | ROI Calculator + Discovery | "The build versus buy equation has changed" |
| Atomom | CRM custom | Reemplazó Salesforce, ahorró $40,000 |
Estadísticas de la plataforma
| Métrica | Valor |
|---|---|
| Proyectos por día | 200,000+ |
| Total primer año | 25 millones+ |
| Visitas diarias a apps | 6 millones+ |
| Usuarios activos | 8 millones+ |
| ARR (marzo 2026) | $400 millones |
| Fortune 500 usando Lovable | Más del 50% |
Proyectos de impacto social
Plinq (Brasil): app de seguridad para mujeres con datos criminales públicos. NHS Healthcare Apps: 20+ apps clínicas construidas por un farmacéutico sin código, 300+ registrantes en hackathon clínico. MySafe: ganador de Hackathon Canada en menos de 24 horas. One Love Foundation: recaudó $150,000 y 200+ donantes mensuales.
10. Cuándo usar Lovable y cuándo no
Cuándo Lovable es la decisión correcta
Lovable gana de forma clara en: validación de ideas (MVP en días, costo 40-100x menor que contratar devs), landing pages con lógica (formularios, Stripe, todo en un lugar), herramientas internas sin presupuesto de ingeniería, prototipos para ventas o inversión que funcionan como producto real, freelancers y agencias (ROI de 10-50x demostrado), y apps con menos de 100 usuarios simultáneos.
La regla práctica: si el proyecto puede vivir 6-12 meses sin necesitar SSR, apps nativas o compliance estricto, construirlo ahí es la decisión correcta.
Cuándo Lovable no es la decisión correcta
SEO como canal principal (CSR sin SSR es un handicap real, necesitas Next.js o similar), apps que van a escalar a 10k+ usuarios activos (deuda técnica silenciosa que se vuelve cara), proyectos con lógica de negocio compleja (el Last 30% Problem no desaparece), industrias reguladas (HIPAA, GDPR-strict, finanzas con compliance específico), apps móviles nativas (limitaciones PWA en iOS son reales: push notifications, Bluetooth, storage persistente), y equipos técnicos productivos (Cursor + Claude Code probablemente genera más valor por dólar).
El stack híbrido: la forma inteligente de usarlo
La mayoría de los builders que obtienen mejores resultados no usa Lovable en exclusiva. El flujo estándar: diseñar el schema con ChatGPT o Claude antes de abrir Lovable, conectar Supabase externo (no Lovable Cloud) y GitHub desde el primer día, construir el 70% en Lovable (UI, flujos, integraciones básicas), migrar a Cursor o Claude Code para el 30% restante (lógica compleja, optimizaciones, seguridad), auditar RLS antes de lanzar, hacer deploy en Netlify o Cloudflare Pages para mayor control.
Es el workflow que usan las agencias que generan $100K-$250K/mes con Lovable. No es una solución de nicho, es el camino probado.
Checklist antes de empezar
- ¿Necesito SSR para SEO? Si sí, considera otra herramienta
- ¿Mi app necesitará más de 100 usuarios simultáneos en 12 meses? Si probablemente sí, planifica la migración desde el inicio
- ¿Hay compliance regulatorio obligatorio? Si sí, Lovable solo para el prototipo
- ¿Conecté Supabase externo antes de construir features? Si no, hazlo ahora
- ¿Tengo GitHub conectado desde el primer día? Si no, empiézalo hoy
- ¿Audité las políticas RLS antes de lanzar? Si no, no lances
Lovable es la herramienta más poderosa para validar y construir rápido en 2025-2026. Las limitaciones son reales pero predecibles. El error más común no es elegir Lovable, es usarlo sin entender sus límites.
© 2026 Andres Ospina
