Design e ingegneria per founder SaaS
Costruiamo l'intero prodotto in abbonamento. Il sito di marketing è la parte facile. Più difficile è il sistema di pagamento che deve funzionare al primo addebito, l'accesso che deve passare la prima verifica di sicurezza, e il prodotto che deve mostrare il proprio valore prima che il cliente pensi a disdire.
Quello che vediamo più spesso
La fatturazione è cinque strumenti diversi che non si parlano
Il founder finisce a passare le serate a tenere insieme il sistema di pagamento, gli abbonamenti, le email automatiche e il foglio condiviso per estendere i trial scaduti. A fine mese nessuno sa davvero quante settimane di runway sono bruciate.
Un MVP no-code che ha messo paletti dove non avrebbe dovuto
Il founder è arrivato con un prototipo che gli ha permesso di trovare i primi tre clienti, ma a quattro clienti il tetto del no-code si vede. Le viste interne sono finte, il registro delle operazioni non esiste, e il primo cliente che chiede di vedere come tieni i dati separati blocca la trattativa.
Una pagina prezzi che parla agli ingegneri, non a chi compra
I piani sono copiati da un competitor. La tabella comparativa è troppo lunga e non si legge mai fino in fondo. Quello che il cliente consuma oltre il piano non arriva mai sulla fattura.
Moko, lo spazio di lavoro per il supporto clienti
Abbiamo disegnato e sviluppato Moko da zero, dalla casella dei messaggi al portale dove il cliente cerca da solo. Ogni schermata che il team usa ogni giorno è stata costruita con la stessa cura, dentro un unico design system.
Come abbiamo costruito Moko
Moko sostituisce lo spazio di lavoro intero di un team di supporto clienti, dalla casella dei messaggi al portale dove il cliente cerca da solo. Il brief era preciso: ogni schermata finita con lo stesso livello di cura, niente pagina principale pulita seguita da viste lasciate a metà. È la forma di lavoro che rompe quasi tutti gli strumenti di supporto dopo il primo lancio. La casella dei messaggi si prende l'attenzione, i report restano grezzi per mesi, e il portale del cliente lo aggiunge qualcuno la sera prima di andare online.
Il design system era il progetto
Tutte le schermate con la stessa cura significa che il design system guida il progetto, non viceversa. Abbiamo cominciato dalle parti che ogni vista avrebbe condiviso, dai bottoni alle tabelle ai grafici, e sopra quella base abbiamo costruito le aree del prodotto. Nessuna schermata ha avuto un trattamento di favore, nessuna area ha chiesto una variante solo per sé.
La casella dei messaggi è la pagina più importante
La casella dei messaggi è il posto in cui un operatore di supporto vive durante la giornata. La finestra di risposta cambia colore quando si passa dalla risposta visibile al cliente alla nota interna del team, e la modalità si capisce prima di premere invio. I cambi di stato sono immediati e si possono annullare, e l'interfaccia non si ferma mai ad aspettare la rete. Etichette e priorità si modificano direttamente dalla riga del messaggio, senza aprire una finestra in più. Sopra le conversazioni lunghe compare una sintesi automatica, che dice come si sente il cliente, in che piano è, e cosa potrebbe servirgli come passo successivo.
L'intera pagina si può usare anche solo da tastiera. Le scorciatoie coprono i passaggi che un operatore ripete cento volte al giorno. Chi le impara non torna più al mouse.
Un profilo cliente che non racconta storie
Ogni cliente porta con sé la propria storia. Il profilo riassume in una striscia le statistiche principali, mostra tutti i ticket aperti e chiusi del cliente, e permette di aggiungere campi personalizzati direttamente dalla riga, senza aprire una finestra a parte. La stessa scheda compare anche dentro la casella dei messaggi. Chi apre una conversazione vede subito a quale piano è iscritto il cliente, da dove sta scrivendo, e quali sono stati gli ultimi ticket. Tutto resta nella stessa schermata.
Una base di conoscenza per il team e per il cliente
La base di conoscenza è scritta dal team di supporto, e viene letta dai clienti. Dal lato interno è uno strumento di gestione editoriale, con le categorie, le bozze, gli articoli pubblicati. La parte pubblica, raggiungibile dall'indirizzo /help, è una vera pagina di consultazione, con la ricerca in evidenza, le categorie raggruppate, e un indice dentro ogni articolo. Le due facce leggono dagli stessi dati. L'operatore che aggiorna un articolo per chiudere un ticket sa che lo stesso articolo è quello che il cliente troverà cercando da solo.
I due temi pensati insieme dall'inizio
Il tema chiaro e quello scuro non sono stati aggiunti uno dopo l'altro. Sono stati pensati insieme dall'inizio del progetto, e si è lavorato con entrambi attivi durante lo sviluppo. Il prodotto prende i colori e le dimensioni di carattere dal design system, e nessun valore è scritto a mano dentro la singola schermata. Quando si cambia tema, i grafici e le etichette di stato cambiano insieme ai bottoni, e nessuna parte rimane indietro. Cambiare il colore di una categoria di grafici in tutto il prodotto è una modifica in un solo posto.
Perché conta per chi lancia un prodotto in abbonamento
Un prodotto SaaS completo è un sistema in cui il team di supporto, l'amministrazione, la dirigenza e il cliente trovano ognuno il proprio spazio per lavorare. Moko mette insieme tutto questo dentro un solo design system, e il prodotto continua a sembrare lo stesso prodotto quando il team raddoppia o il marchio cambia direzione.
Cosa portiamo in produzione, in questo settore
Accesso con dati isolati per ogni cliente
Ogni cliente vede soltanto i propri dati, e il controllo è fatto direttamente nel database. È la garanzia scritta nero su bianco che il reparto sicurezza del primo cliente enterprise vorrà vedere prima di firmare.
Sistema di pagamento ricorrente che regge i casi limite
Upgrade a metà mese, downgrade, rinnovi e riprove dopo un pagamento fallito vengono calcolati al centesimo. Le notifiche che arrivano da Stripe vengono processate una sola volta, anche se arrivano due volte, e il registro contabile interno non si disallinea mai.
Misura di chi sta capendo davvero il prodotto
Tracciamo le azioni che predicono il rinnovo, non i clic generici. Si capisce subito chi diventerà cliente fedele e chi sta per perdersi, prima che la mail di disdetta arrivi.
Cabina di regia per il tuo team
Rimborsi, cambi di piano, accesso ai dati di un singolo cliente in caso di problema, tutto da interfaccia. Il tuo team smette di entrare nel database a mano.
Compliance pronta al primo audit
Permessi diversi per ogni ruolo del team, registro delle operazioni importanti, esportazione e cancellazione dei dati a norma GDPR. Quello che il primo cliente enterprise chiede di vedere è già lì, pronto.
Difesa contro l'abuso dei trial
Controlliamo il dominio dell'email, riconosciamo il dispositivo che si registra, e mettiamo un tetto al numero di tentativi dalla stessa rete. Aprire una finestra in incognito non basta più.
Uno stack che si ripaga due volte
Ogni livello di questo stack si ripaga due volte. La prima quando metti online la prima versione del prodotto. La seconda quando inizi a crescere, ad assumere, o a rispondere alle domande dell'ufficio acquisti del primo cliente enterprise. Scegliamo lo stack che regge nel secondo momento, non quello che funziona solo oggi.
La parte pubblica del sito, il prodotto vero dentro l'app e il pannello dell'amministratore vivono dentro un solo progetto Next.js. La pagina prezzi è statica e si posiziona bene sui motori di ricerca. Il prodotto, una volta dentro, è veloce dal primo clic. Il team di marketing e quello di prodotto lavorano sullo stesso codice, senza discussioni su dove far stare un flusso nuovo.
I dati dei clienti restano isolati direttamente nel database, e non per via del codice dell'applicazione. La ragione è una sola. La prima trattativa importante con un cliente grande passa per una verifica di sicurezza, e quella verifica fa sempre la stessa domanda, cioè come garantisci che il cliente A non possa vedere i dati del cliente B. Con un Postgres gestito la risposta sta in poche righe di codice, e si può mettere nero su bianco nel contratto. Nello stesso database vivono anche gli account dei clienti, i file caricati, gli aggiornamenti in tempo reale, e il tuo team smette di tenere insieme tre servizi che non si mettono d'accordo su chi sia l'utente.
La fatturazione gira su Stripe. Gli abbonamenti, i cambi di piano, le riprove dopo un pagamento fallito le gestisce Stripe per noi, e il sistema di fatturazione cresce insieme al prodotto senza chiedere di essere rifatto da capo. Se Stripe ha un problema temporaneo, il registro contabile interno resta allineato, e nessun cliente viene addebitato due volte. Il cliente gestisce il proprio piano direttamente dal portale di Stripe, e il tuo supporto smette di fare anche da ufficio fatturazione.
La protezione dagli abusi di utilizzo passa per un servizio Redis gestito, senza un server da mantenere. I file dei clienti restano dentro un object storage che non si fa pagare ogni download, e una scarica ripetuta dello stesso file da parte di un utente non si trasforma in una sorpresa a quattro cifre sulla bolletta del mese dopo.
Tutto il codice è scritto in TypeScript, dalle chiamate al database alle viste sullo schermo. È il vantaggio meno appariscente e il più importante. Quando un ingegnere lascia il team, quando una funzione cambia nome, gli errori vengono scoperti subito invece di emergere sei mesi dopo in produzione. Chi apre il codice il giorno dopo si muove senza una visita guidata.
Domande che fanno i founder
Ho già un MVP su Bubble, si può ripartire da lì?
Sì, lo migriamo. La logica costruita dentro Bubble viene riscritta in codice vero, i dati passano su Postgres, e il prodotto nuovo va online come applicazione vera, non come prototipo no-code con il tetto basso.
Mi serve solo la parte di fatturazione, la fate?
Sì, con un perimetro chiaro. Costruiamo il modulo di fatturazione su Stripe come pezzo a sé, con tutte le integrazioni collegate e una vista interna per il tuo team. Il prezzo dipende da quanto è complesso il modello di prezzi che vuoi.
Come gestite l'abuso dei trial gratuiti?
Lo trattiamo come un livello di sicurezza, non come un trucco di marketing. Controlliamo il dominio dell'email, riconosciamo il dispositivo che si registra, e mettiamo un tetto al numero di tentativi dalla stessa rete. Aprire una finestra in incognito non basta più.
Qual è il perimetro minimo per arrivare ai primi clienti paganti?
All'inizio servono tre cose. L'accesso dei clienti, un sistema di fatturazione che funziona, e il flusso centrale del prodotto fatto bene. Le viste interne e le integrazioni arrivano dopo, quando i primi clienti paganti ti dicono cosa serve davvero. Il superfluo si taglia prima di costruirlo, non dopo.
Restate anche dopo il lancio?
Due opzioni. La prima è un passaggio pulito al tuo team, con tutta la documentazione e il design system in mano. La seconda è restare come partner continuativo del prodotto. Non spariamo dopo il lancio.
Raccontaci il tuo SaaS
Una prima chiamata per inquadrare il progetto, un numero concreto nella prima risposta, e niente pitch deck con case study tutti uguali.