Fabio Russo · 2026-09-21Due software che a prima vista sembrano simili possono richiedere quantità di lavoro molto diverse. Una dashboard con un solo ruolo e dati già puliti non è lo stesso progetto di un gestionale multi-ruolo che deve migrare anni di dati, sincronizzarsi con un ERP e mantenere uno storico delle approvazioni.
Il costo non dipende dal numero di schermate
Le schermate sono la parte visibile. La complessità reale è spesso nelle regole che stanno dietro all’interfaccia: chi può fare cosa, quali dati devono essere sincronizzati, cosa accade quando un’integrazione fallisce e quali controlli servono prima di modificare informazioni critiche.
- Workflow: stati, eccezioni, approvazioni e automazioni.
- Ruoli e permessi: utenti con visibilità e responsabilità diverse.
- Integrazioni: CRM, ERP, e-commerce, pagamenti o sistemi legacy.
- Dati: qualità, migrazione, deduplicazione e storico.
- Requisiti non funzionali: sicurezza, disponibilità, logging, performance e backup.
- Test e rilascio: ambienti, QA, rollback e supporto post go-live.
La discovery serve anche a ridurre il preventivo
Una buona fase di analisi non serve soltanto ad aggiungere requisiti. Serve anche a togliere ciò che non è necessario nella prima release. Se il team distingue il workflow essenziale dalle funzioni che possono aspettare, il progetto diventa più stimabile e il rischio di costruire moduli inutilizzati diminuisce.
MVP non significa software incompleto
Una prima release utile deve risolvere un problema reale dall’inizio alla fine. Tagliare scope non significa eliminare controlli, sicurezza o gestione degli errori. Significa scegliere un insieme più piccolo di workflow che possa essere usato e misurato, lasciando le estensioni a iterazioni successive.
Come leggere un preventivo software
Prima di confrontare due cifre, verifica se stanno includendo lo stesso perimetro.
- La discovery è inclusa o viene fatturata separatamente?
- Il preventivo include migrazione e pulizia dei dati?
- Le integrazioni sono già state verificate o solo ipotizzate?
- Chi prepara test, ambienti e deploy?
- Repository, account e documentazione restano accessibili al cliente?
- Manutenzione, monitoraggio e supporto hanno un perimetro definito?
- Le evoluzioni vengono stimate a parte o sono comprese?
Prezzo fisso o time & materials?
Un prezzo fisso funziona meglio quando il perimetro è sufficientemente definito. Nei progetti con molte incognite, un modello a tempo e materiali o una discovery separata può rendere più trasparenti assunzioni e cambi di scope. Il punto non è quale formula sia universalmente migliore, ma se rischio e responsabilità sono chiari per entrambe le parti.
Il costo continua dopo il go-live
Hosting, monitoraggio, backup, aggiornamenti, nuove integrazioni e supporto fanno parte del costo totale di proprietà. Un progetto economico da sviluppare ma difficile da manutenere può diventare più costoso nel tempo di una soluzione progettata per evolvere.
Quando la risposta giusta è non sviluppare
Se un SaaS copre il processo con vincoli accettabili, sviluppare da zero può non avere senso. Lo stesso vale quando una semplice automazione o un’integrazione tra strumenti esistenti elimina già il lavoro manuale che genera il problema.
Per approfondire questa decisione leggi software custom o SaaS. Se invece il bisogno è già chiaramente custom, la pagina Software su misura descrive discovery, MVP, integrazioni, sicurezza e manutenzione.
La domanda da portare al primo incontro
Più che chiedere subito “quanto costa?”, prepara una descrizione del processo attuale: chi lo esegue, quali strumenti usa, quali passaggi sono manuali, dove si verificano errori e quali dati devono attraversare più sistemi. È il modo più rapido per trasformare una cifra generica in una stima che abbia un significato.