De Lovable a producción: qué pasa después del prototipo

Lovable te llevó de la idea a una app funcional en horas. Describiste lo que querías, viste cómo generaba una app React completa con un backend de Supabase, y al final del día tenías una demo que parecía construida por un equipo de tres personas.

Se la mostraste a la gente. Se registraron. Alguien incluso pagó.

Entonces llega el momento que todo constructor de Lovable enfrenta: la brecha entre "funciona en el día de la demo" y "funciona en producción". El prototipo es real — pero producción es un juego completamente diferente.

Esto no es una crítica a Lovable. Lovable hace exactamente lo que promete: construye prototipos funcionales a una velocidad extraordinaria. Pero los prototipos están optimizados para "¿funciona?" y producción está optimizada para "¿funciona de manera confiable, asequible, segura y a escala?"

Son preguntas diferentes, y requieren respuestas diferentes.

Las 5 brechas entre el prototipo de Lovable y la app en producción

Después de hablar con docenas de constructores que han llevado prototipos de Lovable a producción, las mismas cinco brechas aparecen cada vez. Algunas son obvias. Algunas no se manifiestan hasta que tienes usuarios de pago.

1. Escalado de costos de IA — Tus funciones de IA se vuelven caras a medida que crece el uso
2. Confiabilidad bajo carga — Límites de tasa de API, caídas y timeouts rompen la experiencia del usuario
3. Datos y privacidad — Los datos de usuario que fluyen a través de APIs de terceros crean riesgo de cumplimiento
4. Rendimiento a escala — Los viajes de ida y vuelta de API agregan latencia que los usuarios perciben
5. Dependencia de proveedores — Las funciones principales de tu app dependen de una empresa cuyo precio y disponibilidad no controlas

Repasemos cada una y hablemos de qué hacer al respecto.

Brecha 1: escalado de costos de IA

Esta es la brecha más común y generalmente la primera que duele.

Tu app de Lovable tiene funciones de IA — un chatbot, un resumidor, un motor de recomendaciones, una capa de clasificación. Durante la creación del prototipo, estas funciones llaman a la API de OpenAI y los costos son invisibles. Unos pocos dólares al mes como máximo.

Pero cada interacción de usuario que activa una función de IA cuesta tokens. Y los costos por token escalan linealmente con los usuarios.

Esos $12 con 100 usuarios se sentían como nada. Esos $620 con 5,000 usuarios se comen tu margen. Esos $3,000 con 25,000 usuarios podrían superar todos tus ingresos.

La solución no es eliminar las funciones de IA — probablemente son la razón por la que los usuarios aman tu app. La solución es dejar de pagar por token.

La solución para producción: Ajusta un modelo pequeño (7B parámetros) para tu caso de uso específico y despliégalo localmente. Tus costos de IA se convierten en un fijo de $44.50/mes ($14.50 por Ertas + $30 por un VPS) sin importar la cantidad de usuarios. Cubriremos esto en detalle en la sección de arquitectura más abajo.

Brecha 2: confiabilidad bajo carga

Durante la creación del prototipo, las llamadas API a OpenAI generalmente funcionan sin problemas. Pero en producción, necesitas planificar para cuando no funcionen.

Límites de tasa. OpenAI impone límites de tasa basados en el nivel de tu cuenta. Si tu app genera una ráfaga de solicitudes — digamos, 50 usuarios activando la función de IA en el mismo minuto — obtendrás errores 429. Tus usuarios ven "algo salió mal".

Caídas de API. OpenAI ha tenido múltiples caídas importantes en el último año. Cuando OpenAI se cae, cada función de IA en tu app se cae. No tienes respaldo, no tienes redundancia y no tienes control sobre cuándo vuelve.

Manejo de timeouts. Las respuestas de GPT-4 pueden tardar 3-10 segundos. Bajo carga pesada, pueden tardar 15-30 segundos. Tu frontend generado por Lovable probablemente no tiene manejo sofisticado de timeouts, lógica de reintentos o estados de carga para estos escenarios.

