Lovable + Supabase per operations ecommerce: app interne in giorni invece di mesi

Negli ultimi due anni la domanda che mi arriva più spesso dai founder ecommerce è la stessa, declinata in cento modi: “abbiamo bisogno di un’app interna per gestire X, ma sviluppo software classico è troppo lento e troppo caro, e i tool no-code non scalano”. X può essere un CRM custom per il sourcing, una pipeline operativa con stage che non corrispondono a nessun template Shopify, un portale per partner logistici, un’inbox unificata multi-mittente. La risposta che do oggi, dopo aver costruito sistemi del genere in produzione, è quasi sempre: Lovable per il front-end e Supabase per il back-end. Questo articolo spiega quando questa combinazione batte le alternative, e dove sono i tradeoff veri.

Cosa intendo per “app interne” in ecommerce ops

Non sto parlando dello store. Lo store è Shopify, WooCommerce o equivalente, e in quasi tutti i casi va lasciato dov’è. Sto parlando degli strumenti che il team operations usa ogni giorno e che lo store non copre: il sourcing dei prodotti (specialmente in modelli consignment o resale), la valutazione delle inquiries inbound, la gestione dei photo shoot, la riconciliazione contabile, i portali B2B per seller, brand e logistic partner, le inbox condivise.

In un progetto luxury furniture resale su cui ho lavorato, il sistema operativo interno conteneva circa settanta pagine, oltre cento edge functions, una pipeline inbound a dieci stage, un’inbox unificata che aggregava più mailbox, un sistema di @-mention con fan-out verso email e notifiche in-app, tre portali separati (seller, brand, logistic), un UI per gestire i cron job senza toccare il database, e un chatbot RAG su pgvector con knowledge base costruita da PDF e Word interni. Tutto questo su un singolo stack Lovable + Supabase, costruito da una persona in qualche mese.

Lo stesso sistema su Retool sarebbe stato fattibile ma costoso (licenze per utente che scalano male), su Internal o Glide avrebbe lottato sulla parte di logica server, su sviluppo classico React + Node sarebbe richiesto un team di tre persone per nove mesi.

Dove Lovable + Supabase batte le alternative

Tre pattern in particolare giustificano la scelta.

Edge functions in Deno per la logica di dominio. Tutto ciò che è “regola di business non triviale” — un rule engine per task automation, un dispatcher centralizzato verso Xero o QuickBooks, un parser di @-mention con fan-out, un orchestrator per pull batch di foto da Google Drive — sta in edge functions versionate accanto al codice front-end. Niente Zapier dentro l’app, niente workflow visivi che diventano illeggibili quando crescono. Codice TypeScript con tipi condivisi tra client e server.

pg_cron per scheduling nativo. I cron job vivono nel database, non in un’infrastruttura separata. Sweep di stale inquiries ogni notte, advance di settlement Shopify il primo del mese, auto-release di prenotazioni scadute ogni ora, backup notturno delle tabelle critiche, prune degli audit log oltre i sei mesi: tutto in pg_cron. Per il team operations è anche più semplice — esiste una pagina nell’app, “Manage Cron Jobs”, che permette di vedere e modificare gli schedule senza aprire SQL.

Row-Level Security per multi-portale. Tre portali diversi (seller, brand, logistic), ciascuno con i propri utenti, che vedono solo i propri dati, sullo stesso database condiviso con la console interna. RLS gestisce la separazione a livello di riga, non di applicazione. Significa che lo stesso schema serve tutti, e una nuova permission si aggiunge cambiando una policy SQL, non una libreria di permessi a livello applicativo. Il pattern anti-enumeration (un seller non deve neanche poter dedurre che un altro seller esiste) si implementa con policy che filtrano ogni SELECT a monte.

A questi tre aggiungerei i signed upload URL di Supabase Storage: il team operations carica fatture, foto, documenti direttamente nell’app, e i file vivono accanto al record di business a cui appartengono.

Il tradeoff vs Retool e Internal

Retool è più veloce per costruire una CRUD UI sopra un database esistente. Se hai già un Postgres pulito e ti serve un’interfaccia admin in due settimane, Retool vince. Internal è simile, e lo stesso vale per Airtable + Softr.

Lovable + Supabase vince quando l’app interna è il sistema operativo dell’azienda, non un’interfaccia secondaria. Quando deve girare logica di dominio complessa, esporre portali esterni con sicurezza seria, integrare cinque o sei API esterne, e il modello pricing per-utente di Retool diventa insostenibile.

Il costo da pagare è che si scrive codice. Edge functions in TypeScript, policy SQL, migration. Chi cerca puro “drag and drop” non è il pubblico giusto. Chi accetta di leggere e modificare TypeScript ben strutturato guadagna ordini di grandezza in flessibilità.

Il pattern di produzione che porto sempre

Quando inizio un progetto Lovable + Supabase per ops ecommerce, la struttura che imposto da subito è questa:

1. Schema con RLS abilitato di default. Nessuna tabella è accessibile senza una policy esplicita. Si comincia restrittivi, si apre dove serve.
2. Edge functions tipizzate. Una funzione = una responsabilità. Niente “mega-function” che fa cinque cose. I tipi sono condivisi tra front-end e back-end via TypeScript shared types.
3. pg_cron schedulato dal giorno uno. Anche se all’inizio non serve, la presenza dei cron forza a pensare a cosa va automatizzato e cosa no.
4. Audit log per le azioni sensibili. Ogni edit di un dato finance, ogni push verso Xero, ogni invio di email verso un esterno passa per un audit log queryabile. Quando qualcosa va storto, è la prima tabella che si guarda.
5. Dispatcher centralizzati per le integrazioni esterne. Tutto ciò che parla con Xero passa per uno “Xero Push Dispatcher”. Tutto ciò che parla con Resend passa per un “Mail Dispatcher”. Cambiare provider domani è una funzione da riscrivere, non venti.

La metrica realistica

Il numero che conta per i founder che mi chiamano è il time-to-production. Un sistema operativo interno paragonabile a quello descritto sopra, fatto con sviluppo classico, richiede sei-nove mesi e un team di due-tre persone. Con Lovable + Supabase, l’MVP funzionante (pipeline inbound, CRM, portale seller, sync Shopify bidirezionale) è arrivato in produzione in circa due mesi di lavoro full-time di una persona. Le estensioni successive — il chatbot RAG, l’inbox unificata, l’AI Library per versionare i prompt, gli ulteriori portali — si sono aggiunte una per settimana o quasi, una volta che le fondamenta erano in piedi.

Non significa che chiunque possa replicare quel ritmo. Significa che lo stack abilita un ritmo che con altre tecnologie non sarebbe stato possibile.

Quando non sceglierlo

Se l’app interna è un’unica dashboard di consultazione sopra un Postgres esistente, Retool è più veloce. Se il team non ha nessuno che possa leggere TypeScript, il rischio operativo di Lovable cresce. Se l’azienda è enterprise con compliance pesante che richiede on-premise o sovereign cloud specifico, Supabase managed non basta. Se i flussi sono interamente “trigger-azione” semplici tra SaaS, Make.com o n8n risolvono con meno superficie d’attacco.

Negli altri casi — ed è la maggioranza dei progetti operations ecommerce che vedo — Lovable + Supabase è oggi la combinazione che fa di più, in meno tempo, con meno costo ricorrente.