TL;DR — selezione fornitore in sintesi
Scegliere bene una società di sviluppo software si riduce a sei dimensioni. Valutate ogni candidato su questi criteri prima di confrontare i prezzi:
- Certificazioni: ISO 27001 (sicurezza delle informazioni) + SOC 2 Type II (enterprise US/UE) + DPA articolo 28 GDPR per i dati UE + adeguamento alle linee guida del Garante
- PI & NDA: NDA reciproco prima della condivisione delle specifiche; contratto che cede tutta la PI al cliente; codice ospitato nel repository del cliente
- Adeguatezza del portfolio: almeno 2 progetti nel vostro livello di complessità e settore, consegnati negli ultimi 24 mesi
- Modello di ingaggio: prezzo fisso (perimetro stabile, build piccolo) / T&M (prodotto evolutivo) / team dedicato (velocità continua)
- Referenze: 2–3 chiamate in diretta, non solo testimonianze scritte su un profilo
- Comunicazione: sovrapposizione di fuso orario, project manager nominato, percorso di escalation definito
Qualità vs prezzo basso: il vero compromesso
Il team offshore a 25 €/ora e il team nearshore senior a 65 €/ora promettono entrambi di costruire il vostro prodotto. La differenza emerge 6 mesi dopo. I fornitori che praticano tariffe inferiori al mercato in genere compensano:
- Affidando i progetti a ingegneri junior che richiedono supervisione intensiva
- Ricorrendo a subappaltatori non dichiarati, creando rischi sulla catena di titolarità della PI
- Omettendo i controlli di sicurezza, i log di audit e l’architettura di conformità (costosi da aggiungere a posteriori)
- Consegnando demo funzionanti che mascherano debito architetturale che richiederà riscritture in fase di scaling
Le ricerche Gartner sull’outsourcing IT mostrano costantemente che i tassi di rilavorazione negli impegni a basso costo si attestano in media al 20–40% delle ore totali. Su un progetto da 150.000 €, il 30% di rilavorazione è un extra di 45.000 € che non appare mai nella proposta. Aggiungete il costo di gestione che il vostro team sopporta nel supervisionare un impegno sottoperformante, e l’opzione “economica” spesso costa di più di un impegno ben strutturato con un partner senior.
Questo non significa che abbiate bisogno del fornitore più costoso sul mercato. Significa che il valore per la qualità è il corretto criterio di ottimizzazione, non la tariffa oraria più bassa. Per un confronto economico completo, consultate la nostra guida su outsourcing vs sviluppo interno.
Certificazioni: ISO 27001, SOC 2, GDPR e Garante
Le certificazioni non sono burocrazia — sono prove verificate in modo indipendente che un fornitore ha implementato controlli specifici. Ecco cosa significa ciascuna nella pratica:
ISO 27001
Lo standard internazionale per i sistemi di gestione della sicurezza delle informazioni (SGSI). Un fornitore certificato ISO 27001 ha superato un audit di terze parti delle sue politiche, controlli di accesso, procedure di risposta agli incidenti, gestione dei fornitori e sicurezza fisica/cloud. La certificazione è rilasciata da organismi accreditati e richiede audit di sorveglianza annuali. Per qualsiasi progetto che coinvolga dati personali, finanziari o regolamentati, ISO 27001 è il requisito minimo — non un differenziatore.
SOC 2 Type II
Uno standard di audit di origine statunitense, ora ampiamente richiesto dagli acquisti enterprise negli USA e in Europa. Il Type I è una valutazione puntuale; il Type II copre un periodo prolungato (tipicamente 6–12 mesi) ed è quindi molto più significativo. Un report SOC 2 Type II fornisce al vostro team di sicurezza prove dirette che i controlli erano effettivamente operativi nel tempo, non solo documentati. Consultate il nostro articolo su SOC 2 Type II per startup SaaS per il contesto di ciò che copre l’audit.
GDPR — articolo 28 DPA e Garante Privacy
Ai sensi del Regolamento UE 2016/679 (GDPR), se il vostro fornitore tratterà dati personali di residenti UE per vostro conto, è un “responsabile del trattamento” e l’articolo 28 richiede un accordo scritto di trattamento dati (DPA). Non è facoltativo. Per i trattamenti che coinvolgono dati di cittadini italiani, verificate la conformità alle linee guida e ai provvedimenti del Garante per la protezione dei dati personali. Il DPA deve specificare: finalità e durata del trattamento; categorie di dati; divulgazione dei subresponsabili; supporto ai diritti degli interessati; cancellazione/restituzione dei dati a fine contratto; e diritti di audit. Verificate il DPA prima dell’onboarding, non dopo una violazione dei dati.
Sicurezza, NDA e protezione IP
La protezione della PI e dei dati nell’outsourcing software è regolata dal diritto contrattuale, non dalla fiducia. Le seguenti protezioni contrattuali sono non negoziabili:
NDA reciproco prima della condivisione delle specifiche
Qualsiasi fornitore che si rifiuti di firmare un NDA prima di ricevere le vostre specifiche tecniche è un fornitore con cui non dovreste lavorare. Il NDA deve essere reciproco (proteggendo entrambe le parti), coprire segreti commerciali e know-how tecnico, e specificare la giurisdizione competente e i rimedi. Per i clienti italiani, il diritto italiano o quello di un’altra giurisdizione UE è standard; verificate che la giurisdizione competente corrisponda al vostro paese di operazione principale.
Clausola di cessione della PI
Il contratto deve includere una clausola di cessione che assegni esplicitamente alla vostra azienda tutta la proprietà intellettuale creata durante l’impegno. Confermate che questo si estenda a: codice sorgente, asset di design, documentazione, suite di test, script CI/CD e librerie personalizzate. Verificate anche che il fornitore non includa componenti open-source con licenza GPL nei deliverable senza divulgazione.
Proprietà del repository di codice
Tutto il codice deve essere committato in un repository di proprietà della vostra organizzazione e da essa controllato fin dal primo giorno dell’impegno. Non accettate mai un modello in cui il fornitore controlla il repository principale. Alla risoluzione del contratto, richiedete la consegna di tutte le credenziali, i token di accesso, le configurazioni dell’infrastruttura e gli script di deployment.
Divulgazione dei subappaltatori
Chiedete esplicitamente se qualsiasi parte del lavoro sarà eseguita da subappaltatori o freelance, e richiedete la divulgazione della loro identità. Ogni subappaltatore deve essere vincolato da termini NDA e di cessione della PI equivalenti. Nel contesto GDPR, i subresponsabili del trattamento devono essere menzionati nel DPA articolo 28. Il subappalto non dichiarato è una fonte comune di controversie sulla catena di titolarità della PI e di incidenti di sicurezza.
Referenze: casi di studio e chiamate clienti
Il portfolio e le referenze sono gli indicatori anticipatori più affidabili della qualità della consegna. Valutateli criticamente, non superficialmente.
Valutazione del portfolio
Cercate almeno due progetti nel vostro livello di complessità (semplice / medio / enterprise) e nel vostro settore verticale, consegnati negli ultimi 24 mesi. La recency è importante: un caso di studio fintech del 2018 non vi dice nulla sul team attuale, la toolchain o la postura di conformità del fornitore. Chiedete se gli ingegneri lead del progetto referenziato sono ancora in azienda.
Chiamate di referenza
Le testimonianze scritte su Clutch o sul sito del fornitore sono materiale di marketing selezionato. Le chiamate di referenza in diretta sono diverse. Richiedete al fornitore 2–3 referenze da progetti di complessità simile. Durante la chiamata, affrontate questi punti:
- Il progetto è stato consegnato nei tempi e entro il 15% del budget iniziale?
- Come ha gestito il fornitore i cambiamenti di perimetro e le sfide tecniche impreviste?
- Come era la comunicazione durante l’impegno — proattiva o reattiva?
- Cosa fareste diversamente se li ingaggiaste di nuovo?
- Li assumereste nuovamente per il vostro prossimo progetto?
Un fornitore che non riesce a fornire un cliente di referenza in diretta ha qualcosa da nascondere.
Confronto dei modelli di ingaggio
Il modello di ingaggio determina chi sopporta il rischio di perimetro, come sono strutturati i costi e quanto l’impegno è adattabile ai requisiti in evoluzione.
| Modello | Come funziona | Ideale per | Rischio |
|---|---|---|---|
| Prezzo fisso | Perimetro, tempi e prezzo concordati. Modifiche tramite change request formali. | MVP ben definito, build piccolo (< 75.000 €), requisiti stabili | Il fornitore gonfia il prezzo per assorbire il rischio di perimetro; l’ambiguità nelle specifiche genera controversie |
| Time & Materials | Fatturato sulle ore e materiali effettivi. Il perimetro può evolvere sprint per sprint. | Sviluppo prodotto iterativo, SaaS, continuità discovery-to-build | Sforamento del budget senza forte supervisione del PM; richiede forte coinvolgimento del cliente |
| Team dedicato | Ingegneri senior nominati integrati nel vostro team di delivery. Retainer mensile. | Sviluppo continuo, scaling di un prodotto esistente, impegno a lungo termine | Rischio di concentrazione della conoscenza; richiede forte ownership del prodotto internamente |
La maggior parte dei build di media dimensione beneficia di un approccio ibrido: una fase di discovery e architettura a prezzo fisso (4–6 settimane), seguita da sprint di delivery in T&M con cap mensili. Questo riduce il rischio di perimetro iniziale mantenendo la flessibilità di delivery. Per i prodotti a lungo termine, un modello di team dedicato con obiettivi trimestrali offre il miglior equilibrio tra velocità e responsabilità.
Segnali d’allarme da monitorare
I seguenti pattern, individualmente o in combinazione, indicano un rischio di consegna elevato:
- Prezzo fisso quotato senza fase di discovery — qualsiasi fornitore che quota un prezzo fisso fermo su un sistema di media o elevata complessità senza una fase di discovery di 4–6 settimane sta sottostimando o nascondendo ipotesi di perimetro che emergeranno come change request a metà progetto.
- Assenza di certificato ISO 27001 o SOC 2 aggiornato su richiesta — affermare la conformità senza poter produrre il certificato non è conformità.
- Referenze non contattabili direttamente — solo testimonianze scritte, nessun contatto diretto.
- Repository di codice controllato dal fornitore — se il fornitore possiede il repository, siete dipendenti da lui per accedere al vostro prodotto in qualsiasi momento, anche in caso di controversia.
- Politica di subappalto vaga — “potremmo utilizzare partner” senza divulgazione specifica è un rischio PI e un rischio di trattamento dati GDPR.
- Tempi irrealistici rispetto al perimetro — un team senior che consegna un build di 4 mesi in 6 settimane dovrebbe sollevare domande su cosa viene omesso (test, revisione della sicurezza, documentazione).
- Nessun project manager nominato — “il team sarà il vostro punto di contatto” è una struttura di comunicazione che si rompe sotto pressione.
- Eccessiva opacità sulle informazioni di base dell’azienda — i fornitori legittimi forniscono visura camerale, attestazioni assicurative e referenze finanziarie; l’eccessiva opacità è un segnale d’allarme nella due diligence.
15 domande da porre ad ogni fornitore software
Utilizzate queste domande nella revisione iniziale delle risposte al bando e nelle chiamate di follow-up. Le risposte deboli o evasive rivelano più delle risposte elaborate.
- Potete fornire il vostro certificato ISO 27001 aggiornato e, se applicabile, il vostro più recente report SOC 2 Type II?
- Disponete di un contratto di trattamento dati standard (DPA articolo 28 GDPR) e possiamo esaminarlo prima della firma?
- Chi sarà proprietario della proprietà intellettuale di tutti i lavori consegnati — specificamente codice sorgente, asset di design e documentazione?
- Qualsiasi parte del lavoro sarà eseguita da subappaltatori o freelance? In tal caso, chi sono e a quali termini NDA/PI sono vincolati?
- In quale repository sarà ospitato il nostro codice, e avremo accesso amministratore completo fin dal primo giorno?
- Potete fornire 2–3 clienti di referenza da progetti di complessità simile che possiamo contattare direttamente?
- Qual è il modello di ingaggio proposto per il nostro progetto e perché?
- Chi sarà il project manager nominato e qual è il vostro processo di escalation quando sorgono problemi?
- Qual è la seniority media del vostro team di ingegneri e qual è il vostro tasso di turnover attuale?
- Come gestite i cambiamenti di perimetro nell’ambito di un contratto a prezzo fisso?
- Quali pratiche di sicurezza sono integrate nel vostro processo di sviluppo (code review, SAST, dependency scanning, penetration testing)?
- Come gestite la localizzazione e il trattamento dei dati personali UE ai sensi del GDPR (Regolamento UE 2016/679) e delle linee guida del Garante?
- Quali sono i deliverable standard di passaggio a fine contratto (codice, credenziali, documentazione, trasferimento di conoscenze)?
- Quale SLA offrite per il supporto post-lancio e le correzioni di bug?
- Potete fornire una scomposizione dei costi completamente dettagliata per fase, con le ipotesi esplicite per ogni voce?
Modello di scorecard fornitore
Utilizzate questa matrice di punteggio ponderato per confrontare oggettivamente i fornitori prescelti. Regolate i pesi per riflettere le vostre priorità (i settori regolamentati dovrebbero pesare maggiormente la sicurezza; le startup possono pesare maggiormente la comunicazione e l’agilità).
| Dimensione | Peso | Punteggio 1–5 | Punteggio ponderato |
|---|---|---|---|
| Certificazioni tecniche (ISO 27001, SOC 2, DPA GDPR) | 20% | ||
| Adeguatezza del portfolio (livello di complessità & settore) | 20% | ||
| Qualità delle referenze (chiamate in diretta, recency) | 15% | ||
| PI & termini contrattuali | 15% | ||
| Modello di ingaggio & trasparenza dei prezzi | 15% | ||
| Comunicazione & compatibilità di fuso orario | 10% | ||
| Seniority e retention del team | 5% | ||
| Totale | 100% |
Un fornitore che ottiene meno di 3,0 sulle certificazioni o sui termini PI deve essere eliminato dalla selezione indipendentemente dal punteggio totale — questi sono criteri di soglia, non criteri di compromesso. Per il contesto di come si presenta il ciclo completo dell’impegno una volta selezionato un partner, consultate la nostra guida al processo di sviluppo software su misura.
FAQ
Come si sceglie una società di sviluppo software?
Iniziate con le certificazioni e l’adeguatezza normativa (ISO 27001, SOC 2, DPA GDPR, Garante). Esaminate il portfolio per progetti nel vostro livello di complessità e settore degli ultimi 24 mesi. Verificate contrattualmente la proprietà IP e i termini NDA. Confrontate i modelli di ingaggio rispetto alla stabilità del vostro perimetro. Conducete chiamate di referenza in diretta — non solo testimonianze scritte. Valutate i candidati su una matrice ponderata ed eliminate qualsiasi fornitore sotto soglia su certificazioni o termini PI, indipendentemente dal prezzo.
Quali certificazioni deve avere un fornitore software?
ISO 27001 è il minimo per qualsiasi impegno che coinvolga dati sensibili. SOC 2 Type II è standard per gli acquisti enterprise US. Il DPA articolo 28 GDPR (Regolamento UE 2016/679) è obbligatorio per il trattamento di dati personali UE. Per i trattamenti che coinvolgono dati di cittadini italiani, verificate la conformità alle linee guida del Garante per la protezione dei dati personali. Richiedete il certificato o il report di audit aggiornato, non un’affermazione di marketing di “conformità”.
Come proteggere la PI e i dati in caso di outsourcing?
Quattro protezioni contrattuali sono non negoziabili: NDA reciproco prima della condivisione delle specifiche; clausola di cessione PI che trasferisce tutta la PI creata alla vostra azienda; codice ospitato nel vostro repository fin dal primo giorno; e un DPA articolo 28 GDPR se sono coinvolti dati personali UE. Richiedete inoltre la divulgazione esplicita di qualsiasi subappaltatore e confermate che siano vincolati da termini equivalenti. Fate esaminare tutte le clausole dal vostro consulente legale — non solo il SOW — prima della firma.
Prezzo fisso o time & materials per lo sviluppo software?
Il prezzo fisso è appropriato per build piccoli e ben definiti e stabili (tipicamente inferiori a 75.000 €). Il time & materials è più adatto a prodotti iterativi ed evolutivi in cui i requisiti cambieranno durante la delivery. Un retainer di team dedicato è adatto allo sviluppo continuo a lungo termine. L’approccio più pragmatico per i build di media dimensione è una fase di discovery a prezzo fisso (4–6 settimane) seguita dalla delivery in T&M, che combina chiarezza del perimetro e flessibilità di delivery.
Quali sono i segnali d’allarme in un’agenzia di sviluppo software?
Segnali chiave: prezzo fisso quotato senza fase di discovery; assenza di certificato ISO 27001 o SOC 2 aggiornato; referenze non contattabili direttamente; repository di codice controllato dal fornitore; divulgazione vaga dei subappaltatori; tempi irrealistici rispetto al perimetro; nessun project manager nominato; e eccessiva opacità sullo stato legale e finanziario dell’azienda.
Come verificare le referenze di una società di sviluppo software?
Richiedete 2–3 contatti di referenza in diretta da progetti di complessità simile consegnati negli ultimi 18 mesi. Chiamateli direttamente. Chiedete se il progetto è stato consegnato nei tempi e nel budget, come sono stati gestiti i cambiamenti di perimetro e i problemi, se riassumerebbero il fornitore, e cosa farebbero diversamente. Incrociate con le recensioni su Clutch o G2, ma trattate le chiamate in diretta come il segnale primario — le testimonianze scritte selezionate non sono un sostituto.
Ultimo aggiornamento: 8 giugno 2026. I requisiti di certificazione riflettono ISO/IEC 27001:2022, AICPA SOC 2 e il Regolamento UE 2016/679 (GDPR) in data di pubblicazione. I requisiti legali variano per giurisdizione; consultate un consulente legale qualificato per la revisione contrattuale.