La solución para producción: Un modelo ejecutándose localmente en tu propia infraestructura no tiene límites de tasa (tú controlas el rendimiento), no se cae cuando OpenAI tiene un incidente, y típicamente responde en 0.5-2 segundos para un modelo 7B ajustado. También puedes agregar un respaldo: intentar primero con el modelo local, y recurrir a OpenAI si el modelo local no está disponible.

Así se ve esa diferencia de confiabilidad en la práctica:

Brecha 3: datos y privacidad

Esta te toma por sorpresa.

Cada vez que tu app envía la entrada de un usuario a la API de OpenAI, esos datos viajan a través de la infraestructura de OpenAI. Para una demo de prototipo, a nadie le importa. Para una app en producción con usuarios de pago, esto crea problemas reales:

Cumplimiento de GDPR. Si tienes usuarios europeos, estás enviando sus datos personales a un tercero con sede en EE.UU. Eso activa requisitos de acuerdo de procesamiento de datos, obligaciones de aviso de privacidad y potencialmente restricciones de transferencia transfronteriza. La superficie legal es significativa.

Confianza del usuario. Tu política de privacidad probablemente no menciona que las entradas de los usuarios son procesadas por OpenAI. Una vez que los usuarios se enteren (y eventualmente lo harán), algunos se irán. Particularmente en verticales sensibles como salud, legal, finanzas o recursos humanos.

Retención de datos. Las políticas de retención de datos de OpenAI han cambiado múltiples veces. ¿Qué pasa con los datos del usuario después de ser procesados? No controlas completamente la respuesta.

Cumplimiento industrial. Si estás construyendo para salud (HIPAA), finanzas (SOC 2) o gobierno (FedRAMP), enviar datos a APIs externas puede ser un punto de partida no viable. Algunas empresas ni siquiera evaluarán tu producto si el procesamiento de IA ocurre fuera de sus instalaciones.

La solución para producción: Cuando tu modelo de IA se ejecuta localmente, los datos del usuario nunca salen de tu infraestructura. No hay procesador de datos de terceros del que preocuparse. Tu discurso de privacidad se vuelve simple: "Tus datos permanecen en nuestros servidores. Punto." Eso es una ventaja competitiva en cada industria regulada y una señal de confianza para cada usuario.

Brecha 4: rendimiento a escala

Los viajes de ida y vuelta de API agregan latencia que se acumula a medida que tu app crece.

Una función de IA típica en una app de Lovable funciona así:

1. El usuario activa una acción (500ms para que la solicitud llegue a tu servidor)
2. Tu servidor envía la solicitud a OpenAI (100-200ms de latencia de red)
3. OpenAI procesa la solicitud (2,000-8,000ms para GPT-4)
4. La respuesta viaja de vuelta a tu servidor (100-200ms)
5. Tu servidor envía la respuesta al usuario (500ms)

Total: 3-9 segundos para una sola interacción de IA. Los usuarios notan cualquier cosa por encima de 2 segundos. A más de 5 segundos, empiezan a preguntarse si la app está rota.

Y esto empeora bajo carga. Cuando los servidores de OpenAI están ocupados, ese tiempo de procesamiento de 2-8 segundos puede estirarse a 15-30 segundos. Tu cola se acumula. Los usuarios empiezan a hacer clic furiosamente. Las tasas de error se disparan.

La solución para producción: Un modelo local ajustado elimina por completo el viaje de ida y vuelta a OpenAI. El procesamiento ocurre en el mismo servidor (o VPS cercano) que tu app. Tiempos de respuesta típicos para un modelo 7B en un VPS decente:

Tus usuarios experimentan funciones de IA que se sienten instantáneas en lugar de lentas. Eso es una mejora significativa de UX que afecta directamente la retención.

Brecha 5: dependencia de proveedores

Las funciones de IA de tu prototipo de Lovable dependen enteramente de OpenAI. Eso significa:

• Los cambios de precio te afectan inmediatamente. Cuando OpenAI sube los precios (o cambia su modelo de precios), tus márgenes cambian de la noche a la mañana. No puedes negociar. No puedes cambiar sin un trabajo significativo.

