Software house: come sceglierla, quanto costa, cosa chiedere prima di firmare e il numero che decide in cinque anni

Un'azienda di serramenti di Treviso, quaranta dipendenti, decide di sostituire il file Excel con cui pianifica le installazioni. Chiede tre preventivi a tre software house trovate su Google. Il primo costa 78.000 euro, il secondo 120.000, il terzo 135.000. Il titolare sceglie il primo: "Stesso risultato, 57.000 euro in meno". Otto mesi dopo il programma è in produzione con cinque mesi di ritardo, il codice sta nel repository del fornitore, ogni modifica si paga a parte e nessun altro sviluppatore riesce a metterci le mani senza un mese di studio.

Il caso è composto, non è di un cliente reale, ma ne ho visti decine che gli somigliano. La domanda "quale software house scelgo?" si fa quasi sempre guardando la prima riga del preventivo, quella con il prezzo. È la riga che dice meno.

In questo articolo trovi come scegliere una software house guardando quello che costa davvero in cinque anni. Ti dico che cosa sono le sei figure che si fanno chiamare così, quanto costano nel 2026, che cosa cambia tra prezzo chiuso e tempo e materiali, e quali sono le dodici domande che fanno emergere in mezz'ora un fornitore che non è all'altezza. C'è un conto in euro con ogni ipotesi scritta in chiaro, un programma C# che ho compilato e fatto girare per confrontare tre offerte, e un numero solo che decide quasi tutto: quanti giorni servono a un altro fornitore per prendere in mano il tuo codice.

Una premessa onesta. Dal 1999 progetto software per aziende e ho costruito e venduto un gestionale legale multi-tenant: ho passato più anni dall'altra parte del tavolo di quanti ne vorrei ammettere, a scrivere preventivi, a leggerli, a rimediare a quelli scritti da altri. Tutti i numeri qui sotto sono ordini di grandezza che incontro nelle proposte e ipotesi dichiarate, non statistiche di mercato. Servono a farti rifare il conto con i tuoi dati, non a sostituirlo.

Che cos'è una software house, e perché sotto lo stesso nome stanno sei mestieri diversi?

"Software house" in italiano vuol dire una cosa sola: un'azienda che sviluppa software. Ma chi cerca il termine su Google trova sotto la stessa etichetta realtà che non hanno quasi nulla in comune, e il preventivo di una non è confrontabile con quello di un'altra. La prima mossa per scegliere bene è capire con quale delle sei stai parlando.

Il punto che quasi nessuno dice: nessuna delle sei è migliore in assoluto. Un'agenzia web è la scelta giusta per un portale che pubblica contenuti. Una software house di prodotto è la scelta giusta se ti serve un gestionale per la tua categoria e il tuo processo ci sta dentro. Una fabbrica è la scelta giusta quando il progetto è grande e hai bisogno di un metodo. Si sbaglia quando si chiede a una figura di fare il mestiere di un'altra.

Il secondo punto riguarda la parola "fornitore". Una software house che ti consegna un programma e sparisce è un fornitore. Una che resta, lo mantiene e ne risponde per anni è un partner tecnico. Il prezzo sul preventivo è lo stesso, la differenza sta nel contratto e nella persona che alza il telefono il giorno in cui qualcosa si rompe.

Prima di chiedere preventivi rispondi per iscritto a tre domande. Il programma serve a fare una cosa che fanno anche i tuoi concorrenti, o a fare qualcosa che ti distingue? Quante persone lo useranno ogni giorno? Chi, in azienda, sarà il referente che decide quando il fornitore ti chiede un chiarimento? Se non sai rispondere alla terza, il problema non è il fornitore: manca il proprietario del progetto, e nessuna software house, per brava che sia, può esserlo al tuo posto.

Quanto costa una software house nel 2026?

Le tariffe non sono un segreto, ma raramente si trovano scritte. Questi sono gli ordini di grandezza che vedo nelle proposte per progetti .NET e web in Italia, in euro a giornata di otto ore, IVA esclusa.

Una software house strutturata ti fattura una tariffa media che mescola questi profili, di solito fra 380 e 480 euro a giornata. Dentro ci sono i costi che il freelance non ha: una persona che gestisce il progetto, chi fa il collaudo, chi risponde al telefono. Quando il preventivo ti sembra poco, guarda come sono composte le giornate: quattro giornate junior per ogni giornata senior è un prezzo basso e un rischio alto.

