Errores técnicos al gestionar 16 productos en Lovable y Supabase
Gestionamos 16 productos en Inithouse. Utilizamos Lovable y Supabase para todos ellos. Un solo equipo lo gestiona todo. Esto suena bien hasta que te enfrentas a 16 dominios personalizados, 16 proyectos de Supabase y 16 conjuntos de edge functions.
Cometimos errores que nos costaron tiempo. Estos son los cinco errores técnicos más importantes y nuestras soluciones.
- Esquemas de base de datos inconsistentes
Nuestros tres primeros productos utilizaban nombres de tablas diferentes para los mismos datos. Un proyecto usaba page_views para analíticas. Otro usaba analytics_events. Esto hacía imposible escribir código compartido. Una tarea que debería haber tomado una tarde nos llevó dos semanas.
La solución: Creamos una plantilla de migración compartida. Cada nuevo producto recibe las mismas tablas base para analíticas, publicaciones de blog y autenticación. Adaptamos los proyectos antiguos durante las semanas de menor actividad. Ahora, añadir un endpoint de monitorización toma 20 minutos en lugar de un día.
- Dominios personalizados rotos
Lovable te permite conectar dominios personalizados. A veces el despliegue tiene éxito pero la verificación de DNS falla. La URL de vista previa funciona, pero el dominio en vivo muestra una página en blanco. Perdimos tres días de tráfico porque no comprobamos la URL en vivo.
La solución: Utilizamos una lista de verificación post-publicación. Abrimos cada dominio en vivo en una ventana de incógnito para verificarlo. También añadimos un control de tiempo de actividad (uptime check) que envía una notificación a Slack si un dominio falla.
- Visibilidad de datos fragmentada
No podíamos ver el rendimiento de todo nuestro portafolio sin abrir dashboards separados para cada producto. Estábamos volando a ciegas.
La solución: Desplegamos un endpoint de API de estadísticas en cada proyecto de Supabase. Cada producto envía métricas clave como usuarios y registros en un formato estándar. Un único script extrae estos datos en un solo dashboard.
- Copiar y pegar componentes
Solíamos copiar componentes de React de un proyecto a otro. Estos componentes arrastraban suposiciones antiguas. Una tarjeta de precios de un producto fallaba en otro porque esperaba un flujo de pago diferente. Pasamos días depurando estos errores fantasma.
La solución: Dejamos de copiar y pegar. Mantenemos un documento de patrones de componentes. Le indicamos a Lovable que construya un componente nuevo basado en estos patrones. Es más lento de configurar, pero mucho más fácil de mantener.
- Usar el historial del chat como documentación
Dependíamos del historial del chat de Lovable para recordar decisiones técnicas. Los registros de chat son caóticos. Mezclan cambios exitosos con intentos fallidos. Encontrar una razón específica para un cambio en un hilo largo es difícil.
La solución: Trasladamos el registro de decisiones a Linear. Escribimos una línea en Linear explicando qué cambió y por qué. El chat de Lovable es para la ejecución. Linear es para las decisiones.
La lección es sencilla. No trates 16 productos como 16 proyectos separados. Trátalos como un único portafolio. Estandariza tus plantillas y monitoriza todo desde un solo lugar.
Fuente: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh
Comunidad de aprendizaje opcional: https://t.me/GyaanSetuAi