• La depreciación de modelos rompe tu app. OpenAI ha depreciado múltiples versiones de modelos. Cuando la versión de tu modelo llega al fin de vida, tienes que migrar — y la nueva versión podría comportarse diferente, rompiendo tus prompts y las expectativas de tus usuarios.

• La disponibilidad de funciones no está garantizada. OpenAI puede cambiar límites de tasa, políticas de uso o acceso a funciones en cualquier momento. Startups han tenido acceso a API restringido o revocado con aviso mínimo.

• No puedes diferenciarte. Cada app que usa GPT-4 con el mismo prompt obtiene aproximadamente la misma salida. Tus funciones de IA no son una ventaja competitiva — son un commodity. Cualquier competidor puede replicarlas copiando tu prompt.

La solución para producción: Un modelo ajustado que posees elimina la dependencia de proveedores por completo. Tú controlas el modelo, los datos de entrenamiento, el despliegue y los precios. Si quieres actualizar el modelo, reentrenar en tu calendario. Si quieres cambiar de modelo base (de Qwen a Llama, por ejemplo), puedes — tus datos de entrenamiento permanecen iguales.

Más importante aún, un modelo ajustado es tu propiedad intelectual. Codifica tu experiencia en el dominio, los patrones de tus usuarios y los comportamientos específicos de tu producto. Eso es una ventaja competitiva. Ningún competidor puede replicarla llamando a la misma API.

La arquitectura de IA lista para producción

Así se ve un stack de IA listo para producción para una app de Lovable:

┌────────────────────────────────────┐
│  Tu app de Lovable (Vercel/Netlify)│
│  React + Supabase                  │
└──────────────┬─────────────────────┘
               │
               ▼
┌────────────────────────────────────┐
│  Tu VPS ($30/mes)                  │
│  ┌──────────┐  ┌────────────────┐  │
│  │  Ollama   │  │  Modelo        │  │
│  │  Server   │──│  ajustado(GGUF)│  │
│  └──────────┘  └────────────────┘  │
└────────────────────────────────────┘

El cambio respecto a tu prototipo es quirúrgico:

1. El frontend de tu app permanece exactamente igual (fue construido por Lovable — no lo toques)
2. Tu ruta API que llamaba a OpenAI ahora llama a tu endpoint de Ollama
3. Todo lo demás — autenticación, base de datos, lógica de negocio — permanece sin cambios

El cambio de la llamada API es típicamente una modificación de una línea:

// Antes (prototipo)
const endpoint = "https://api.openai.com/v1/chat/completions"

// Después (producción)
const endpoint = "http://tu-ip-vps:11434/v1/chat/completions"

Ollama soporta el formato de API compatible con OpenAI, así que el cuerpo de tu solicitud, headers y parseo de respuesta permanecen iguales. Lo único que cambia es la URL.

Cómo Ertas cierra la brecha

La brecha entre "sé que debería ajustar un modelo" y "tengo un modelo ajustado ejecutándose en producción" es donde la mayoría de los constructores se quedan atascados. El fine-tuning tradicionalmente requiere:

• Conocimiento de ingeniería de ML
• Acceso a GPU
• Scripts de Python
• Ajuste de hiperparámetros
• Pipelines de evaluación de modelos
• Herramientas de conversión de formato

Ertas elimina todo eso. Si puedes exportar tus registros de API y subir un archivo, puedes ajustar un modelo.

Aquí está el flujo de trabajo para un constructor de Lovable que va del prototipo a producción:

1. Exporta tus registros de API de OpenAI de las últimas semanas. Necesitas los prompts de entrada y las respuestas de la IA como pares. 200-500 ejemplos como mínimo.

2. Sube a Ertas Studio. Arrastra y suelta tu archivo JSONL o CSV. Ertas valida tus datos y te muestra una vista previa.

3. Elige un modelo base. Para la mayoría de las apps de Lovable, Qwen 2.5 7B es la opción correcta — es rápido, preciso en tareas específicas y se ejecuta en hardware asequible.

4. Entrena. Haz clic en el botón. Ertas maneja la configuración de LoRA, la selección de tasa de aprendizaje, el conteo de épocas y la división de validación. El entrenamiento toma 15-45 minutos.

