Architettura — NIE Experts Spain

Scelta 1 — dove vivono i dati

Notion + Supabase, ibrido

La domanda non è "Notion o Supabase". È che un solo strumento dovrebbe fare due lavori diversi, e quei due lavori hanno bisogni opposti.

Livello	Cosa fa	Strumento giusto
Umano	Quello che tu e il partner guardate e modificate: ordini, stato pratiche, colonne appuntamenti	Notion — visivo, già in uso, CRM già pronto
Macchina	Quello che i workflow leggono e scrivono ad alta frequenza: stati, token, deduplica, operazioni in parallelo	Supabase — vincoli, transazioni, trigger istantanei

La regola

Una sola regola

Supabase è ciò che leggono e scrivono i workflow. Notion è ciò che leggono e scrivono le persone. n8n li tiene sincronizzati.

CRM ordini → resta su Notion esattamente com'è. Non si tocca quello che già funziona.
Pratiche → Supabase. Fonte di verità per stati, token e deduplica.
Visibilità → n8n sincronizza Supabase verso una vista Notion: tu e il partner vedete tutto in Notion.
Vista partner → il partner modifica le poche colonne che gli servono in Notion, n8n riporta quei campi su Supabase.

Perché non solo Notion

Tre motivi concreti, tutti legati a cose che hai chiesto tu:

Idempotenza. "Webhook duplicati non creano doppi PDF, doppie email, doppie righe" richiede un controllo atomico. Notion fa solo leggi-poi-scrivi, che in caso di retry può comunque duplicare. Supabase lo impedisce con un vincolo di unicità, gratis.
Rimozione per cambio stato. Hai chiesto che la revoca guide parta dal cambio stato, non da un timer. Su Notion il trigger è a polling (un timer travestito). Supabase scatena l'evento all'istante.
Picco di lancio. Notion ha limiti di frequenza (~3 richieste/sec). Un gruppo da 4 con apertura pratiche in parallelo genera raffiche che vengono frenate proprio nel momento peggiore.

Il vantaggio per te: continui a lavorare in Notion esattamente come oggi e non apri mai Supabase. Supabase è il motore invisibile sotto, quello che fa sì che nulla si duplichi o si rompa il giorno del lancio.

Scelta 2 — i form

Due form, due strumenti

Hai due form con bisogni opposti. Usare lo strumento giusto per ciascuno è più solido che forzarne uno solo a fare tutto.

Fase 1 — raccolta gruppo → Tally

È il form ricco di logica (1–4 persone, capo-famiglia, checkbox appuntamento prioritario, parametri URL) ma non sensibile. Tally va benissimo, a una condizione: tutta la logica condizionale la calcola n8n, e Tally riceve un flag già pronto. Esempio: invece di chiedere a Tally di confrontare "prioritari < persone" (cosa che non sa fare), n8n fa il conto quando genera il link e passa ?mostra_prioritario=true. Tally fa solo mostra/nascondi. È anche EU-based, un punto a favore per il GDPR.

Fase 2 — dati anagrafici + foto documenti → form nativo n8n

Qui si raccolgono le foto del documento d'identità: dati personali di categoria particolare sotto GDPR. Questo form è semplice (pochi campi + upload), ed è esattamente ciò che il form nativo di n8n gestisce bene. Il vantaggio enorme: essendo self-hosted, i documenti d'identità non escono mai dalla vostra infrastruttura. Risolve da solo il rischio di conformità più grosso del progetto, gratis e senza dipendenze esterne.

In sintesi

Tally per la Fase 1 (logica gestita da n8n). Form nativo n8n per la Fase 2 (documenti self-hosted, GDPR risolto). Due strumenti in tutto.

Il dettaglio sulla parte GDPR è nel documento Decisioni & Migliorie.