Quando ha senso un software su misura?
Un software su misura ripaga quando il tuo modo di lavorare è parte di ciò che ti rende competitivo, oppure quando gli strumenti standard ti costringono a soluzioni di ripiego che ogni anno costano più di quanto costerebbe svilupparlo. Di solito è la scelta sbagliata quando un prodotto pronto copre gran parte del processo e il resto si risolve con la configurazione o con una piccola integrazione. Lo verifichiamo con onestà all’inizio, perché il software più economico è quello che non serve sviluppare.
I segnali che cerchiamo: un processo che passa da fogli Excel ed email perché nessuno strumento è adatto; collaboratori che digitano gli stessi dati in più sistemi; licenze per utente pagate per persone che usano una sola schermata; dati che devono restare sotto il tuo controllo. Pro e contro sono spiegati in software su misura o software standard.
Come sviluppiamo un software su misura
Analisi con le persone che fanno il lavoro. Mappiamo il processo così come funziona oggi, eccezioni comprese, e scriviamo le regole di business come affermazioni verificabili («un ordine oltre il limite di credito richiede l’approvazione di un responsabile») invece che come descrizioni di schermate. Il risultato è un modello dei dati, una nota di architettura e un primo rilascio che è utile già da solo.
Un’architettura semplice e collaudata. La maggior parte dei sistemi aziendali che realizziamo è una sola applicazione con un database PostgreSQL, una REST API tipizzata e documentata con OpenAPI e un’interfaccia in React o renderizzata lato server. Separiamo servizi distinti solo dove il carico, l’isolamento o un ciclo di rilascio indipendente lo giustificano. I backend sono in Python (FastAPI, SQLAlchemy, migrazioni con Alembic) o in Node.js con TypeScript, scelti in base al tuo team e ai sistemi esistenti.
Test fin dalla prima settimana. Test unitari e di integrazione girano in CI a ogni modifica, con test end-to-end in Playwright sui flussi critici, e un deployment parte solo se la suite passa. La prima istanza della piattaforma di outreach che abbiamo sviluppato per un cliente SaaS è stata consegnata con circa 160 test automatici.
Sicurezza come impostazione di base. I ruoli sono applicati nel backend, le password sono salvate come hash, il login si blocca dopo ripetuti tentativi falliti e le credenziali restano fuori dal codice. Le dashboard di amministrazione si rifiutano di avviarsi su un indirizzo pubblico finché l’autenticazione non è configurata. Dove il server richiama URL esterni, si collega solo a indirizzi pubblici e li ricontrolla dopo ogni redirect, chiudendo le classiche falle SSRF.
Gestione operativa pianificata prima del lancio. Immagini Docker, un ambiente di staging, un reverse proxy con TLS, log strutturati, backup e un runbook che può seguire anche chi non ha scritto il codice.
Cosa va storto nei progetti di software su misura
- Regole scoperte durante i test con gli utenti. Quando il perimetro è descritto come una serie di schermate, i casi limite emergono tardi. Scrivere le regole come test e come impostazioni (soglie, finestre temporali, priorità) le rende visibili e modificabili senza un nuovo rilascio.
- Integrazioni sottovalutate. Le API esterne hanno limiti di chiamate, campi mancanti e comportamenti non documentati. Colleghiamo ogni sistema esterno già nel primo sprint, e le integrazioni restano in sola lettura se la scrittura non è necessaria. In uno dei sistemi che abbiamo realizzato, l’integrazione può chiamare solo un elenco autorizzato di operazioni di lettura, e un test dimostra che un’importazione completa non esegue alcuna scrittura.
- Job eseguiti due volte. Un job ripetuto invia la stessa email o crea lo stesso ordine una seconda volta. Chiavi univoche, prese in carico atomiche e handler idempotenti rendono sicure le riesecuzioni.
- Nessun responsabile dopo il lancio. Un software che nessuno capisce si degrada in fretta. Ricevi documentazione, un runbook e la possibilità di proseguire lo sviluppo con Sensaria.
Cosa incide su costi e tempi
| Fattore |
Effetto sull’impegno |
| Flussi di lavoro e ruoli utente |
Ogni ruolo e ogni percorso di approvazione aggiungono schermate, regole e test. |
| Integrazioni |
Qualità e limiti delle API esterne spesso decidono il calendario. |
| Migrazione dei dati |
Pulire e trasferire i dati esistenti è quasi sempre sottostimato. |
| Audit e conformità |
Log, regole di conservazione e controlli di accesso aggiungono lavoro di progettazione e di test. |
| Complessità dell’interfaccia |
Modifiche in blocco, tabelle complesse o uso offline costano più di semplici moduli. |
| Disponibilità |
Un servizio attivo 24 ore su 24 richiede monitoraggio, ridondanza e reperibilità. |
Offriamo un prezzo fisso per un primo rilascio ben definito, oppure lavoriamo per fasi quando l’analisi mostra che una parte del perimetro dipende da come le persone usano la prima versione. In entrambi i casi vedi il piano e le sue ipotesi prima che il lavoro inizi.
Protezione dei dati e hosting
I sistemi aziendali contengono di solito dati personali, quindi le norme sulla protezione dei dati orientano la progettazione: per i dati trattati in Svizzera la legge federale sulla protezione dei dati (LPD) riveduta, in vigore dal 1° settembre 2023, e per i dati di persone nell’UE il RGPD, con obblighi analoghi. Nella LPD, l’articolo 7 impone la protezione dei dati sin dalla progettazione e per impostazione predefinita. L’articolo 16 consente la comunicazione all’estero solo verso Paesi con una protezione adeguata o con garanzie supplementari. L’articolo 24 obbliga a notificare all’IFPDT ogni violazione della sicurezza dei dati che comporta verosimilmente un rischio elevato per le persone interessate. In pratica integriamo ruoli, regole di conservazione e registri di audit nel primo rilascio, documentiamo quali fornitori vedono quali dati e ospitiamo il sistema in Svizzera o in una regione UE, a seconda dei tuoi contratti e del tuo settore.
Come si collega al resto dei tuoi sistemi
Un software su misura raramente vive da solo. Legge e scrive dati nel tuo CRM, nella contabilità o nella piattaforma e-commerce tramite integrazioni API, a volte diventa un CRM o gestionale su misura e talvolta si trasforma in un prodotto per altre aziende attraverso lo sviluppo SaaS. Gli scenari tipici sono descritti nella soluzione dedicata ai gestionali e processi interni.
Perché Sensaria
Sensaria AG è un’azienda svizzera con sede a Lugano. Per un cliente SaaS abbiamo realizzato una piattaforma di scouting e outreach verso startup: una pipeline quotidiana con code di approvazione, una dashboard basata sui ruoli e il passaggio dei contatti al CRM del cliente. Abbiamo sviluppato anche un sistema di riattivazione degli affiliati che analizza una piattaforma di terzi rigorosamente in sola lettura, e un motore di reclutamento di affiliati con crawling protetto da SSRF e una traccia di audit per ogni identità unificata. Lavoriamo in italiano, tedesco, francese e inglese.