5. Evalúa. Ertas te muestra comparaciones lado a lado: la salida de tu modelo ajustado vs. la salida original de GPT-4 para tus casos de prueba. Puedes ver inmediatamente si la calidad está donde necesita estar.

6. Exporta a GGUF. Un clic. Descarga un único archivo. Ese es tu modelo de producción.

7. Despliega con Ollama. Carga el archivo GGUF en tu VPS, inicia Ollama, actualiza tu endpoint de API. Listo.

Todo el proceso — desde exportar registros de API hasta tener un modelo local listo para producción — toma unas pocas horas de tu tiempo distribuidas en un día o dos (la mayor parte es esperar a que el entrenamiento se complete).

La checklist de producción

Antes de poner en marcha tu IA ejecutándose localmente, revisa esta checklist:

Infraestructura

• VPS aprovisionado con mínimo 4 vCPU, 16GB RAM
• Ollama instalado y configurado para iniciar con el arranque
• Modelo cargado y respondiendo a solicitudes de prueba
• Endpoint de Ollama asegurado (reglas de firewall, o solo red interna)
• Monitoreo configurado para VPS (CPU, memoria, disco)

Validación de calidad

• Probadas más de 50 entradas reales contra tanto OpenAI como el modelo local
• La calidad de salida iguala o supera a OpenAI para tu caso de uso
• Casos extremos manejados (entradas vacías, entradas muy largas, formatos inesperados)
• El formato de respuesta coincide con lo que tu app espera (estructura JSON, etc.)

Cambios en la aplicación

• Endpoint de API actualizado para apuntar a Ollama
• Manejo de timeouts configurado (el modelo local es más rápido, pero establece límites razonables)
• Manejo de errores para la indisponibilidad del modelo (reiniciar Ollama, o recurrir a OpenAI)
• Parseo de respuesta actualizado si es necesario (formato Ollama vs. formato OpenAI)

Monitoreo e iteración

• Registro de entradas y salidas de IA para reentrenamiento futuro
• Monitoreo de tasa de errores en endpoints de IA
• Recolección de feedback de usuarios sobre la calidad de la IA
• Plan para reentrenamiento mensual del modelo a medida que recopilas más datos

Seguimiento de costos

• Clave de API de OpenAI eliminada o degradada a solo respaldo
• Costo del VPS registrado en tu presupuesto operativo
• Suscripción de Ertas activa para fine-tuning continuo
• Costos de API del mes anterior documentados para comparación

Los números que importan

Aquí está el antes y después para una app típica de Lovable que va del prototipo a producción:

La versión de producción cuesta 93% menos, responde 3-5x más rápido, mantiene los datos privados y tiene costos mensuales predecibles. Eso no es una optimización — es un modelo de negocio diferente.

Cuándo hacer el cambio

No necesitas esperar hasta que los costos duelan. El mejor momento para cambiar es cuando tienes suficientes datos para ajustar un modelo — típicamente después de 200-500 interacciones reales de usuarios con tus funciones de IA.

Algunos constructores hacen el cambio con 100 usuarios. Algunos esperan hasta 1,000. Cuanto antes cambies, más dinero ahorras — pero también necesitas suficientes datos para un buen modelo ajustado.

Una regla general razonable: si tu factura de OpenAI supera los $50/mes y va en aumento, es el momento. El costo de configuración es unas pocas horas de trabajo, y el período de recuperación es generalmente menor a un mes.

Tu prototipo de Lovable demostró que la idea funciona. Ahora haz que funcione a escala.

---

Lectura adicional

• Tu app vibe-coded llegó a 10K usuarios. Ahora tu factura de IA es $3K/mes. — El desglose completo de costos para apps que escalan con precios de IA por token.
• IA auto-alojada para apps indie — Por qué los modelos auto-alojados son la opción correcta para desarrolladores indie y equipos pequeños.
• De Cursor a producción: IA sin dependencia de proveedores — Una guía paralela para constructores que usan Cursor en lugar de Lovable.