Quanto costa un progetto, per taglia

A questi numeri vanno aggiunti, ogni anno, dal 12 al 22% del costo di sviluppo per manutenzione: correzioni, aggiornamenti di sicurezza, piccole modifiche, hosting. Chi ti dice che il software "non ha costi dopo la consegna" o non l'ha mai mantenuto o sta ricavando il margine altrove. Per il dettaglio di tempi e contratto di un progetto su misura c'è la guida allo sviluppo software su misura.

C'è un costo che nei preventivi non compare mai: il tuo tempo. Un progetto medio chiede al referente interno dalle quattro alle otto ore a settimana per mesi, fra riunioni, risposte, prove e collaudo. A 32 euro l'ora di costo interno sono dai 3.000 ai 6.500 euro al mese di lavoro che nessun fornitore ti fattura e che il conto finale deve contenere.

Prezzo chiuso o tempo e materiali: chi si prende il rischio?

Dopo il prezzo, la riga che decide il resto è il modello di contratto. Ce ne sono quattro, e ognuno sposta il rischio da una parte.

Il prezzo chiuso piace perché sembra togliere il rischio. Non lo toglie, lo prezza. Il fornitore sa che i requisiti cambieranno, e mette nel preventivo una riserva che va dal 20 al 35%, oppure scrive il perimetro in modo stretto e fattura tutto il resto come variazione. In un progetto di software il perimetro cambia sempre, perché si scopre cosa serve usandolo. Con un prezzo chiuso ogni scoperta diventa una trattativa.

Il tempo e materiali è onesto e pericoloso. Onesto perché paghi quello che si lavora. Pericoloso perché nessuno ha interesse a finire. La soluzione che uso io, e che consiglio, è una via di mezzo: prezzo chiuso per fasi corte di quattro-sei settimane, con un perimetro scritto per ciascuna, e un tetto di spesa complessivo che si rivede alla fine di ogni fase. Il fornitore ha un impegno preciso, tu puoi fermarti dopo ogni fase, e le scoperte si pagano al prezzo di una fase, non di una variazione.

Il team dedicato ha senso solo se hai già un responsabile tecnico che sa dirigerlo, oppure se prendi un architetto che lo diriga per te. Il canone mensile ha senso per un prodotto a scaffale, con tutto il suo costo di abbonamento, e non per un progetto su misura: in quel caso stai comprando in affitto qualcosa che è fatto apposta per te.

Quanto costa davvero scegliere il preventivo più basso?

Torno ai tre preventivi di Treviso e li metto sulla stessa scala di cinque anni. Il progetto è lo stesso, un programma per pianificare installazioni, ordini e squadre. Le tre offerte:

• A, il prezzo più basso: 78.000 euro a prezzo chiuso, team di sviluppatori prevalentemente junior, codice nel repository del fornitore, manutenzione al 20% l'anno.
• B, una software house strutturata: 120.000 euro, codice nel repository del cliente fin dal primo giorno, manutenzione al 15%.
• C, un architetto senior con un piccolo team: 135.000 euro a fasi, tempo e materiali con tetto, manutenzione al 12%.

Il conto che segue ha otto voci. Ogni ipotesi è scritta nel codice, quindi puoi cambiarla con le tue.

1. Prezzo di sviluppo: quello del preventivo.
2. Variazioni: in un progetto vero il perimetro cresce di circa il 30% rispetto al documento iniziale. Il fornitore A le fattura a una tariffa 1,35 volte quella implicita nel prezzo, il B 1,10 volte, il C alla tariffa normale.
3. Rifacimenti: parti consegnate che vanno rifatte dopo il collaudo e non sono coperte dalla garanzia. Il 25% del prezzo per A, l'8% per B, il 5% per C.
4. Manutenzione: la percentuale annuale per cinque anni.
5. Ritardo: ogni mese di ritardo costa 4.000 euro in benefici che non arrivano. Cinque mesi per A, due per B, uno per C.
6. Uscita attesa: la probabilità di cambiare fornitore entro cinque anni è del 35%. Se succede, due persone lavorano per i giorni di subentro a 480 euro ciascuna.
7. Costo dell'ostaggio: se i giorni di subentro superano venti, il fornitore sa che non puoi andartene e dal terzo anno alza la manutenzione del 30%.
8. Fallimento atteso: la probabilità che il progetto venga abbandonato (20% per A, 8% per B, 5% per C), moltiplicata per il 70% del prezzo già speso e per 100.000 euro per rifarlo altrove.

