SaaS costruiti per reggere il centesimo cliente.
I primi dieci account sono facili. Ciò che si rompe dopo è la separazione dei dati tra clienti, i casi limite della fatturazione e un database che nessuno aveva progettato per questo. Noi lo prevediamo dall’inizio.
Sviluppiamo prodotti SaaS multi-tenant: i dati di ogni cliente separati come si deve, abbonamenti che gestiscono upgrade, downgrade e pagamenti falliti, e un’architettura che non va riscritta quando i clienti crescono. Fissiamo queste due fondamenta prima di qualsiasi funzione. Il codice è vostro dal primo commit, e la prima versione fa solo ciò che serve a vendere.
Aggiornato novembre 2026
Molte riscritture di un SaaS nascono da decisioni prese nella seconda settimana.
Come separate i dati di un cliente da quelli di un altro è la decisione su cui poggia tutto il resto. Se è sbagliata, lo scoprite quando un cliente vede dati che non sono suoi: non è un bug da cui la reputazione si riprende.
L’altra è la fatturazione. Upgrade a metà periodo, downgrade, pagamenti falliti, prove gratuite che si convertono, rimborsi, IVA in più paesi. Sembra poca cosa finché non gira con soldi veri.
Per questo sistemiamo prima queste due cose, poi costruiamo il prodotto sopra. Meno entusiasmante che mostrare funzioni nella prima settimana, e molto meno costoso che ricostruire tutto al secondo anno.
Che cosa sviluppiamo.
Separazione dei clienti che regge
Applicata a livello di database, non affidata alla memoria di chi deve ricordarsi di aggiungere un filtro a ogni query.
Fatturazione che regge la realtà
Upgrade a metà periodo, downgrade, carte rifiutate, solleciti, prove gratuite, rimborsi, IVA. In Italia, se vendete ad aziende, anche la fattura elettronica tramite SDI.
Team, ruoli e inviti
I vostri clienti hanno colleghi. Aggiungerlo dopo è doloroso, quindi entra presto.
Un onboarding che converte
I primi dieci minuti decidono se una prova diventa un cliente. Vanno progettati, non lasciati a un tour guidato.
Limiti d’uso e misurazione
I limiti di ogni piano applicati davvero, e dati di utilizzo su cui si può fatturare.
Un pannello per il vostro team
L’assistenza non può aiutare un cliente che non vede. Costruito con un registro di chi ha fatto che cosa.
Analisi del prodotto
Quali funzioni vengono usate, dove le prove si bloccano. Altrimenti la roadmap si fa a intuito.
Pronto per le domande sulla sicurezza
Registro delle attività, controllo degli accessi, esportazione dei dati. I clienti grandi lo chiedono, e «lo aggiungeremo» fa perdere contratti.
Come separare i dati dei clienti.
La decisione di architettura più difficile da cambiare dopo. Non esiste una risposta giusta per tutti: esiste quella giusta per la vostra situazione.
| Tabelle condivise | Schema per cliente | Database per cliente | |
|---|---|---|---|
| Costo con mille clienti | Il più basso | Medio | Il più alto |
| Rischio che i dati si mescolino | Reale: basta una query sbagliata | Basso | Quasi nullo |
| Ripristinare i dati di un solo cliente | Difficile | Semplice | Banale |
| Personalizzazioni per cliente | Difficili | Possibili | Facili |
| Clienti grandi o regolamentati | Spesso rifiutato | Di solito accettato | Preferito |
| Adatto per | Self-service, tanti piccoli account | La maggior parte dei prodotti B2B | Pochi clienti grandi o regolamentati |
Piattaforme che abbiamo costruito.
Piattaforma di gestione aziendale in Oman, web e app, costruita da zero con il nostro fondatore come CTO.
Checkout di pagamento per una fintech pakistana, in produzione da oltre quattro anni.
Lavoro per il più grande switch di pagamento condiviso del Pakistan.
Gateway di pagamento e fatturazione in Qatar, costruito partendo dall’idea del cliente fino a un prodotto funzionante.
Quando costruire.
L’avete venduto prima di costruirlo
La posizione più forte. Clienti paganti prima del codice significano che la domanda sul mercato ha già una risposta.
State trasformando un servizio in prodotto
Fate già questo lavoro a mano per i clienti. È il punto di partenza migliore per un SaaS.
Uno strumento interno che altri vogliono
Qualcuno ha chiesto di comprare ciò che avete costruito per voi. Vale la pena prenderlo sul serio.
Non fa per voi se l’idea non è mai stata messa alla prova
Costruite prima la cosa più piccola che dimostri che qualcuno paga. Se è questa la risposta onesta, vi proponiamo quella invece di un SaaS completo.
Come lavoriamo.
Fissiamo separazione dei dati e fatturazione
Le due decisioni che costa caro cambiare. Prima di qualsiasi funzione.
Riduciamo la prima versione
Ciò che dimostra che le persone pagheranno, e nient’altro. La maggior parte delle prime versioni di un SaaS è grande il doppio del necessario.
Sviluppiamo in blocchi di due settimane
Software funzionante su un link che potete usare, ogni quindici giorni.
Colleghiamo i pagamenti presto
Non alla fine. Un problema di pagamento scoperto al quarto mese è molto peggio che al primo.
Misuriamo l’uso
Analisi dal lancio, così la roadmap nasce dall’uso reale e non dalle opinioni.
Consegniamo come si deve
Documentazione, codice nel vostro repository e un periodo di assistenza mentre il prodotto si assesta.
Sviluppo di prodotti SaaS
7 domande con risposta. Ne avete un’altra? Scriveteci.
Dipende meno dall’elenco delle funzioni e più dalle due decisioni di fondo: come separate i clienti e come funziona la fatturazione. Chi le salta per mostrare funzioni prima di solito perde quel tempo, con gli interessi, al secondo anno. Le date le concordiamo per iscritto dopo aver definito la prima versione.
Sette categorie. Quarantacinque servizi.
Raccontateci il progetto, com’è davvero.
Scriveteci cosa vi serve e dove siete bloccati. Vi rispondiamo entro un giorno lavorativo con domande vere, e se il progetto dovrebbe essere più piccolo di come lo immaginate ve lo diremo.