Errori tecnici nella gestione di 16 prodotti su Lovable e Supabase
Gestiamo 16 prodotti in Inithouse. Usiamo Lovable e Supabase per tutti. Un unico team gestisce tutto. Sembra un'ottima idea, finché non ti ritrovi con 16 domini personalizzati, 16 progetti Supabase e 16 set di edge functions.
Abbiamo commesso errori che ci sono costati tempo. Ecco i cinque più grandi errori tecnici e le nostre soluzioni.
- Schemi del database incoerenti
I nostri primi tre prodotti utilizzavano nomi di tabella diversi per gli stessi dati. Un progetto usava page_views per l'analisi dei dati. Un altro usava analytics_events. Questo rendeva impossibile scrivere codice condiviso. Un compito che avrebbe dovuto richiedere un pomeriggio ha richiesto due settimane.
La soluzione: Abbiamo creato un template di migrazione condiviso. Ogni nuovo prodotto riceve le stesse tabelle base per analytics, post del blog e autenticazione. Abbiamo aggiornato i vecchi progetti durante le settimane meno intense. Ora, aggiungere un endpoint di monitoraggio richiede 20 minuti invece di un giorno.
- Domini personalizzati non funzionanti
Lovable ti permette di collegare domini personalizzati. A volte il deploy ha successo ma la verifica DNS fallisce. L'URL di anteprima funziona, ma il dominio live mostra una pagina bianca. Abbiamo perso tre giorni di traffico perché non avevamo controllato l'URL live.
La soluzione: Utilizziamo una checklist post-pubblicazione. Apriamo ogni dominio live in una finestra in incognito per verificarlo. Abbiamo anche aggiunto un controllo dell'uptime che invia una notifica su Slack se un dominio fallisce.
- Visibilità dei dati frammentata
Non riuscivamo a vedere come stesse andando l'intero portfolio senza aprire dashboard separate per ogni prodotto. Stavamo procedendo alla cieca.
La soluzione: Abbiamo distribuito un endpoint API per le statistiche in ogni progetto Supabase. Ogni prodotto invia metriche chiave come utenti e iscrizioni in un formato standard. Un singolo script raccoglie questi dati in un'unica dashboard.
- Copia e incolla di componenti
Solitamente copiavamo componenti React da un progetto all'altro. Questi componenti portavano con sé vecchie assunzioni. Una card dei prezzi di un prodotto non funzionava in un altro perché si aspettava un flusso di pagamento differente. Abbiamo passato giorni a fare il debugging di questi bug fantasma.
La soluzione: Abbiamo smesso di fare copia e incolla. Manteniamo un documento di pattern dei componenti. Chiediamo a Lovable di costruire un nuovo componente basato su questi pattern. È più lento da configurare, ma molto più facile da mantenere.
- Usare la cronologia della chat come documentazione
Ci affidavamo alla cronologia della chat di Lovable per ricordare le decisioni tecniche. I log delle chat sono disordinati. Mescolano modifiche riuscite con tentativi falliti. Trovare il motivo specifico di una modifica in un thread lungo è difficile.
La soluzione: Abbiamo spostato la registrazione delle decisioni su Linear. Scriviamo una riga su Linear spiegando cosa è cambiato e perché. La chat di Lovable serve per l'esecuzione. Linear serve per le decisioni.
La lezione è semplice. Non trattare 16 prodotti come 16 progetti separati. Trattali come un unico portfolio. Standardizza i tuoi template e monitora tutto da un unico posto.
Source: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh
Optional learning community: https://t.me/GyaanSetuAi