Le ipotesi sono mie e sono discutibili: il 20% di fallimento della prima offerta è un'opinione di mestiere, non una statistica. È per questo che il codice è sotto, e che dopo il risultato ti faccio vedere quanto cambia il totale quando le ipotesi si spostano.

static Costi Calcola(Offerta o, Ipotesi h)
{
    var variazioni = o.Prezzo * h.CrescitaAmbito * o.MoltiplicatoreVariazioni;
    var rifacimenti = o.Prezzo * o.QuotaRifacimento;
    var manutenzione = o.Prezzo * o.ManutenzioneAnnua * h.Anni;
    var ritardo = o.MesiRitardo * h.CostoMensileRitardo;
    var uscita = h.ProbabilitaCambio * o.GiorniSubentro * h.PersoneSubentro * h.TariffaGiornaliera;
    var ostaggio = o.GiorniSubentro > h.SogliaOstaggio
        ? o.Prezzo * o.ManutenzioneAnnua * h.RincaroOstaggio * (h.Anni - 2)
        : 0m;
    var fallimento = o.ProbabilitaFallimento * (o.Prezzo * h.QuotaPerduta + h.CostoRifacimentoAltrove);
    var totale = o.Prezzo + variazioni + rifacimenti + manutenzione + ritardo + uscita + ostaggio + fallimento;
    return new(totale, variazioni, rifacimenti, manutenzione, ritardo, uscita, ostaggio, fallimento);
}

record Offerta(string Nome, decimal Prezzo, decimal MoltiplicatoreVariazioni, decimal QuotaRifacimento,
    decimal ManutenzioneAnnua, int GiorniSubentro, int MesiRitardo, decimal ProbabilitaFallimento);

record Ipotesi
{
    public int Anni { get; init; } = 5;
    public decimal CrescitaAmbito { get; init; } = 0.30m;
    public decimal CostoMensileRitardo { get; init; } = 4_000m;
    public decimal ProbabilitaCambio { get; init; } = 0.35m;
    public int PersoneSubentro { get; init; } = 2;
    public decimal TariffaGiornaliera { get; init; } = 480m;
    public int SogliaOstaggio { get; init; } = 20;
    public decimal RincaroOstaggio { get; init; } = 0.30m;
    public decimal QuotaPerduta { get; init; } = 0.70m;
    public decimal CostoRifacimentoAltrove { get; init; } = 100_000m;
}

record Costi(decimal Totale, decimal Variazioni, decimal Rifacimenti, decimal Manutenzione,
    decimal Ritardo, decimal UscitaAttesa, decimal Ostaggio, decimal Fallimento);

L'ho compilato con .NET 10 e fatto girare. Il programma completo ha in più, oltre al blocco qui sopra, tre cicli di stampa di una ventina di righe. Questo è il risultato:

Leggi la differenza. Sul preventivo, A costa 57.000 euro meno di C. In cinque anni, A costa 13.555 euro più di C. Il risparmio apparente non sparisce perché il fornitore sia disonesto: sparisce perché il prezzo basso viene compensato altrove, in variazioni più care, rifacimenti, ritardi, dipendenza e probabilità di fallimento.

Il risultato per me più utile non è la classifica, è che i tre totali stanno in 13.500 euro su quasi 300.000. Il prezzo del preventivo non separa le offerte. Quello che le separa è il rischio, cioè quanto è larga la forbice di quello che può succedere.

Guarda come si muove il conto tra A e B quando il progetto cresce più del previsto:

Più il progetto cresce, più l'offerta bassa si avvicina alle altre, perché la sua base è più piccola. Ma in nessuna delle quattro ipotesi A costa meno di B. E il conto non include l'ipotesi peggiore, quella in cui il fornitore sparisce con il codice dentro il suo repository.

