Vai al contenuto
Prezzi & decisioni

Come scegliere una software house senza buttare i soldi

Stai per spendere decine di migliaia di euro in software su misura e non hai gli strumenti tecnici per valutare chi lo costruisce. Ecco i segnali che contano davvero, le domande da fare prima di firmare e come proteggerti.

9 min di lettura

Stai per firmare un contratto da decine di migliaia di euro per un software che dovrebbe far girare la tua azienda — e la verità scomoda è che non hai gli strumenti per capire se chi hai davanti è bravo o sta solo vendendo bene. Non è colpa tua: non sei tecnico. Ma la decisione la devi prendere lo stesso. Questa è la guida che avrei voluto darti prima che firmassi.

Scegliere male non costa il progetto: costa il doppio

Quando una software house consegna male, non perdi solo i soldi che hai speso. Perdi i mesi passati ad aspettare, perdi la finestra di mercato in cui quel prodotto serviva, e alla fine paghi una seconda volta: qualcuno deve capire il codice altrui, decidere cosa salvare e cosa buttare, e rifarlo. Il conto vero di una scelta sbagliata è quasi sempre più alto del preventivo che ti aveva convinto.

I criteri con cui scegli di solito non predicono il risultato

Quasi tutti scelgono una software house sugli stessi tre segnali. Il problema è che nessuno dei tre dice quasi niente su come finirà il tuo progetto.

  • Il portfolio bello. Un sito con dei bei case study dimostra che sanno presentarsi, non che scrivono codice mantenibile. Le schermate le fa il reparto grafico; il debito tecnico non si vede in una slide.
  • Il commerciale simpatico. La persona che ti conquista in riunione quasi mai è quella che scriverà il tuo software. È pagata per farti firmare, non per costruire.
  • Il prezzo. Né il più economico né il più caro ti proteggono. Il preventivo basso di solito taglia le cose invisibili che tengono in piedi un software nel tempo; quello alto non è garanzia di nulla se non sai cosa stai pagando.

I segnali che contano davvero

Quelli che predicono un buon esito sono meno appariscenti, e li puoi cogliere anche senza essere tecnico — perché riguardano il comportamento, non il codice.

  • Ti fanno domande scomode. Una software house seria, prima di darti un numero, vuole capire il problema: chi userà il software, cosa succede se una certa cosa si rompe, cosa puoi tagliare. Chi ti dà un preventivo senza averti interrogato, ti sta dando un numero a caso.
  • Ti dicono di no.Chi ti dà ragione su tutto ti sta vendendo, non consigliando. Un fornitore che ti spiega perché un'idea è troppo costosa o rischiosa vale più di uno che dice sempre "sì, si può fare".
  • Sono chiari su chi scrive il codice.Devi sapere chi, in concreto, metterà le mani sul tuo progetto — e cosa succede se quella persona se ne va. La risposta "abbiamo un team" non basta.
  • Stimano a voce alta. I bravi ti spiegano come sono arrivati a un numero e a una tempistica, e dove sono i rischi. Chi stima con sicurezza assoluta o non ha capito il problema, o te lo sta nascondendo.

Le domande da fare prima di firmare

Portale al primo incontro. Non ti serve capire le risposte tecniche nel dettaglio: ti serve vedere come rispondono — se sono diretti o vaghi, se ti spiegano o ti confondono.

  • Il codice, il repository con lo storico e gli accessi all'infrastruttura restano miei? (La risposta giusta è sì, per iscritto.)
  • Chi scrive concretamente il codice, e con che esperienza? Cosa succede se quella persona non c'è più?
  • Come gestite i test e cosa succede quando qualcosa si rompe in produzione?
  • Cosa NON è incluso nel preventivo? (Le sorprese vivono qui.)
  • Se tra sei mesi voglio cambiare fornitore, cosa mi porto via e in che stato?

Se davanti a queste domande diventano evasivi, hai già l'informazione che cercavi. Molte delle situazioni che racconto in agenzia software che non consegna iniziano proprio con domande mai fatte all'inizio.

I campanelli d'allarme

  • Prezzo fisso su uno scope vago. Un numero preciso su un progetto descritto in due righe significa che qualcuno pagherà la differenza — e non saranno loro.
  • "Ti facciamo tutto noi, non pensare a niente." Suona rassicurante, di solito significa nessuna trasparenza e dipendenza totale da loro.
  • Proprietà del codice ambigua. Se serve una discussione per stabilire che il tuo software è tuo, la risposta la conosci già.
  • Nessun senior sul progetto. Se le parti delicate le scrive chi sta ancora imparando, le paghi due volte: una in bug, una in rifacimenti.

Come proteggerti prima di firmare

Non devi diventare tecnico per fare una scelta tecnica: devi mettere qualcuno di tecnico dalla tua parte. Una seconda opinione indipendente — un audit tecnicoprima di firmare, o nelle prime settimane di lavoro — costa una frazione del progetto e ti dice se le promesse stanno in piedi: se il preventivo è realistico, se l'approccio è sensato, se ci sono rischi nascosti.

È lo stesso principio di una perizia prima di comprare casa. Se stai costruendo da zero, vale la pena partire con la struttura giusta — ne parlo in creare un prodotto software. Se invece un progetto è già partito male, non sempre va buttato: spesso si può recuperare. E se vuoi allenare l'occhio nel frattempo, qui trovi come capire se il tuo sviluppatore fa bene il lavoro.

Continua a leggere

Vuoi una diagnosi del tuo caso?

30 minuti gratuiti per capire cosa serve. Risposta garantita entro 24 ore.