Scegliere il partner di sviluppo sbagliato è il singolo errore che fa fallire la maggior parte dei progetti di software custom delle PMI italiane. Non è la tecnologia, non è il budget, non è la dimensione del partner — è il mismatch tra quello che il partner sembrava in pre-vendita e quello che è risultato in delivery.
Questa checklist serve esattamente a quello: identificare il mismatch prima del contratto, quando il costo di cambiare idea è zero. Le 15 domande coprono sei aree (track record, IP, tecnologia, delivery, supporto, finanza) e sono pensate per essere fatte prima della firma, idealmente al secondo o terzo colloquio con il partner — quando ha già capito di cosa si tratta ma non hai ancora preso impegni economici.
Per ogni domanda: il perché è importante, cosa cercare nella risposta del partner, i red flag da cui scappare. Per un range di costo del progetto puoi usare in parallelo il configuratore software su misura. Per il framework di calcolo TCO/ROI vedi il pillar ROI software su misura: TCO a 3 anni. Per la decisione build vs buy vedi il confronto Software su misura vs SaaS verticale.
Indice
- Area 1 — Track record e affidabilità (domande 1-3)
- Area 2 — Proprietà intellettuale e contratti (domande 4-6)
- Area 3 — Tecnologia e architettura (domande 7-9)
- Area 4 — Processo di delivery (domande 10-11)
- Area 5 — Supporto e manutenzione (domande 12-13)
- Area 6 — Finanza e modello commerciale (domande 14-15)
- Come usare la checklist in pratica
Area 1 — Track record e affidabilità (domande 1-3)
L’area più sottovalutata. Le aziende guardano portfolio e case study sui siti web, ma raramente verificano la sostanza dietro. Tre domande che cambiano la conversazione.
Domanda 1 — “Mi presenti 3 clienti analoghi al mio caso che posso chiamare?”
Perché è importante: il portfolio sul sito è curato per impressionare; le reference verificabili sono la prova che il partner ha davvero consegnato e non solo iniziato.
Cosa cercare nella risposta: il partner deve nominare almeno 2-3 clienti con dimensione e settore confrontabili al tuo (non solo “tutti i nostri clienti vanno bene”). Idealmente fornisce contatto diretto, oppure organizza una call a tre. Le reference servite servono a chiedere tre cose specifiche: il progetto è andato live nei tempi? Il budget finale è stato vicino al preventivo iniziale? Lo userebbero di nuovo?
Red flag: “Per privacy non possiamo darti contatti diretti.” Tradotto: il cliente reference o non esiste, o non parla bene del partner. Le reference verificabili sono la spina dorsale del B2B: chiunque opera seriamente in questo mercato ha 5-6 clienti felici di prendere una chiamata di 15 minuti.
Domanda 2 — “Cosa è successo nei vostri ultimi 2 progetti che NON sono andati come previsto?”
Perché è importante: nessun partner di sviluppo serio ha solo progetti perfetti. La capacità di raccontare onestamente cosa è andato storto è un proxy forte della maturità operativa. Un partner che dice “non abbiamo mai avuto un problema” sta mentendo, oppure non ha mai consegnato.
Cosa cercare nella risposta: aspettati una risposta articolata: cosa è successo, perché, come è stato gestito, cosa hanno imparato. Bonus se il partner racconta un fallimento parziale (ritardo significativo, scope ridotto, cambio di tecnologia in corso) — significa che hanno la pelle abbastanza dura per essere onesti.
Red flag: “Tutti i nostri progetti sono andati benissimo.” Oppure: aneddoti generici e impersonali (“a volte ci sono ritardi”). Significa che non hanno ancora consegnato abbastanza per avere storie reali, o stanno nascondendo qualcosa.
Domanda 3 — “Quanti dei vostri clienti sono ancora attivi dopo 3 anni dal primo go-live?”
Perché è importante: la durata della relazione cliente-partner è il KPI più importante che non vedi mai nei siti web. Un software custom mantiene il suo valore solo se evolve nel tempo, e questa evoluzione richiede una relazione cliente-partner che continui. Se i clienti vanno tutti via dopo 12-18 mesi, c’è un problema strutturale.
Cosa cercare nella risposta: un numero specifico (es. “circa il 70% dei clienti che abbiamo onboardato 3+ anni fa è ancora attivo”) e una motivazione. Idealmente esempi di clienti storici con cui sono ancora a regime.
Red flag: “La maggior parte.” Oppure: “Non lo misuriamo.” Significa che il partner pensa al progetto come a un one-shot e non come a una relazione di lungo termine. Va benissimo per chi vuole comprare e scappare; pessimo per chi compra software che dovrà evolvere.
Area 2 — Proprietà intellettuale e contratti (domande 4-6)
L’area dove i clienti perdono più valore senza accorgersene. Il contratto standard di molti partner contiene clausole che limitano i diritti del cliente in modi che diventano evidenti solo dopo 2-3 anni — quando è troppo tardi.
Domanda 4 — “Il codice sorgente sarà di mia proprietà al saldo finale?”
Perché è importante: la proprietà del codice è il discrimine fra “ho comprato un software” e “ho noleggiato un servizio di sviluppo”. Senza la cessione integrale dei diritti di sfruttamento economico, il software che hai pagato resta tecnicamente in licenza al partner — non puoi farlo evolvere altrove, non puoi rivenderlo, non puoi metterlo in escrow.
Cosa cercare nella risposta: cessione integrale dei diritti di sfruttamento economico al saldo finale, comprensiva di codice sorgente, documentazione tecnica, asset grafici, eventuali artefatti DevOps (script CI/CD, file Infrastructure-as-Code). Eccezioni accettabili: librerie open source (restano sotto licenza propria), framework e tool generali del partner (restano del partner), know-how non-tangibile (resta del partner).
Red flag: “Il codice è nostro ma tu hai una licenza d’uso.” Oppure: “Cediamo il codice ma non la documentazione tecnica.” Sono varianti di vendor lock-in mascherato. Per il significato preciso vedi anche glossario sviluppo software custom.
Domanda 5 — “Per progetti business-critical accettate clausola di escrow del codice presso terza parte?”
Perché è importante: l’escrow del codice deposita il codice sorgente presso una terza parte neutra (notaio o servizio dedicato). In caso di cessazione attività del partner o di rottura contrattuale, il cliente accede al codice senza dover citare in giudizio. È la tutela più robusta per software business-critical.
Cosa cercare nella risposta: disponibilità a inserire la clausola in contratto, indicazione operativa di costo (tipicamente 500-1.500 €/anno per il servizio di escrow), partner notarile o servizio dedicato accettato.
Red flag: rifiuto secco, oppure “non l’abbiamo mai fatto e preferiremmo non iniziare”. Per progetti non-critical può essere accettabile, ma su progetti business-critical (gestionale interno, portale clienti, software mission-critical) è un grosso flag.
Domanda 6 — “Quali sono le clausole standard del vostro contratto su limitazione di responsabilità, garanzie e SLA?”
Perché è importante: i contratti dei partner di sviluppo hanno spesso clausole molto restrittive che limitano la responsabilità del partner a piccoli multipli del valore del contratto. È accettabile per il rischio “perdita di profitto indiretto” (sempre escluso, su qualsiasi contratto B2B), ma diventa inaccettabile per perdite di dati o disservizi prolungati causati da bug del software.
Cosa cercare nella risposta: garanzia di funzionamento secondo specifica per 6-12 mesi dal go-live, correzione bug critici gratuita nel periodo di garanzia, SLA esplicito sui tempi di reazione (es. bug bloccante: reazione entro 4 ore lavorative).
Red flag: “Non diamo nessuna garanzia, il software è as-is.” Tradotto: stiamo per consegnarti del codice che potrebbe non funzionare e tu non puoi rivendicare nulla. Pessimo segno.
Area 3 — Tecnologia e architettura (domande 7-9)
Tre domande che servono a distinguere chi sa quello che sta facendo da chi sta improvvisando. Anche se non sei tecnico, le risposte si valutano per consistenza interna e capacità di articolare le scelte.
Domanda 7 — “Quale stack tecnologico proponete per il mio caso e perché?”
Perché è importante: lo stack tecnologico è la scelta architetturale che ti accompagna per i prossimi 5-7 anni. Stack mainstream (.NET, Node.js, Python con framework popolari) significa che fra 3 anni potrai trovare altri sviluppatori per evolverlo. Stack esoterico (linguaggi di nicchia, framework proprietari del partner, tecnologie obsolete) significa lock-in tecnologico permanente.
Cosa cercare nella risposta: stack mainstream giustificato in base al tuo caso. Esempi accettabili: ”.NET 9 perché siete Microsoft-centric e abbiamo competenze profonde sul vostro stack”, “Node.js + React per cross-platform veloce”, “Python perché serve integrare modelli ML pre-trained”. La risposta deve essere giustificata, non default.
Red flag: tecnologia esoterica o proprietaria del partner (“usiamo il nostro framework interno”), oppure stack obsoleto (Visual Basic .NET, AngularJS, jQuery come framework principale, PHP <7).
Domanda 8 — “Dove ospitate il software? Quale cloud, quale region?”
Perché è importante: la scelta del cloud determina costi operativi, performance, compliance e flessibilità. La risposta del partner ti dice anche quanto è strutturato sull’operations (non solo sviluppo).
Cosa cercare nella risposta: cloud mainstream (Azure, AWS, GCP) con region Italia o EU per i dati. Idealmente più opzioni con motivazioni: “Azure Italy North se siete Microsoft 365 e volete residenza dati Italia, AWS eu-south-1 se preferite ecosistema Linux/serverless, on-premise se avete vincoli regolatori specifici”. Per la scelta dettagliata vedi il confronto Azure vs AWS per software custom.
Red flag: “Ospitiamo sui nostri server.” Tradotto: dipendi al 100% dal partner anche per il running del software. Sotto provider cloud serio. Oppure: “Decidiamo dopo.” La scelta di hosting va fatta in fase di architettura, non a delivery.
Domanda 9 — “Come gestite la sicurezza del software? Fate vulnerability scan? Penetration test?”
Perché è importante: la sicurezza non è opzionale. Un software custom non sicuro è una porta aperta. NIS2 lo richiede esplicitamente, GDPR lo richiede implicitamente. La qualità della risposta è un proxy forte della maturità tecnica del partner.
Cosa cercare nella risposta: vulnerability scan automatici sulle dipendenze (npm audit, dotnet list package vulnerable, dependabot/snyk attivo), code review obbligatoria, encryption at rest e in transit by default, gestione secret tramite key vault del cloud (non hardcoded), best practice OWASP applicate. Per progetti business-critical: penetration test esterno annuale.
Red flag: “La sicurezza la gestiremo se serve” oppure “facciamo tutto manualmente”. I tool moderni di security scanning sono gratuiti o quasi — non averli attivi è inaccettabile nel 2026.
Area 4 — Processo di delivery (domande 10-11)
Come il partner consegna è importante tanto quanto cosa consegna. Due domande che separano partner agili da partner waterfall.
Domanda 10 — “Come gestite il progetto dal punto di vista metodologico? Sprint? Demo regolari?”
Perché è importante: lo sviluppo software è inevitabilmente esposto al cambiamento. Un processo che pianifica una specifica all’inizio e consegna 9 mesi dopo è strutturalmente fragile — quando consegnano, il business è già cambiato e quello che hanno costruito non serve più del 100%. Un processo agile con sprint regolari permette di adattarsi al cambiamento in corso.
Cosa cercare nella risposta: sprint di 1-2 settimane, demo regolari al cliente al termine di ogni sprint, possibilità di rivedere priorità sprint per sprint, backlog visibile e gestito insieme al cliente. Tool di project management condiviso (Jira, Azure DevOps, Linear, GitHub Projects).
Red flag: “Vi consegniamo il software finito alla fine.” Approccio waterfall puro, garantisce mismatch fra quello che speravate e quello che ricevete. Oppure: agile dichiarato ma senza demo regolari e senza coinvolgimento del cliente — è teatrino agile.
Domanda 11 — “Come gestite cambi di scope o richieste di feature extra durante il progetto?”
Perché è importante: il primo cambio di scope arriva tipicamente nelle prime 4-6 settimane di sviluppo. Come viene gestito determina se il progetto resta sano o degenera in tensione cliente-partner permanente.
Cosa cercare nella risposta: processo chiaro di change request — la richiesta viene valutata in giornate/settimane aggiuntive, il cliente decide se procedere con maggiorazione o se de-priorizzare altre feature equivalenti. Trasparenza sui costi incrementali, nessun “vedremo poi”.
Red flag: “Tutto è incluso, non si fanno extra.” Significa che il partner ha sovra-stimato il preventivo iniziale e poi pacchetta dentro qualsiasi richiesta nuova, sacrificando qualità. Oppure: “Per ogni cambio rifacciamo il contratto.” Procedura burocratica che blocca progetti agili.
Area 5 — Supporto e manutenzione (domande 12-13)
Spesso trascurato in fase pre-vendita perché “ci penseremo dopo il delivery”. Errore. Il modello di supporto post-delivery va concordato nel contratto iniziale, altrimenti si scopre dopo che le tariffe per supporto/evolutiva sono diverse da quelle dello sviluppo iniziale.
Domanda 12 — “Qual è il vostro modello di supporto post-delivery? SLA, costi, escalation?”
Perché è importante: dopo il go-live il software entra in fase ricorrente. Bug emergono, dipendenze pubblicano patch di sicurezza, utenti chiedono modifiche. Senza un contratto di supporto strutturato il cliente paga ogni richiesta a tariffa giornaliera, accumulando costi imprevedibili.
Cosa cercare nella risposta: contratto di manutenzione esplicito (mensile o annuale) con SLA definiti: tempi di reazione per bug bloccanti/normali/minori, ore di manutenzione evolutiva incluse, canale di escalation. Tariffe trasparenti per overage. Costo tipico per PMI: 10-20% del costo di sviluppo iniziale all’anno.
Red flag: “Fattureremo a giornata quando ci chiamerete.” Modello a chiamata, imprevedibile. Per progetti business-critical inaccettabile.
Domanda 13 — “Se l’unica persona del vostro team che conosce il mio progetto se ne va, cosa succede?”
Perché è importante: il “fattore Bus” (cosa succede se il sviluppatore principale è investito da un autobus) è un rischio reale dei partner piccoli, dove il singolo sviluppatore conosce il software meglio dell’azienda intera.
Cosa cercare nella risposta: almeno 2 sviluppatori coinvolti su ogni progetto (anche se uno a tempo parziale), documentazione tecnica mantenuta in repository condiviso, on-boarding di nuovo sviluppatore stimato in 1-2 settimane per progetto medio. Bonus: process di hand-over documentato.
Red flag: “Tutti i nostri sviluppatori sono insostituibili.” Tradotto: dipendi da una singola persona. Se il singolo dev se ne va, sei senza partner per mesi.
Area 6 — Finanza e modello commerciale (domande 14-15)
L’area da affrontare per ultima, ma non meno importante. Due domande che evitano le sorprese contrattuali più frequenti.
Domanda 14 — “Qual è il vostro modello commerciale: fixed price, time & material, ibrido?”
Perché è importante: il modello commerciale determina chi porta il rischio in caso di scope creep o di stime errate.
Cosa cercare nella risposta:
- Fixed price funziona bene per scope ben definito (MVP, prima release con specifica chiara). Il rischio è del partner, ma il cliente paga un premio di sicurezza (15-25% sopra time & material teorico) e perde flessibilità sui cambi.
- Time & material funziona bene per progetti esplorativi o evolutivi continui. Il rischio è del cliente, ma c’è massima flessibilità.
- Ibrido: fixed price per la prima release + time & material per evolutive successive. È il modello più frequente per PMI italiane.
Il partner serio sa proporre il modello giusto per il tuo caso, non solo “quello che usiamo sempre”.
Red flag: solo fixed price su scope vago — il partner sta firmando un contratto in perdita oppure ha sovra-stimato. Solo time & material su scope ben definito — il partner ti scarica tutto il rischio.
Domanda 15 — “Quale è la struttura tipica di pagamento? Cosa succede se il progetto si allunga rispetto al previsto?”
Perché è importante: il pagamento al milestone è lo standard di settore. La struttura giusta protegge entrambi: il cliente paga solo per quello che riceve, il partner ha cassa per continuare a lavorare.
Cosa cercare nella risposta: pagamento a milestone (es. 30% al kick-off, 40% al delivery MVP, 30% al go-live finale), penali simboliche per ritardi gravi (>2 settimane su milestone definito), bonus opzionale per consegna anticipata. Possibilità di rivedere milestone se lo scope cambia.
Red flag: “100% in anticipo.” Inaccettabile per progetti di qualsiasi dimensione. Oppure “Pagamento a tempo, fattura mensile a consuntivo senza tetto” — pericoloso senza una stima totale di riferimento.
Come usare la checklist in pratica
Tre consigli operativi per applicare la checklist senza trasformare il colloquio in interrogatorio.
1. Non leggere le 15 domande in sequenza. Spalmale su 2-3 colloqui pre-vendita in modo naturale. Le domande dell’area 1 (track record) le fai nel primo colloquio, quelle delle aree 3-4 (tecnologia, delivery) nel secondo, quelle delle aree 5-6 (supporto, finanza) nel terzo o nel passaggio contrattuale.
2. Confronta 3 partner sulla stessa griglia. La checklist diventa utile quando viene usata come griglia di valutazione comparativa. Crea uno spreadsheet con le 15 domande in riga e i partner in colonna, e assegna un punteggio 1-5 a ogni risposta. I partner mediocri spesso passano la valutazione individuale ma si rivelano deboli rispetto al confronto.
3. Fidati delle reference, non solo delle risposte. Le risposte di pre-vendita possono essere ben preparate. Le reference sono l’unico fact-check vero. Investi 30 minuti nel chiamare 2-3 reference per ogni partner finalista — è il singolo investimento di tempo con il ROI più alto in tutto il processo di selezione.
Conclusione
La selezione del partner è il momento di leva più alto di un progetto di software custom. Costa 4-6 ore di tempo, blocca o sblocca decine di migliaia di € di progetto, determina la qualità della relazione per i prossimi 3-5 anni.
Se hai letto fin qui hai probabilmente uno o più partner sul tavolo. Tre passi pratici:
- Range di prezzo: usa il configuratore software su misura per validare che i preventivi che ricevi siano nell’ordine di grandezza ragionevole.
- Decisione build vs buy: leggi Software su misura vs SaaS verticale per confermare che custom sia la scelta giusta.
- Business case: usa il framework ROI software su misura: TCO a 3 anni per costruire il calcolo finanziario interno.
Quando hai la rosa finale dei partner, scrivici se vuoi confrontare un quarto preventivo (il nostro). Il primo colloquio parte sempre dal contesto che hai già raccolto, non dalle scoperte di base.