Qual è il numero che decide quasi tutto?

Ho detto che il prezzo non separa le offerte. Quello che le separa è un numero che nessun preventivo contiene: i giorni di subentro. Sono i giorni che servono a una persona competente, che non ha scritto il codice, per scaricarlo, farlo partire su un computer pulito, capirlo abbastanza da correggere un errore e rilasciare una modifica.

Perché questo numero e non un altro? Perché misura in una volta sola cose che altrimenti non vedresti: se il codice è leggibile, se esistono i test, se l'ambiente si ricrea con un comando, se la documentazione c'è, se il repository è tuo. Soprattutto misura quanto sei libero di andartene, e la libertà di andartene è l'unica leva negoziale che hai dopo la firma.

Nel conto di prima l'ho usato in due modi. Il primo è il costo di uscita: se cambi fornitore, due persone lavorano per quei giorni. Il secondo è il costo dell'ostaggio: oltre i venti giorni il fornitore sa che andartene ti costa troppo, e la manutenzione sale. Ecco come cambia il totale dell'offerta A al variare del solo numero di giorni, tenendo fermo tutto il resto:

Da cinque a sessanta giorni, lo stesso fornitore con lo stesso prezzo costa 32.520 euro in più. Quasi tutto il salto sta fra venti e trenta giorni, dove scatta la dipendenza. Per questo la regola pratica è una soglia: sotto i venti giorni sei libero, sopra i trenta sei ostaggio.

Non sono numeri scolpiti: la soglia di venti giorni è la mia, nasce da progetti che ho visto cambiare mano. Ma la forma del grafico è sempre quella, un gradino, e il gradino sta dove il cliente smette di poter minacciare di andarsene.

Come si misura il subentro prima di firmare?

Si misura facendolo, in piccolo. Ogni software house che ha già un progetto consegnato, anche piccolo, può prestarti un esempio del suo lavoro. Le chiedi di far scaricare quel progetto a una persona esterna, che non l'ha scritto, e di far partire il sistema da zero. Se non può farlo per riservatezza, ne scegli uno interno o uno di test. Il tempo che ci vuole è il tuo numero.

Puoi affidare il controllo a un consulente tecnico indipendente, per una o due giornate, che vale molto meno del conto di sopra. Questo è lo script che gli consegno. Misura i minuti di ogni passo, da un repository vuoto a un sistema che gira con i test verdi:

#!/usr/bin/env bash
# Misura in minuti quanto serve per far partire un progetto da un computer pulito.
# Uso: ./test-subentro.sh <indirizzo-repository> "<comando-di-build>" "<comando-di-test>"
set -euo pipefail

repo="$1"; build="$2"; prova="$3"
inizio=$(date +%s)
passo() { echo "[$(( ($(date +%s) - inizio) / 60 )) min] $1"; }

git clone --quiet "$repo" progetto
cd progetto
passo "repository scaricato"

bash -c "$build"
passo "ambiente ricostruito e progetto compilato"

bash -c "$prova"
passo "test passati"

echo "Tempo totale: $(( ($(date +%s) - inizio) / 60 )) minuti"
echo "Ora una persona esterna prova una modifica di una riga e la rilascia in prova."

Il numero che esce è un minimo, perché chi lo esegue ha le istruzioni in mano. La regola è: se un esperto non riesce a far partire il sistema in mezza giornata usando solo il repository e il file di istruzioni, i giorni di subentro veri sono più di venti. Se serve telefonare a chi l'ha scritto per sapere che cosa fare, sono più di trenta.

I quattro passi hanno un tempo massimo che considero accettabile per un progetto medio:

• Scaricare il repository: 10 minuti. Se per avere il codice devi chiedere un permesso a qualcuno, il codice non è tuo.
• Ricostruire l'ambiente: 90 minuti. Database, configurazione, segreti. Se serve "il file di configurazione che ha solo Marco", quello è un debito, non un dettaglio.
• Far passare i test: 60 minuti. Se i test non esistono, il subentro non è possibile in modo sicuro: ogni modifica diventa una scommessa.
• Rilasciare una modifica di prova: 120 minuti. Una modifica da una riga, in un ambiente di prova, passando dal processo di rilascio vero.

