EN

Sviluppo SaaS, da chi ne gestisce uno

Sette lastre di vetro smerigliato sospese una sopra l'altra, come i livelli di una piattaforma SaaS

Un SaaS non è un sito con il login: incassa ogni mese, tiene separati i dati di ogni cliente e non può fermarsi di notte. Se sei ancora alla prima versione, parti dallo sviluppo dell'MVP; se il prodotto è uno strumento interno, guarda le web app su misura.

Anatomia

Di cosa è fatto un SaaS?

Un SaaS è fatto di sette livelli impilati, e l'interfaccia che vedono i clienti è solo quello in cima. Gli altri sei decidono se il prodotto incassa, protegge i dati e regge quando i clienti aumentano.

  1. Interfaccia

    L'app web che usano i tuoi clienti: onboarding, pagine di lavoro, impostazioni. In Next.js e React, veloce anche dal telefono e pronta a diventare un'app.

  2. API

    Collega l'interfaccia ai dati e agli altri servizi: app mobile, integrazioni, automazioni. Versionata, documentata, con limiti d'uso per ogni cliente.

  3. Autenticazione e ruoli

    Chi entra e cosa può fare: login, inviti, ruoli per team e amministratori. Ogni richiesta controlla i permessi sul server, non solo nell'interfaccia.

  4. Abbonamenti e pagamenti

    Piani, prove gratuite, rinnovi, disdette e fatture. Sul web con un provider di pagamento; nelle app con gli acquisti in-app, quando le regole degli store lo chiedono.

  5. Dati multi-tenant

    Un database condiviso in cui i dati di ogni cliente restano separati. Lo schema nasce con il cliente dentro: aggiungerlo dopo vuol dire riscrivere mezzo prodotto.

  6. Infrastruttura

    Server, database, code di lavoro, ambienti di prova e di produzione. Decidiamo dove girano i dati e automatizziamo i rilasci, così ogni modifica passa dagli stessi controlli.

  7. Monitoraggio e backup

    Errori, metriche e allarmi per sapere che qualcosa non va prima dei clienti. Backup automatici del database, con una copia conservata fuori sede.

Le fasi

Come si sviluppa un SaaS, dall'idea alla scala?

In sei fasi, e le prime due si fanno prima di scrivere codice: sono quelle che costano di più se le salti.

  1. Perimetro

    Chi paga, per quale problema, quanto vale risolverlo. Fissiamo il primo perimetro misurabile e le metriche che diranno se funziona.

  2. Architettura

    Modello dei clienti, ruoli, piani e prezzo, dove vivono i dati. Sono le scelte più care da cambiare dopo: le mettiamo per scritto.

  3. Design di prodotto

    Flussi, prototipo cliccabile, design system, provati con utenti veri prima di costruirli: è il lavoro di product design e UX.

  4. MVP

    Login, abbonamenti, la funzione che giustifica il prezzo e una dashboard. Con CI, ambienti separati e backup attivi dal primo rilascio.

  5. Lancio

    Onboarding, email di sistema, tracciamento di attivazione, ricavi ricorrenti e abbandoni. Entrano i primi clienti e misuriamo cosa fanno davvero.

  6. Crescita

    Iterazioni guidate dai dati, integrazioni, app mobile, prestazioni sotto carico. Quando il prodotto cresce, ne parliamo nella fase di scale-up.

Architettura

Quali scelte architetturali vanno fatte all'inizio?

Cinque, e conviene scriverle prima del codice: ognuna è facile da decidere il primo giorno e costosa da cambiare quando i clienti sono dentro.

