Sei fasi, ordinate per dipendenza: cosa sblocca cosa, e come costruiamo l'85% senza restare bloccati ad aspettare gli altri sviluppatori.
Prima di fissare tempi e numeri definitivi, ci sono tre punti tecnici da verificare sul campo (circa una giornata in tutto). Servono a trasformare la stima da "ipotesi" a "numero": ognuno ha un esito chiaro sì/no.
| Verifica | Cosa si testa | Esito |
|---|---|---|
| A — Limiti Tally | Ripetizione 1–4 persone, parametri URL, validazioni | Tally regge → si tiene. Altrimenti → form custom |
| B — Compilazione EX-18 | Riempire il PDF AcroForm governativo via n8n | Campi mappabili → rapido. Modulo bloccato → altro approccio |
| C — Livello dati | Schema Supabase + sync verso Notion + affidabilità trigger | Ibrido solido → si procede. Altrimenti → fallback |
Schema Supabase, la base anti-duplicati (idempotenza), gestione errori globale verso Discord, e i blocchi riutilizzabili (Drive, email, alert). Tutto il resto poggia qui.
Un solo tier (Expert), una sola situazione, dall'inizio alla fine: acquisto → raccolta → pratica → documenti → guida. Prova l'intera catena prima di costruire in larghezza. La Tasa viene simulata con uno stub.
Tutti i tier e tutte le situazioni: raccolta Fase 1 completa (gate, reminder), apertura pratiche in parallelo, matrice delle 12 guide, gestione upsell.
Revoca per cambio stato, loop di correzione email e WhatsApp, recovery NIE rejected, chargeback. È la metà "robusta": qui si concentra gran parte dei test.
Webhook in entrata/uscita con l'agente WhatsApp, API di lettura pratica, reminder. Si costruisce sul contratto concordato col developer, con un agente simulato per non restare bloccati.
Calendly, cart abandonment, campagne recensione/referral, KPI dashboard.
Replay degli eventi falliti, e le sessioni di test dal vivo insieme — tutti gli scenari, log alla mano. Più export JSON e documentazione dei workflow.
Due parti dipendono da altri sviluppatori: l'endpoint Tasa e l'agente WhatsApp. Se aspettassimo entrambi, il calendario sarebbe ostaggio del loro.
La soluzione: simulare entrambi. Uno stub che restituisce un PDF finto al posto della Tasa, e un finto agente che chiama i nostri endpoint. Così costruiamo e testiamo circa l'85% del sistema in autonomia, e innestiamo gli endpoint veri quando sono pronti. È la differenza tra un calendario di 4 settimane e uno di 8.
Le settimane indicate sono di lavoro effettivo. Il calendario reale dipende soprattutto da due cose esterne: quando arriva il contratto dei webhook WhatsApp e quando è pronto l'endpoint Tasa. Il dettaglio è nel documento Dipendenze & Contratti.