Sono circa cinque ore e mezza. Un progetto che le supera di molto non è per forza fatto male, ma ti sta dicendo che dovrai pagare il suo conoscitore per sempre.

Quali sono le dodici domande che smascherano un fornitore?

Un fornitore preparato risponde a queste domande senza irrigidirsi, spesso con piacere. Uno che non lo è cambia argomento, ti manda un opuscolo o ti dice che "dipende". Falle in una riunione di mezz'ora, e annota la risposta parola per parola.

1. Chi scriverà il codice del mio progetto, con nome e anni di esperienza? Una buona risposta ha tre nomi e un responsabile. Una cattiva dice "il nostro team", senza nomi.
2. Dove sta il codice, e di chi è il repository? Deve essere nel tuo account, con accesso del fornitore, fin dal primo giorno. Se è nel suo e "ti viene consegnato a fine progetto", è un ricatto con un orario.
3. Quanti giorni servono a un altro fornitore per subentrare? È la domanda del capitolo precedente. Un fornitore sicuro ti propone lui il test.
4. Come gestite una richiesta che cambia il perimetro a metà progetto? Vuoi sentire un processo con una tariffa scritta. Non "ne parliamo".
5. Quali parti del lavoro sono coperte da test automatici, e in che percentuale? Un numero qualsiasi, anche basso, ma onesto. "I test li facciamo a mano" è una risposta.
6. Posso parlare con due clienti che hanno più di tre anni di rapporto con voi? Non i casi studio del sito. Due telefonate, con persone vere. Chi rifiuta ha un problema di ritenzione.
7. Che cosa è andato storto nell'ultimo progetto e che cosa avete cambiato? Chi non ha mai sbagliato non ha mai consegnato. Quello che conta è la lezione.
8. Chi risponde quando qualcosa si rompe di notte o nel weekend, e in quanto tempo? Una buona risposta ha un numero in ore e un costo dichiarato.
9. Dove girerà il sistema, e chi paga l'infrastruttura? Se il server è del fornitore, i dati sono nelle sue mani. Se è tuo, devi sapere quanto costa al mese.
10. Come trattate i dati personali, e firmate la nomina a responsabile del trattamento? Il fornitore che tocca dati di clienti o dipendenti deve avere la nomina e sapere che cosa significa.
11. Quali tecnologie userete, e perché queste? Se la scelta è "quello che sappiamo fare" invece di "quello che serve a te", il fornitore vende il proprio comodo.
12. Che cosa non dovrei chiedervi? È la mia preferita. Una software house onesta sa dirti cosa non fa bene e a chi mandarti.

Dopo la riunione, dai un punteggio da 0 a 2 a ogni risposta. Zero per l'evasione, uno per la risposta parziale, due per la risposta precisa e verificabile. Sotto i quattordici punti su ventiquattro, non vai avanti.

Quali segnali nel preventivo dicono "fermati"?

Il preventivo parla anche quando il fornitore tace. Questi sono i sei segnali che mi fanno rileggere tutto.

• Un solo numero, senza ipotesi. "Sviluppo applicazione: 78.000 euro". Un preventivo serio dice che cosa è incluso, che cosa no, quante giornate per profilo, e su quali ipotesi si regge.
• Nessuna fase di analisi pagata a parte. Prezzare un progetto medio senza avere parlato con chi lo userà vuol dire che il prezzo è un'ipotesi, e che la differenza la pagherai dopo.
• Tempi molto più corti degli altri. Se due fornitori dicono nove mesi e il terzo dice quattro, il terzo non è più veloce: ha capito un'altra cosa o sta promettendo per vendere.
• Nessun nome. Se il preventivo non dice chi lavorerà al progetto, lavorerà chi è libero quel mese.
• Manutenzione assente o molto alta. Meno del 10% annuo significa che non ci sarà un servizio. Oltre il 25% significa che il costo è nascosto nel dopo.
• Proprietà del codice scritta in modo vago. "Il cliente ha diritto d'uso" non è "il cliente è proprietario". La differenza ti costa il giorno in cui vuoi cambiare fornitore.

Un segnale solo non basta a scartare nessuno: i preventivi si scrivono in fretta, e molti sono scritti male da persone che lavorano bene. Due segnali insieme meritano una telefonata. Tre sono un motivo per scegliere un altro.

