Piattaforma SaaS in abbonamento: come la costruiamo dal primo modulo

Un prodotto SaaS («software as a service») è un’applicazione che i tuoi clienti usano dal browser e pagano ogni mese o ogni anno, senza installare nulla. Chi cerca «sviluppo piattaforma SaaS» ha di solito un’idea verificata a metà: conosce bene un problema di un certo settore e vuole venderne la soluzione a più aziende contemporaneamente.

Il rischio più grande non è tecnico. È costruire a lungo un prodotto che nessuno paga. Per questo proponiamo una prima versione piccola, chiamata di solito MVP (prodotto minimo funzionante, cioè il prodotto più piccolo che si può vendere), con le fondamenta fatte bene e il resto rimandato apertamente.

Sviluppo piattaforma SaaS: cosa entra nella prima versione

La prima versione fa bene una cosa sola: quella per cui qualcuno tirerebbe fuori la carta. Mettiamo che tu voglia un prodotto per la gestione di alcune palestre. La funzione che si vende potrebbe essere il registro degli abbonamenti e degli ingressi; i report elaborati, l’app per smartphone e il collegamento con i tornelli possono aspettare.

Intorno a questa funzione c’è però una parte che non puoi saltare, perché senza di essa non hai un prodotto, ma un prototipo.

• Registrazione e autenticazione: nuovo account, conferma via email, reimpostazione della password.
• Spazio del cliente: ogni azienda abbonata ha i propri dati, utenti e impostazioni.
• Ruoli: almeno proprietario, amministratore e utente semplice, con inviti via email.
• Abbonamento: scelta del piano, pagamento, cambio di piano, disdetta.
• Guida al primo utilizzo: pochi passaggi che portano la persona fino al primo risultato utile, con dati di esempio.
• Pannello di amministrazione: per te, per vedere account, pagamenti e problemi.

Account separati per ogni cliente: come teniamo divisi i dati

L’architettura in cui la stessa applicazione serve più clienti si chiama multi-tenant (ogni cliente è un «inquilino»). Nella variante più diffusa tutti condividono lo stesso database e ogni riga porta l’identificativo dell’azienda a cui appartiene. Nell’altra, ogni cliente ha il proprio database.

La prima è più semplice da mantenere e adatta alla maggior parte dei prodotti agli inizi. La seconda isola meglio e aiuta quando vendi a grandi aziende, ma complica gli aggiornamenti. Qualunque sia la scelta, la separazione viene imposta in un solo punto del codice, non in ogni schermata, e viene verificata con test automatici che provano di proposito a leggere i dati di un altro cliente.

Abbonamenti e fatturazione tramite un gateway di pagamento

La logica dei pagamenti ricorrenti non la scriviamo da zero. Usiamo un gateway (Stripe è un esempio frequente) che conserva le carte, esegue i rinnovi, ritenta i pagamenti falliti e avvisa l’applicazione tramite webhook, cioè messaggi automatici inviati a ogni evento: pagamento riuscito, pagamento fallito, abbonamento disdetto.

L’applicazione ascolta questi messaggi e apre o limita l’accesso. La parte commerciale la decidi tu: periodo di prova o no, piani per numero di utenti o per volume, che cosa succede ai dati di chi smette di pagare. Il trattamento fiscale delle vendite, soprattutto verso altri paesi, va chiarito con il commercialista prima di scegliere il gateway.

Che cosa lasciamo volutamente a dopo

Ogni funzione rimandata è tempo guadagnato per scoprire che cosa vogliono davvero i primi utenti. Teniamo un elenco scritto di ciò che non entra nella prima versione, perché non rientri di soppiatto strada facendo.

Quello che non rimandiamo mai: i backup, la separazione dei dati e la possibilità per un abbonato di esportare i propri dati. Sono cose che costa moltissimo sistemare quando hai già degli utenti.

• App nativa per smartphone: all’inizio basta un’interfaccia web che si veda bene da mobile.
• Interfaccia di programmazione (API) per terzi: si aggiunge quando la chiede qualcuno che paga.
• Report complessi: un’esportazione in un foglio di calcolo copre le esigenze iniziali.

Il ritmo di lavoro e gli strumenti dietro le quinte

Per prodotti di questo tipo preferiamo Laravel, un framework PHP che offre, nel nucleo o tramite pacchetti ufficiali, l’autenticazione, le code di lavori e il collegamento con alcuni gateway di pagamento. I dati stanno in PostgreSQL o MySQL. Le operazioni lente (email, importazioni, report) girano in background e ogni modifica passa da una serie di test automatici prima della pubblicazione.

Quello che non possiamo fare: validare il mercato al posto tuo. Possiamo costruire gli strumenti con cui misuri (quanti si registrano, quanti arrivano al primo risultato, quanti pagano dopo il periodo di prova), ma i colloqui con i primi clienti spettano a te.

• Workshop iniziale: disegniamo il percorso dell’utente dalla registrazione al primo risultato e tagliamo il resto.
• Ossatura: account, spazio di ogni cliente, ruoli, ambiente di prova.
• Funzione centrale: costruita in cicli brevi, con una dimostrazione alla fine di ciascuno.
• Pagamenti e guida iniziale: aggiunti quando la funzione centrale si può mostrare a qualcuno di esterno.
• Primi utenti: un gruppo ristretto, dai cui intoppi nasce l’elenco successivo.

Questa è la descrizione di un progetto tipo: mostra come affrontiamo di solito un lavoro di questo genere e non presenta un progetto realizzato per un cliente specifico. Ogni progetto reale parte dalla situazione della tua azienda; fasi, tempi e prezzo si definiscono dopo il primo colloquio.