Come scegliere una software house? Verificando dieci cose concrete: chi possiede il codice, ogni quanto vedrai demo funzionanti, se gli SLA sono scritti, come è costruita la stima, se le referenze sono verificabili, che tecnologie usa, chi scrive davvero il codice, cosa succede dopo il rilascio, se sa dirti di no e quanto è chiaro il contratto. Se un fornitore supera questi dieci controlli, la probabilità che il progetto finisca bene sale in modo drastico.
Una scelta sbagliata non si paga alla firma: si paga dopo, in mesi di ritardo, codice che non puoi portare via e canoni che coprono difetti di costruzione invece che evoluzioni. In questa guida trovi i dieci criteri spiegati uno per uno, il confronto software house o freelance, le domande da fare al primo incontro e una checklist di autodiagnosi da applicare al fornitore che stai valutando. Se intanto stai definendo il budget, abbiamo scritto una guida separata su quanto costa un software su misura.
Come scegliere una software house: i 10 criteri
Nessuno di questi criteri richiede competenze tecniche per essere verificato. Servono solo domande dirette e la disponibilità ad ascoltare le risposte con attenzione: un fornitore serio non si offende, anzi apprezza chi le fa.
1. Proprietà del codice
Il codice deve essere tuo, per contratto e nella pratica: proprietà intellettuale assegnata alla tua azienda, repository a cui hai accesso completo fin dal primo giorno, credenziali di cloud e domini intestate a te. La formula «vi concediamo una licenza d'uso» significa che stai affittando, non comprando: al primo disaccordo il fornitore ha in mano il tuo sistema.
2. Demo frequenti
Un fornitore serio mostra software funzionante ogni una o due settimane, non slide di avanzamento. Le demo frequenti sono l'unico modo per accorgersi presto che qualcosa è stato capito male, quando correggere costa poco. Se ti propongono di «rivederci alla consegna» fra quattro mesi, stai firmando per un effetto sorpresa — e nei progetti software le sorprese sono quasi sempre negative.
3. SLA scritti
«Rispondiamo sempre subito» non è uno SLA: è una frase. Uno SLA vero indica tempi di presa in carico e di risoluzione per gravità del problema, canali di contatto, orari coperti e cosa succede se non vengono rispettati. Chiedilo prima di firmare, non al primo blocco in produzione: la differenza tra chi ce l'ha e chi improvvisa si vede esattamente in quel momento.
4. Stime trasparenti
Una stima seria si può leggere: elenca cosa include, cosa esclude, quali assunzioni sono state fatte e come vengono gestiti i cambi di scope. Un importo secco su una riga non è una stima, è una scommessa — di solito persa da te. Diffida anche dell'estremo opposto: il preventivo molto più basso degli altri di norma non ha capito il progetto, e recupererà la differenza in extra.
5. Referenze verificabili
Chiedi due o tre clienti con progetti simili al tuo per settore o complessità, e chiamali davvero. Le domande utili: il fornitore ha rispettato tempi e budget? Come ha gestito gli imprevisti? Com'è l'assistenza dopo il rilascio? Un portfolio patinato senza nomi contattabili vale poco: chiunque può elencare loghi.
6. Stack moderno ma noioso
Le tecnologie giuste per il software aziendale sono quelle consolidate, ben documentate e con un mercato di sviluppatori ampio. Chi propone l'ultimo framework di moda ti sta usando come terreno di sperimentazione; chi usa un framework proprietario «fatto in casa» ti sta costruendo un lock-in. La domanda di controllo: «Se domani volessi far evolvere il sistema con un altro team, quanto sarebbe difficile trovarlo?»
7. Chi scrive davvero il codice
Il senior brillante che vedi in call è la stessa persona che svilupperà, o il progetto finirà in subappalto? Chiedi nomi, ruoli e da quanto tempo le persone sono nel team. Il subappalto non è illegale, ma va dichiarato: ogni passaggio di mano aggiunge attrito, perdita di contesto e un margine in meno investito sulla qualità.
8. Manutenzione dopo il rilascio
Il go-live è l'inizio, non la fine: aggiornamenti di sicurezza, dipendenze da tenere al passo, piccole evoluzioni continue. Un fornitore serio propone un piano di manutenzione e supporto già in offerta, con contenuti espliciti. Chi non ne parla mai o sta pianificando di sparire dopo il collaudo, o conta di fartela pagare cara quando sarai vincolato.
9. Capacità di dire no
Un fornitore che dice sempre sì sta vendendo, non progettando. Già in fase di valutazione dovresti sentirti dire almeno un no motivato: una funzione da rimandare, una semplificazione proposta, un'idea da verificare con i dati prima di svilupparla. È il segnale che dall'altra parte c'è qualcuno che ragiona sul tuo risultato, non sul proprio fatturato di giornata.
10. Contratto chiaro
Il contratto deve coprire proprietà intellettuale, milestone con criteri di accettazione, pagamenti legati agli avanzamenti, gestione delle modifiche, riservatezza e una clausola di uscita che ti permetta di chiudere il rapporto portando via codice, dati e documentazione. Se il commerciale minimizza con un «sono formalità», è esattamente il momento di leggere ogni riga.
Software house o freelance: cosa cambia per una PMI
La domanda arriva sempre, ed è legittima: un bravo freelance costa meno e per progetti piccoli e ben definiti può essere la scelta giusta. Il confronto però va fatto sui rischi, non solo sulla tariffa oraria.
| Aspetto | Freelance | Software house |
|---|---|---|
| Tariffa | Più bassa | Più alta |
| Continuità | Dipende da una persona (ferie, malattia, altri clienti) | Coperta dal team |
| Competenze | Verticali su una tecnologia | Trasversali: sviluppo, sicurezza, cloud, UX |
| Bus factor | 1: se sparisce, si ferma il progetto | Più persone conoscono il codice |
| Quando ha senso | Progetto piccolo, scope chiuso, bassa criticità | Sistema critico che evolve negli anni |
La regola pratica: più il software è critico per il fatturato e più a lungo dovrà vivere, più il costo di una struttura si ripaga. In ogni caso i dieci criteri di questa guida valgono per entrambi: anche un freelance deve darti codice di tua proprietà, stime leggibili e un contratto chiaro.
Le domande da fare a una software house al primo incontro
Le domande da fare a una software house servono a due cose: ottenere informazioni e osservare come reagisce chi hai davanti. Le risposte evasive dicono più delle risposte sbagliate.
- Di chi è il codice a fine progetto, e dove sarà il repository?
- Ogni quanto vedrò una demo funzionante?
- Chi lavorerà concretamente sul mio progetto, e da quanto tempo è nel vostro team?
- Cosa include la stima, cosa esclude e come gestite i cambi in corsa?
- Posso parlare con due vostri clienti con progetti simili al mio?
- Che SLA offrite dopo il rilascio, per iscritto?
- Se fra tre anni volessi cambiare fornitore, cosa mi porto via e in che formato?
- Qual è l'ultima cosa che avete sconsigliato a un cliente?
L'ultima domanda è la più rivelatrice: chi non ha mai sconsigliato nulla a nessuno ti sta dicendo che accetterà qualunque richiesta, comprese quelle che ti danneggiano.
Come valutare un fornitore software: i segnali d'allarme
Oltre ai criteri positivi, ci sono segnali che dovrebbero interrompere la trattativa, o almeno rallentarla parecchio. Nessuno di questi da solo è una condanna: due o tre insieme sì.
- Preventivo a corpo in poche righe, senza assunzioni né esclusioni
- Codice concesso «in licenza d'uso» invece che di tua proprietà
- Prima demo prevista solo alla consegna finale
- Framework proprietario o tecnologie che nessun altro sul mercato conosce
- Nessun cliente contattabile, solo loghi sul sito
- Pressione a firmare in fretta «per bloccare il prezzo»
- Silenzio totale su manutenzione, sicurezza e aggiornamenti
- Ogni tua idea accolta con entusiasmo, senza una sola obiezione
Regola d'oro: tutto ciò che il commerciale promette a voce deve esistere anche nel contratto. Se non è scritto, non esiste.
Il metodo dietro i criteri: un esempio concreto
Questi dieci criteri non sono teoria: sono il modo in cui una software house seria dovrebbe lavorare per struttura, non per gentile concessione. Nel nostro processo li abbiamo resi espliciti: demo a ogni iterazione, codice di proprietà del cliente fin dal primo commit, stime che elencano assunzioni ed esclusioni, e la libertà — che ci prendiamo spesso — di sconsigliare funzioni che non ripagherebbero l'investimento.
Non lo raccontiamo per dire che siamo gli unici a farlo: lo raccontiamo perché puoi usare il nostro studio e il nostro modo di sviluppare software su misura come termine di paragone. Porta questi criteri a ogni fornitore che valuti — noi compresi — e osserva chi regge il confronto senza irrigidirsi.
Come scegliere una software house: il test dei 10 punti
Applica ora i dieci criteri al fornitore che stai valutando: spunta solo le voci che puoi dimostrare con documenti, contratti o telefonate fatte, non con impressioni. Il verdetto ti dice a che punto sei.
Meglio una software house o un freelance?
Dipende da criticità e durata del progetto. Per uno strumento piccolo e ben definito un bravo freelance può bastare; per un sistema critico che evolverà negli anni servono continuità, competenze trasversali e un bus factor superiore a uno. I dieci criteri della guida valgono comunque per entrambi.
Quante software house conviene confrontare?
Due o tre preventivi comparabili sono sufficienti. Se le cifre distano moltissimo tra loro, quasi sempre i fornitori hanno capito progetti diversi: torna a chiarire i requisiti prima di scegliere in base al prezzo.
Come verifico davvero le referenze di una software house?
Chiedi contatti di clienti con progetti simili al tuo e chiamali. Fai domande su tempi, gestione degli imprevisti e assistenza dopo il rilascio: sono i punti in cui i fornitori deboli crollano e quelli seri si distinguono.
Una software house piccola è un rischio?
Non di per sé. Contano il metodo, la proprietà del codice, la documentazione e il fatto che più di una persona conosca il progetto. Una struttura piccola con un processo solido è più affidabile di una grande che subappalta senza dirlo.