Quali clausole del contratto contano davvero?

Non sono un avvocato e questo non è un parere legale: il testo lo fai rivedere a chi lo è. Ma dopo molti progetti so quali clausole fanno la differenza quando le cose vanno storte, e sono otto.

1. Proprietà del codice e della documentazione. A te, dal momento del pagamento di ogni fase, e non "alla fine". Con l'eccezione esplicita delle librerie e dei componenti preesistenti del fornitore, che restano suoi ma con licenza perpetua d'uso a tuo favore.
2. Repository del cliente. Il fornitore lavora nel tuo account, con i suoi permessi. Il cambio di fornitore diventa togliere un utente, non negoziare.
3. Accettazione per fasi. Criteri scritti, collaudo in un tempo definito, pagamento a fine fase. Il silenzio non è accettazione.
4. Garanzia sui difetti. Almeno dodici mesi dalla messa in produzione, con tempi di correzione per gravità. Definisci bene che cosa è un difetto e che cosa è una nuova richiesta.
5. Livelli di servizio. Tempo di risposta e di risoluzione per gravità, orari coperti, penale se non rispettati. Una penale non ripaga un fermo, ma indirizza l'attenzione.
6. Uscita ordinata. Se il rapporto finisce, il fornitore garantisce un periodo di affiancamento al successore, a tariffe già scritte. Con una frase si risparmia metà dei giorni di subentro.
7. Persone chiave. Se i nomi nel preventivo cambiano, il cliente ha diritto di approvare i sostituti. Spesso si evita con la formula "o persone di pari livello", che non vuole dire nulla.
8. Protezione dei dati e riservatezza. Nomina a responsabile del trattamento, elenco dei sub-fornitori, luogo di conservazione dei dati, obbligo di avviso in caso di violazione entro un numero di ore scritto.

Il contratto non sostituisce la fiducia, la rende verificabile. Un fornitore che ti chiede di firmare senza modifiche una bozza di cinque pagine sta dicendo come intende lavorare.

Come cambia il rapporto con una software house ora che si programma con l'AI?

Nel 2026 quasi ogni fornitore usa assistenti di programmazione. È un bene: una funzione che richiedeva tre giorni ne richiede uno e mezzo, e il tempo risparmiato può diventare prezzo più basso o più prove. Non è però automatico, e ti conviene chiedere esplicitamente come viene usata.

Il rischio nuovo non è che il codice sia scritto da una macchina. È che nessuno lo abbia davvero letto. Un programma generato in velocità e consegnato senza revisione si legge male, e il suo subentro costa più giorni di uno scritto a mano. Per questo la domanda sul subentro vale oggi più di prima.

Tre domande in più da aggiungere alla lista delle dodici. Chi rivede il codice prodotto con l'AI prima che entri nel repository? Deve esserci una persona con nome. I test sono scritti da una persona o generati dallo stesso strumento che ha scritto il codice? Un test generato dalla stessa fonte conferma gli errori della fonte. Quali dati del mio progetto escono verso servizi esterni? Il codice del cliente non va incollato in uno strumento senza un accordo sul trattamento.

Per il metodo con cui valuto il codice generato c'è la guida su come valutare il codice generato dall'AI, e per l'impatto sulle PMI quella su AI e software su misura nelle PMI italiane.

Software house, team interno, freelance o architetto: chi serve per quale lavoro?

La scelta non è sempre fra tre software house. A volte è fra una software house e un'altra strada. Questo è come ragiono.

Il team interno merita un'osservazione, perché è la strada che tutti scartano per il costo. Un team di sviluppo .NET in Italia costa una cifra a sei zeri l'anno già con tre persone, come spiego nella guida al costo di un team di sviluppo .NET. Quindi ha senso solo quando il software è il centro del tuo valore.

In tutti gli altri casi un fornitore esterno scelto bene costa meno, a patto che tu non gli lasci la proprietà di ciò che costruisce.

C'è un ultimo caso, spesso sottovalutato: l'architetto prima della software house. Pagare due-cinque giornate a un senior indipendente per scrivere i requisiti, scegliere la struttura e confrontare i preventivi costa tra 2.000 e 4.500 euro. È meno del 4% di un progetto medio e riduce molto la probabilità di fallimento.

