Percorri la prima sessione del cliente
Crea un account nuovo nell'ambiente che intendi pubblicare. Segui la verifica o i callback dei provider, ricarica l'app, aggiorna un profilo e disconnettiti. Ripeti il percorso su uno schermo stretto con la tastiera. La tua sessione di sviluppo abituale può nascondere passi di configurazione mancanti e stato obsoleto.
Rivedi i messaggi che spiegano cosa fare dopo. Una schermata vuota dovrebbe offrire un'azione utile. Una richiesta fallita deve spiegare come riprovare invece di suggerire che il lavoro è riuscito. Usa il linguaggio reale del prodotto in questi messaggi e assicurati che i link di account e supporto portino a destinazioni reali.
Ripeti il percorso una volta per ogni metodo di accesso. I callback OAuth di Google e GitHub portano ciascuno i propri redirect e modi di fallire (la guida alla configurazione di OAuth spiega come configurarli), e la schermata di consenso di prova di un provider si comporta diversamente da quella di produzione.
- Creazione account e ripristino sessione funzionano.
- Il logout revoca l'accesso e cancella la presentazione dell'utente precedente.
- Gli stati vuoto, caricamento ed errore restano comprensibili su mobile.
- Ogni provider OAuth completa il suo callback sul dominio reale.
- Le email di verifica e reset arrivano, si leggono chiaramente e puntano all'ambiente giusto.
- L'esperienza del primo avvio dice a un nuovo utente cosa fare dopo.
Dimostra l'accesso a pagamento sul server
Il checkout è la metà facile. Percorri l'intero ciclo di vita nella sandbox del provider: acquisto, webhook ricevuto e verificato, permesso persistito, funzionalità a pagamento sbloccata — poi rinnovo, cancellazione e rimborso. Ogni transizione dovrebbe cambiare stato posseduto dal server, non solo un flag nel client. La guida a pagamenti e abbonamenti mostra dove supastack conserva quello stato.
Poi testa gli eventi che speri di non vedere: un webhook consegnato due volte, un pagamento fallito, un abbonamento che scade a metà di un'attività. Un permesso risponde «è consentito adesso» al momento della richiesta; un badge nella dashboard no.
- Un acquisto in sandbox si completa e sblocca la funzionalità a pagamento.
- Le consegne duplicate dei webhook sono sicure — l'elaborazione è idempotente.
- Cancellazione e rimborso revocano l'accesso alla frontiera del server.
- I limiti per posto o per utilizzo, se offerti, rifiutano oltre i loro termini.
Verifica i confini con dipendenze reali
Usa due account indipendenti per verificare il possesso. Prova a leggere e modificare il record di un account dall'altro, inclusi stato delle attività e URL di ripresa. Verifica l'accesso a pagamento alla frontiera dell'azione server, non solo nascondendo un pulsante nell'interfaccia.
I record delimitati per workspace sono la spina dorsale di un prodotto multi-tenant — il post sui confini dei workspace spiega il modello. Qualunque sia il tuo stack, la domanda di lancio è la stessa: ogni lettura e scrittura deriva il possesso dal contesto autenticato del server, senza accettare come prova un ID di record o un workspace inviato dal client?
- Letture e scritture tra workspace vengono rifiutate.
- Gli URL di ripresa e delle attività non concedono accesso da soli.
- Le viste di lista e dettaglio applicano la stessa delimitazione.
- Le chiavi API e i webhook, se offerti, portano con sé anche il confine del workspace.
Esercita apposta i percorsi di fallimento
Il lavoro in background fallisce in due modi distinti, e ciascuno richiede il proprio test. Un dispatch fallito lascia il client incerto se qualcosa sia stato accodato — una chiave di idempotenza delimitata all'attività e una submission salvata permettono al ripristino di riutilizzare la richiesta originale invece di duplicarla. Un completamento fallito significa che il lavoro è girato ma il risultato non è mai arrivato — retry e polling dello stato dovrebbero chiudere quel gap senza una seconda generazione.
Applica lo stesso ragionamento ai provider: un timeout del provider AI, un'email respinta, un errore dell'API di fatturazione. Ciascuno dovrebbe finire in uno stato specifico e spiegabile invece che in un mezzo risultato silenzioso. La guida al ripristino delle attività documenta come il percorso di produzione del kit gestisce questi casi.
- Un retry dopo un timeout di submission non duplica lavoro né costo.
- Un completamento fallito è visibile e recuperabile, non una perdita silenziosa.
- Gli errori dei provider raggiungono l'utente come stati onesti, non crash generici.
Preparati al primo fallimento
Assicurati che qualcuno possa trovare un errore, collegarlo all'attività interessata e aiutare l'utente a riprendersi senza esporre segreti dei provider. Conferma quali log e record di audit esistono, per quanto li conservi e come un operatore vi accede.
Decidi prima del lancio che aspetto ha «qualcosa non va»: consegne di job fallite, errori di verifica dei webhook, un'improvvisa impennata nella spesa dei provider. Un alert che nessuno riceve non è monitoraggio — la guida alla configurazione dell'osservabilità copre il collegamento di quei segnali.
Tratta i backup come un esercizio operativo: un backup configurato non equivale a uno ripristinato. Esegui il ripristino una volta, su dati che assomigliano alla produzione, prima del giorno in cui ti servirà.
- Un errore si può ricondurre alla richiesta, all'utente e all'attività che l'hanno causato.
- Log e record di audit hanno un proprietario, una policy di retention e regole di accesso.
- Un backup è stato ripristinato, non solo configurato.
- I job falliti e gli errori dei webhook sollevano un alert che una persona riceve.
Controlla le superfici attorno al prodotto
Le superfici legali e di comunicazione fanno parte del lancio, non della rifinitura: privacy e termini che descrivono ciò che il prodotto fa davvero, un indirizzo di supporto che raggiunge una persona e un dominio mittente verificato così la posta transazionale arriva da un indirizzo che possiedi.
Leggi ogni email automatica come farebbe un cliente. I messaggi di verifica, reset, ricevuta e completamento dovrebbero portare il nome del prodotto, link all'ambiente giusto e un percorso di risposta che non sia un indirizzo noreply morto.
- Le pagine di privacy e termini descrivono il prodotto che esegui davvero.
- La posta transazionale parte da un dominio verificato che possiedi.
- Le domande su supporto e fatturazione hanno una destinazione raggiungibile.
Rendi esplicita la decisione di go o no-go
Assembla il registro di rilascio: la revisione del build, l'ambiente target, cosa è stato testato e come, e cosa resta non verificato. Una checklist con gap onesti batte un riepilogo sicuro di sé — i gap sono dove di solito vive il primo incidente.
Decidi il percorso di rollback prima che ti serva: come annullare il deployment, cosa succede ai dati scritti nel frattempo e chi prende la decisione. Poi lancia la versione più piccola dell'offerta che puoi supportare pienamente, e allargala deliberatamente.
Domande frequenti sul lancio
Le checklist di lancio falliscono in punti prevedibili. Queste sono le domande che ne intercettano la maggior parte.
- Cosa dimentica la maggior parte dei lanci SaaS? — La fine dei flussi: un logout che revoca davvero, una cancellazione che toglie davvero l'accesso e un'esercitazione di ripristino per il backup che esiste sulla carta.
- Quanti account di test mi servono? — Almeno due, nell'ambiente target. L'isolamento dei dati e i flussi di invito non si possono verificare con uno solo.
- Test in sandbox o in produzione? — Entrambi. La sandbox dimostra la logica del ciclo di vita; una piccola transazione reale dimostra che chiavi, domini e webhook sono collegati al posto giusto.
- Quando è sicuro lanciare? — Quando ogni voce che protegge dati o denaro dei clienti è verificata, e quelle non verificate sono annotate con un proprietario — non quando la lista delle funzionalità sembra completa.
- Cosa cambia dopo il lancio? — Conserva il registro di rilascio, osserva gli alert di fallimento che hai configurato e riesegui la checklist dopo ogni cambiamento significativo ad auth, fatturazione o delimitazione.