Come scegliere una software house per la tua startup: criteri, domande e segnali d'allarme

Software house

Azienda che progetta, sviluppa e spesso mantiene software su commissione: web app, app mobile, piattaforme SaaS, integrazioni tra sistemi. Rispetto a un freelance mette a disposizione un team con ruoli diversi (sviluppo, design, test, gestione del progetto); rispetto a un'agenzia di comunicazione, il suo prodotto è codice che funziona.

Cosa guardare in una software house prima del prezzo?

Prima del prezzo guarda se il fornitore capisce il problema che vuoi risolvere e se sa dirti cosa non costruire. Per una startup in fase idea o pre-seed il rischio più grande non è un bug: è spendere il budget su funzioni che nessuno userà.

Nello stesso studio il 70% cita la fine della liquidità, che CB Insights descrive come la causa finale più che quella di fondo. Un buon partner tecnico lavora su entrambi i fronti: ti chiede quali ipotesi vuoi verificare, propone una prima versione più piccola e ti dice quando una funzione può aspettare. Se nella prima call si parla solo di framework e giornate uomo, manca un pezzo. E se l'idea non è ancora validata, parti da lì: come validare un'idea di business prima di firmare un contratto di sviluppo.

Quali criteri usare per confrontare più software house?

Usa criteri che puoi verificare con una domanda e una prova, non con una promessa. La griglia qui sotto l'abbiamo costruita noi pensando a ciò che conta davvero sei mesi dopo il lancio, quando il fornitore lo hai già scelto e cambiarlo costa caro.

Sulla qualità esiste un riferimento pubblico utile anche a chi non scrive codice: le metriche DORA, frutto di un programma di ricerca pluriennale sulla consegna del software, misurano ad esempio la frequenza dei rilasci, il tempo che una modifica impiega ad arrivare in produzione e la quota di rilasci che richiedono un intervento urgente. Non serve che il fornitore le misuri tutte. Serve che sappia rispondere quando gli chiedi come tiene sotto controllo la stabilità di ciò che rilascia.

Quali domande fare a una software house prima di firmare?

Fai domande che costringono a risposte concrete: chi, quando, dove, con quali prove. Questa è la nostra lista, da mandare per email identica a ogni fornitore che stai valutando:

1. Chi è il referente unico del progetto e quante ore a settimana ci dedica?
2. Posso vedere un prodotto simile già online, o parlare con chi l'ha commissionato?
3. Come stimate: a corpo, a tempo o misto? Cosa succede se il perimetro cambia a metà?
4. Dove gira l'applicazione e chi paga e controlla l'hosting?
5. Come trattate i dati personali degli utenti? Firmate un accordo come responsabili del trattamento?
6. Quali componenti open source o di terze parti userete, e con quali licenze?
7. Cosa mi consegnate alla fine: codice, documentazione, credenziali, istruzioni per rilasciare?
8. Se domani volessi cambiare fornitore, quanto tempo servirebbe a un altro team per subentrare?

La quinta domanda non è burocrazia. Se il fornitore tratta dati personali per conto della tua startup, l'art. 28 del GDPR chiede un contratto che ne fissi oggetto, durata, finalità e obblighi. Un fornitore abituato a lavorare bene te lo propone senza che tu lo chieda.

Quali sono i segnali d'allarme nella scelta di un fornitore?

Il segnale più chiaro è un preventivo che arriva prima delle domande. Gli altri sono meno evidenti ma altrettanto utili:

• Tutto incluso, tutto subito: nessuna funzione viene messa in discussione, il perimetro cresce invece di stringersi.
• Account a nome del fornitore: dominio, hosting, repository o account degli store intestati a loro «per comodità».
• Nessuna demo intermedia: il prodotto lo vedrai «alla fine».
• Chi vende non è chi lavora: non sai chi scriverà il codice e nessuno te lo dice.
• Contratto muto su proprietà del codice, licenze delle componenti di terzi e passaggio di consegne.
• Garanzie impossibili: tempi certi su un perimetro che non è ancora definito, o risultati di business promessi.

Cosa deve dire il contratto su codice e account?

Il contratto deve dire per iscritto che i diritti di utilizzazione economica sul codice sviluppato per te passano alla tua società, e da quando. La legge sul diritto d'autore protegge il software e chiede che la cessione di questi diritti sia provata per iscritto (art. 110 della legge 633/1941): una stretta di mano non basta. Le differenze tra dipendenti e fornitori esterni, e le clausole da controllare, sono nella guida sulla proprietà del codice nel contratto di sviluppo.

Oltre al codice conta il controllo operativo. Repository, hosting, dominio, account degli store, servizi di pagamento e strumenti di analisi dovrebbero essere intestati alla tua società, con il fornitore invitato come collaboratore. È la differenza tra possedere un prodotto e averne solo un contratto. Questa guida non è una consulenza legale: per il testo definitivo rivolgiti a un avvocato.

Come confrontare preventivi molto diversi tra loro?

Confronta il perimetro, non il totale: due preventivi lontani di solito descrivono due prodotti diversi. Il prezzo lo fanno le piattaforme (solo web, o anche iOS e Android), le integrazioni con altri sistemi, il livello di design, i dati da migrare, i requisiti di sicurezza e la manutenzione dopo il lancio. Per capire come pesano questi fattori su una prima versione leggi quanto costa sviluppare un MVP.

Serve davvero una software house, o basta altro?

Dipende da cosa devi costruire e da chi lo guiderà dopo. Se la domanda vera è quale modello scegliere, il confronto è nella guida agenzia, freelance o team interno. Se ti manca soprattutto qualcuno che prenda le decisioni tecniche, valuta un fractional CTO. E se pensi di partire con uno strumento visuale, leggi prima quando conviene no-code o sviluppo su misura.