Il confronto fra preventivi fatto da chi non vende nulla è il servizio che più raramente viene richiesto e che più frequentemente evita guai.

Come si porta a termine la selezione in quattro settimane?

Una scelta fatta bene non richiede mesi. Richiede un ordine, e un piccolo investimento per verificare prima di impegnarsi.

• Settimana 1: scrivere il problema. Due pagine: chi usa il software, quali decisioni deve supportare, quali sistemi già esistono, che cosa non deve fare. Non è un capitolato, è un racconto. Poi scegli il referente interno.
• Settimana 2: tre fornitori, una riunione. Scegli tre fornitori di tipo diverso (una struttura, uno studio, un architetto). Fai le dodici domande. Escludi chi sta sotto i quattordici punti.
• Settimana 3: la fase di scoperta pagata. A due fornitori affidi una fase di scoperta di due-cinque giornate a pagamento: mappa dei processi, rischi, stima ragionata. Costa tra 1.500 e 4.000 euro ciascuno. È l'unico modo di vedere come lavorano prima di scegliere, e di avere un preventivo con le ipotesi scritte.
• Settimana 4: il test di subentro e la decisione. Fai eseguire lo script a un esterno su un progetto già consegnato dal fornitore preferito. Fai la telefonata alle due referenze. Confronta i totali a cinque anni con il programma di prima, cambiando le ipotesi con quello che hai appreso.

Se alla fine due offerte sono vicine, scegli la persona. Nel software il fornitore è un gruppo di persone, e quella con cui parlerai ogni settimana per un anno conta più della ragione sociale.

Quando non serve nessuna software house?

Succede spesso, e dirlo fa parte del mestiere. Tre casi.

• Il tuo processo è quello del tuo settore. Esiste già un gestionale per la tua categoria, con anni di correzioni. Se otto regole su dieci stanno nel suo manuale, comprarlo costa meno di costruire, a ogni orizzonte. Il ragionamento è nella guida a sostituire Excel con un gestionale.
• Non sai ancora cosa vuoi. Se i requisiti cambiano ogni settimana perché il processo non è deciso, un fornitore esterno non risolve: fissa nel codice la confusione. Prima si decide il processo, poi lo strumento.
• Non hai un referente. Un progetto senza una persona interna che decide e collauda fallisce con qualunque fornitore. Prima nomini il responsabile, poi cerchi la software house.

Che cosa sarebbe successo a Treviso?

Torno ai serramenti. Con il conto a cinque anni in mano, il titolare avrebbe visto che i 57.000 euro di differenza fra la prima e la terza offerta diventavano, in cinque anni, 13.555 euro a favore della terza.

Avrebbe visto che il numero decisivo era la dipendenza dal fornitore, non il prezzo. E con il test di subentro avrebbe saputo, prima di firmare, che il codice della prima offerta non poteva essere ripreso da nessun altro in meno di due mesi.

Non è detto che avrebbe scelto la terza. Avrebbe potuto scegliere la prima, con una clausola sul repository del cliente e una fase di scoperta pagata, e pagare di meno con meno rischio. Quello che cambia è che la scelta sarebbe stata sua, fatta con i numeri e non con il prezzo in prima riga.

Se stai scegliendo una software house per un progetto di questa taglia, la strada che consiglio è la consulenza software: una o due giornate per scrivere i requisiti e confrontare i preventivi, prima di impegnarti con chiunque.

Se invece il tuo problema è un sistema già in produzione, scritto anni fa da qualcuno che non c'è più, trovi il metodo nella guida al costo del software legacy e nella pagina sulla modernizzazione del software legacy. Per tempi, contratto e costi di un progetto c'è lo sviluppo software su misura.

In cinque righe. Non confrontare i preventivi sul prezzo, confrontali sul totale in cinque anni. Misura i giorni di subentro prima di firmare, e se superano venti, chiedi il repository nel tuo account. Fai le dodici domande e dai un punteggio. Compra una fase di scoperta pagata da due fornitori prima di sceglierne uno. Metti nel contratto la proprietà del codice, l'uscita ordinata e i nomi delle persone.