Le scelte tipiche di un SaaS e quando conviene ciascuna strada
SceltaStrada AStrada BCome scegliamo
Clienti e istanzeSingle-tenant: un'istanza e un database per ogni clienteMulti-tenant: un'istanza condivisa, dati separati per clienteMulti-tenant per quasi tutte le startup: costi e aggiornamenti più semplici. Single-tenant quando un cliente grande chiede isolamento completo per contratto.
Separazione dei datiTabelle condivise, con il cliente indicato su ogni rigaUno schema o un database per clienteTabelle condivise con controlli automatici per partire; schemi separati se i clienti sono pochi, grandi e con requisiti propri.
Modello di prezzoAbbonamento, per piano o per utenteA consumo: si paga quello che si usaAbbonamento quando il valore è stabile: ricavi prevedibili. A consumo quando il valore cresce con l'uso (API, AI, messaggi), con un conteggio preciso.
Pagamenti nelle appPagamento sul web con un providerAcquisti in-app su App Store e Google PlayDipende da cosa vendi: su iOS, per sbloccare funzioni digitali dentro l'app, Apple chiede in genere gli acquisti in-app. Va deciso prima della revisione.
Dove giraPiattaforme cloud gestite, pagate a consumoServer dedicati o virtuali gestiti dal teamPiattaforme gestite per partire in fretta; server propri quando contano controllo, costi prevedibili e dati in Europa.

Esperienza diretta

Come gestiamo il nostro SaaS, Athleex?

Una lastra di vetro con barre e una curva in rilievo, come una dashboard di ricavi e abbandoni

Athleex è il SaaS del gruppo per personal trainer e coach, con un'app per gli atleti: l'abbiamo progettato, costruito e lo facciamo crescere noi. Le scelte di questa pagina le abbiamo fatte prima sul nostro prodotto.

Dentro c'è una dashboard di business con ricavi ricorrenti, abbandoni e valore dei clienti, e un Churn Radar che segnala in anticipo gli atleti a rischio di abbandono: i numeri che servono a chi gestisce un SaaS, dentro il SaaS stesso.

Applicazione
Next.js, interfaccia in più lingue
Dati
PostgreSQL, con Prisma
Server
Europei (Hetzner), gestiti da noi
Rilasci
CI automatica su GitHub Actions
Backup
Notturni, con copia fuori sede
App
iOS e Android con Capacitor, sulla stessa base
Leggi il caso studio Athleex

Domande sullo sviluppo SaaS

Quanto costa sviluppare un SaaS?

Dipende da quanti livelli servono al primo rilascio, da quante integrazioni e dalle piattaforme: solo web, o anche app. Non pubblichiamo listini: dopo una prima chiamata ti diamo una stima su un perimetro scritto. I fattori che fanno il prezzo sono in prezzi e tempi.

Quanto tempo serve per sviluppare un SaaS?

Dipende dal perimetro più che dalla tecnologia. Un primo rilascio con login, abbonamenti e la funzione principale è molto più rapido di una piattaforma completa: per questo fissiamo prima il perimetro e poi i tempi, per scritto.

Cos'è un'architettura multi-tenant?

È un'architettura in cui un'unica applicazione serve più clienti (tenant) tenendo separati i loro dati. È il modello più comune nei SaaS perché riduce i costi e semplifica gli aggiornamenti; la separazione dei dati va progettata nello schema fin dall'inizio.

Meglio un abbonamento o un prezzo a consumo?

L'abbonamento dà ricavi prevedibili ed è più semplice da spiegare. Il consumo funziona quando il valore cresce con l'uso, come per API o funzioni AI, ma richiede di misurare l'utilizzo con precisione. Molti SaaS combinano un piano base con una parte a consumo.

Potete partire da un prototipo che ho già?

Sì. Se l'hai fatto con strumenti no-code o con l'AI, lo valutiamo e decidiamo insieme cosa tenere e cosa riscrivere: è il lavoro descritto in da prototipo a produzione.

Il SaaS può avere anche un'app mobile?

Sì. Con Capacitor la stessa base web diventa un'app iOS e Android, come per Athleex; se il prodotto lo richiede valutiamo React Native, Flutter o il nativo. Ne parliamo nella pagina sullo sviluppo app.

Da leggere

Hai un SaaS da costruire o da far crescere?

Rispondiamo entro un giorno lavorativo.

Parliamone