Erros Técnicos ao Gerenciar 16 Produtos no Lovable e Supabase

Nós gerenciamos 16 produtos na Inithouse. Usamos Lovable e Supabase para todos eles. Uma única equipe gerencia tudo. Isso parece bom até você enfrentar 16 domínios personalizados, 16 projetos no Supabase e 16 conjuntos de edge functions.

Cometemos erros que nos custaram tempo. Aqui estão os cinco maiores erros técnicos e nossas soluções.

1. Esquemas de banco de dados inconsistentes

Nossos primeiros três produtos usavam nomes de tabelas diferentes para os mesmos dados. Um projeto usava page_views para analytics. Outro usava analytics_events. Isso tornava impossível escrever código compartilhado. Uma tarefa que deveria levar uma tarde levou duas semanas.

A solução: Criamos um template de migração compartilhado. Cada novo produto recebe as mesmas tabelas base para analytics, posts de blog e auth. Adaptamos os projetos antigos durante semanas mais tranquilas. Agora, adicionar um endpoint de monitoramento leva 20 minutos em vez de um dia.

2. Domínios personalizados quebrados

O Lovable permite conectar domínios personalizados. Às vezes, o deploy é bem-sucedido, mas a verificação de DNS falha. A URL de preview funciona, mas o domínio ao vivo mostra uma página em branco. Perdemos três dias de tráfego porque não verificamos a URL ao vivo.

A solução: Usamos um checklist pós-publicação. Abrimos cada domínio ao vivo em uma janela anônima para verificá-lo. Também adicionamos uma verificação de uptime que envia um alerta para o Slack se um domínio falhar.

3. Visibilidade de dados fragmentada

Não conseguíamos ver o desempenho de todo o nosso portfólio sem abrir dashboards separados para cada produto. Estávamos voando às cegas.

A solução: Implementamos um endpoint de API de estatísticas em cada projeto do Supabase. Cada produto envia métricas importantes, como usuários e cadastros, em um formato padrão. Um único script puxa esses dados para um único dashboard.

4. Copiar e colar componentes

Costumávamos copiar componentes React de um projeto para outro. Esses componentes traziam suposições antigas. Um card de preços de um produto falhava em outro porque esperava um fluxo de pagamento diferente. Passamos dias depurando esses bugs fantasmas.

A solução: Paramos de copiar e colar. Mantemos um documento de padrões de componentes. Instruímos o Lovable a construir um componente novo baseado nesses padrões. É mais demorado para configurar, mas muito mais fácil de manter.

5. Usar o histórico do chat como documentação

Dependíamos do histórico de chat do Lovable para lembrar de decisões técnicas. Logs de chat são bagunçados. Eles misturam mudanças bem-sucedidas com tentativas falhas. Encontrar um motivo específico para uma mudança em uma thread longa é difícil.

A solução: Movemos o registro de decisões para o Linear. Escrevemos uma linha no Linear explicando o que mudou e por quê. O chat do Lovable é para execução. O Linear é para decisões.

A lição é simples. Não trate 16 produtos como 16 projetos separados. Trate-os como um único portfólio. Padronize seus templates e monitore tudo de um só lugar.

Fonte: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh

Comunidade de aprendizado opcional: https://t.me/GyaanSetuAi