Sviluppo
Sensaria sviluppa prodotti SaaS per founder e aziende, in Svizzera e all'estero, dal primo MVP fino alla piattaforma multi-tenant su cui contano clienti paganti. Progettiamo architettura, isolamento dei tenant, abbonamenti e fatturazione, gestione degli utenti, API pubblica e dashboard, e poi continuiamo a seguire la crescita e lo sviluppo del prodotto.
Un prodotto SaaS ha due parti: le funzionalità per cui i clienti pagano e la piattaforma che permette a molti clienti di usarle in sicurezza nello stesso momento. La piattaforma comprende isolamento dei tenant, registrazione e gestione dei team, abbonamenti e fatturazione, un’API pubblica, strumenti di amministrazione, monitoraggio e un processo di rilascio. Nel primo anno richiede spesso tanto lavoro quanto le funzionalità, ed è la parte più costosa da aggiungere a posteriori. Progettiamo entrambe fin dall’inizio e costruiamo solo la piattaforma che serve nella fase in cui ti trovi.
| Fase | Obiettivo | Cosa esiste alla fine |
|---|---|---|
| Analisi | Individuare l’ipotesi più rischiosa e il prodotto più piccolo che la mette alla prova | Perimetro, nota di architettura, modello di tenancy e di prezzo |
| MVP | Utenti reali su dati reali | Registrazione, flusso principale, fatturazione, tracciamento degli errori, backup |
| Produzione | Clienti paganti che ci contano | Ruoli, registro di audit, API pubblica, console di amministrazione, monitoraggio, revisione di sicurezza |
| Crescita | Crescere senza emergenze continue | Code di lavoro, cache, limiti per tenant, budget di prestazioni, runbook per la reperibilità |
Un MVP è piccolo nel perimetro, non nella qualità. Autenticazione, isolamento dei tenant e logging ci sono dal primo rilascio, perché aggiungerli dopo significa mettere mano a ogni query e a ogni schermata.
Modello di tenancy. Database condiviso con una colonna tenant, uno schema per tenant oppure un database per tenant. Di solito partiamo da un database PostgreSQL condiviso e applichiamo l’isolamento con la row-level security: un filtro dimenticato nel codice applicativo non può esporre le righe di un altro tenant. Il design lascia spazio per spostare in seguito un grande cliente su un database dedicato, se un contratto lo richiede.
Identità e accessi. Sessioni per l’applicazione web, chiavi API con ambiti limitati per le integrazioni e token firmati a breve scadenza (RS256) quando il prodotto è integrato in un’altra piattaforma. I permessi vengono verificati nel backend a ogni richiesta.
Fatturazione. Il provider di fatturazione è la fonte di verità per i pagamenti; il tuo prodotto lo è per ciò che ogni piano consente. Webhook con firma verificata mantengono sincronizzate le due parti, e l’accesso non viene mai concesso sulla base di un semplice redirect del browser.
API first. Una REST API versionata con documento OpenAPI, paginazione basata su cursore e chiavi di idempotenza sulle richieste di scrittura. Per i prodotti che devono poter essere usati da agenti di IA, accanto all’API c’è un server MCP in sola lettura.
Funzioni di IA con dei limiti. Dove il prodotto richiama modelli linguistici (LLM), aggiungiamo tetti di costo per tenant, validazione dell’output del modello, un provider di riserva e la registrazione di modello, versione del prompt, token e costo per ogni chiamata.
Usiamo l’OWASP Application Security Verification Standard (ASVS) come checklist di prontezza per la produzione e seguiamo le pratiche del NIST Secure Software Development Framework (SP 800-218): code review, analisi statica e scansione delle credenziali in CI, e un processo di rilascio documentato. La LPD riveduta si applica ai trattamenti che producono effetti in Svizzera, per esempio quando il prodotto ha utenti svizzeri. Il GDPR si applica se la tua azienda ha sede nell’UE o se offri il prodotto a persone nell’UE, e l’AI Act dell’UE può riguardare le funzioni di IA il cui output viene usato lì. Progettiamo flussi di dati, elenchi dei fornitori e hosting (in Svizzera o in una regione UE) in modo che le tue risposte ai questionari di sicurezza dei clienti siano corrette.
| Fattore | Effetto sull’impegno |
|---|---|
| Tenancy e isolamento | Database dedicati o hosting regionale per singolo cliente aggiungono lavoro di sviluppo e di gestione. |
| Modello di fatturazione | Licenze per utente, conteggio dell’utilizzo, periodi di prova e imposte aggiungono ciascuno regole e casi limite. |
| Integrazioni | Ogni sistema di terzi porta con sé la propria autenticazione, i propri limiti e i propri modi di fallire. |
| Funzioni di IA | Progettazione dei prompt, valutazione e controllo dei costi si aggiungono alla funzione stessa. |
| Requisiti enterprise | Single sign-on, esportazioni per l’audit e revisioni di sicurezza arrivano con i clienti più grandi. |
| MVP esistente | Sostituire una base no-code o un prototipo richiede migrazione dei dati e un periodo di esercizio parallelo. |
Dopo la fase di analisi quotiamo l’MVP come progetto a perimetro fisso, poi pianifichiamo le fasi successive in base a ciò che ti insegna. Fasi e checklist di prontezza sono approfondite in dall’MVP alla produzione.
Un prodotto SaaS ha bisogno di un sistema commerciale attorno. Prove gratuite e registrazioni confluiscono nell’automazione CRM e vendite. Le email di onboarding, fatturazione e utilizzo passano dall’automazione email. I dati del prodotto vengono scambiati con gli strumenti dei tuoi clienti tramite integrazioni API.
Realizziamo e gestiamo piattaforme di questo tipo. Una directory di API di comunicazione che abbiamo realizzato pubblica una REST API pubblica con documento OpenAPI, più un server MCP in sola lettura; le richieste in testo libero passano da un parser deterministico invece che da un LLM, così la stessa domanda riceve sempre la stessa risposta. Per un cliente abbiamo sviluppato un prodotto multi-tenant con row-level security in PostgreSQL, webhook in uscita firmati con nuovi tentativi e disattivazione automatica, e un widget integrabile autenticato con token a breve scadenza. Sensaria AG ha sede a Lugano, in Svizzera, e lavora in italiano, tedesco, francese e inglese.
Cosa comprende
Modello di dominio, modello di tenancy, confini tra i servizi e flussi di dati decisi presto e messi per iscritto, così l'MVP non va riscritto quando arriva il primo grande cliente.
Il prodotto più piccolo che mette alla prova con utenti reali la tua ipotesi più rischiosa, su fondamenta da produzione (autenticazione, tenancy, logging) che più avanti costerebbero care da aggiungere.
Isolamento dei tenant applicato nel database con la row-level security di PostgreSQL, più test automatici che provano a leggere i dati di un altro tenant e devono fallire.
Piani, periodi di prova, licenze per utente e limiti di utilizzo modellati nel tuo prodotto; pagamenti e fatture gestiti da un provider come Stripe Billing e sincronizzati tramite webhook con firma verificata.
Registrazione, inviti, ruoli e permessi, chiavi API con ambiti limitati e regole di sessione, più una console di amministrazione interna per il tuo team di supporto.
Una REST API versionata con un documento OpenAPI e, se il prodotto deve essere usato da agenti di IA, un server MCP in sola lettura accanto all'API.
Dashboard per i clienti e una vista interna su tenant, utilizzo, job falliti e consegne dei webhook.
Webhook in uscita firmati per ogni endpoint, con nuovi tentativi e disattivazione automatica degli endpoint non più raggiungibili; webhook in entrata verificati ed elaborati in modo idempotente.
Code di lavoro in background, cache dove conviene, tracciamento degli errori e log strutturati, e un processo di rilascio che ti permette di pubblicare ogni settimana.
Scenari tipici
Un founder con interviste e una lista d'attesa ha bisogno di un prodotto per cui le persone siano disposte a pagare. Definiamo l'MVP attorno all'unico flusso per cui i clienti pagano e lo lanciamo con la fatturazione già attiva: la disponibilità a pagare si misura, non si presume.
Un sistema nato per una sola azienda acquisisce tenant, onboarding in autonomia e fatturazione, senza rompere i flussi di lavoro degli utenti originali.
Quando un prototipo no-code raggiunge i suoi limiti su prestazioni, permessi o integrazioni, lo ricostruiamo con un modello dei dati adeguato, migriamo gli account esistenti e facciamo girare le due versioni in parallelo fino al passaggio.
Una REST API pubblica con documento OpenAPI e un server MCP in sola lettura permettono agli sviluppatori dei tuoi clienti e agli assistenti IA di interrogare direttamente il tuo prodotto.
Un editor o un widget che altre software house integrano per i propri utenti, isolato in un iframe, con token firmati a breve scadenza e un tema grafico per ogni tenant.
FAQ
Un MVP mirato con registrazione, un flusso principale e fatturazione richiede di solito da due a quattro mesi. Per passare dall'MVP a una piattaforma in produzione su cui contano clienti paganti servono in genere altri tre-sei mesi di rilasci: ruoli, registri di audit, API pubblica, strumenti di amministrazione, monitoraggio e una revisione di sicurezza. Il ritmo dipende soprattutto dalle decisioni sul perimetro e dalle integrazioni.
I principali fattori di costo sono i requisiti di tenancy e hosting, il modello di fatturazione (licenze per utente, conteggio dell'utilizzo, periodi di prova, imposte), le integrazioni, le funzioni di IA e le richieste enterprise come il single sign-on o le esportazioni per l'audit. Non pubblichiamo prezzi. Dopo la fase di analisi quotiamo l'MVP come progetto a perimetro fisso e pianifichiamo le fasi successive in base a ciò che l'MVP ti insegna.
Che i clienti possono contarci. In pratica: i dati dei tenant sono isolati a livello di database, gli accessi vengono verificati a ogni richiesta, gli errori sono tracciati e generano allarmi, i backup vengono ripristinati nei test e non solo eseguiti, i deployment sono automatizzati e reversibili, e puoi rispondere in modo veritiero al questionario di sicurezza di un cliente. Per la parte di sicurezza usiamo OWASP ASVS come checklist.
Chiedi come isola i tenant, come mantiene sincronizzato lo stato della fatturazione, come funzionano test e rilasci e chi gestisce il prodotto dopo il lancio. Chiedi di vedere un prodotto che ha realizzato e che è online, API compresa. Campanelli d'allarme: prezzi fissi senza fase di analisi, nessun test automatico e nessun piano per la proprietà del codice e la consegna.
Il prezzo fisso funziona bene per un MVP o un rilascio con un perimetro chiaro. Quando il prodotto è online e le priorità cambiano ogni settimana, conviene di più una capacità mensile o un accordo a consuntivo, perché scoprirai cose che cambiano il piano. I pagamenti per milestone legati a software funzionante in produzione combinano i due approcci.
Per l'applicazione, OWASP ASVS è una checklist di verifica concreta, mentre il NIST Secure Software Development Framework (SP 800-218) descrive le pratiche di sviluppo che le stanno attorno. SOC 2 e ISO/IEC 27001 sono certificazioni organizzative che i clienti più grandi possono chiedere in seguito; sviluppare secondo ASVS e tenere registri di audit rende quel percorso molto più semplice.
La LPD riveduta si applica ai trattamenti di dati personali che producono effetti in Svizzera, per esempio se il prodotto ha utenti svizzeri. Il GDPR si applica se la tua azienda ha sede nell'UE o se offri il prodotto a persone nell'UE. L'AI Act dell'UE può riguardare le funzioni di IA il cui output viene usato nell'UE, con obblighi che dipendono dalla categoria di rischio. Progettiamo flussi di dati, elenchi dei fornitori e hosting tenendo conto di queste regole.
Sì. Esportiamo il modello dei dati e i record esistenti, ricostruiamo il prodotto con tenancy, permessi e test adeguati, migriamo account e dati e facciamo girare le due versioni in parallelo finché gli utenti non passano alla nuova. Ricostruire conviene quando lo strumento no-code limita prestazioni, controllo degli accessi o integrazioni, non prima di avere utenti paganti.
Tecnologie che usiamo
TecnologieProdotti SaaS dal primo MVP alla piattaforma multi-tenant: architettura, isolamento dei tenant, abbonamenti e fatturazione, gestione utenti, API pubblica, dashboard e sviluppo continuo.