Quando si avvia un progetto software, molto tempo viene dedicato alla scelta della tecnologia giusta: quale framework, quale database, quale piattaforma cloud. È una discussione legittima, ma spesso oscura la decisione che conta davvero: chi costruirà il sistema. La scelta del partner tecnologico è più determinante di qualsiasi stack tecnico — perché una squadra capace porta a termine anche progetti complessi con strumenti imperfetti, mentre una squadra sbagliata riesce a rovinare anche il progetto più semplice con le tecnologie migliori.
Ecco come orientarsi in una scelta che ha conseguenze che si faranno sentire per anni.
Le tre opzioni principali
Il freelance. Massima flessibilità, costo generalmente inferiore, possibilità di lavorare con persone molto specializzate. Il rischio principale è la dipendenza da una singola persona: se è impegnata su altri progetti, se si ammala, se decide di cambiare lavoro, il tuo progetto si ferma. Funziona bene per progetti delimitati, con scope chiaro, dove non è richiesta continuità operativa a lungo termine.
L'agenzia generalista. Ampia gamma di competenze, struttura organizzativa che riduce il rischio di dipendenza da singoli. Il limite è spesso la mancanza di specializzazione: un'agenzia che fa siti web, app mobile, e-commerce e campagne Google difficilmente ha una profondità vera su nessuno di questi ambiti. Per progetti di una certa complessità, la generalità diventa un problema.
La software house specializzata. Focale su un dominio specifico — applicazioni web, SaaS, software gestionali — con processi rodati e competenze verticali. Ha meno flessibilità sui formati contrattuali rispetto a un freelance, e spesso ha costi più alti. Ma per progetti che richiedono solidità architetturale, manutenzione nel tempo e scalabilità, è spesso la scelta più ragionevole.
Le domande da fare in una prima call
La prima conversazione con un potenziale partner è preziosa non per quello che ti raccontano, ma per le domande che ti fanno. Un buon partner vuole capire il tuo business prima di parlare di tecnologia. Presentarsi con un brief tecnico già strutturato accelera questa fase e rivela subito la qualità del partner. Se nella prima mezz'ora si parla solo di React, Node.js e architetture cloud senza che nessuno abbia chiesto cosa fa la tua azienda, è un segnale.
Oltre ad ascoltare, fai tu stesso queste domande:
"Come gestite i cambiamenti in corso d'opera?" I requisiti cambiano sempre. La risposta a questa domanda rivela molto sulla maturità del processo: chi ha una risposta chiara ha già affrontato il problema. Chi dice "dipende" o cambia discorso probabilmente non ha un processo definito.
"Chi sarà il mio interlocutore quotidiano?" Vuoi sapere se il tuo contatto principale sarà un account commerciale o un tecnico che conosce il progetto. La differenza è enorme nella qualità della comunicazione.
"Come documentate il lavoro?" La documentazione è ciò che rimane quando il rapporto finisce. Un codice non documentato è un codice che appartiene a chi l'ha scritto, non a te.
"Cosa succede se terminiamo il rapporto?" Puoi prendere il codice e continuare con qualcun altro? Hai accesso a tutti i repository, i server, le credenziali? La risposta a questa domanda definisce quanto sei libero.
Il segnale d'allarme più sottile: un partner che non ti fa domande difficili nella fase iniziale non ti farà domande difficili neanche durante lo sviluppo. Le domande scomode — "sei sicuro che serva questa funzionalità?", "hai considerato questo rischio?" — sono il valore aggiunto di un partner capace. Un sì a tutto non è rassicurante. È preoccupante.
I segnali d'allarme
Promettono tutto subito. Timeline irrealisticamente brevi, costi molto al di sotto della media di mercato senza una spiegazione concreta, funzionalità illimitate per un budget fisso. Ogni promessa che sembra troppo bella è un rischio che si trasferisce su di te. Un partner serio propone invece un rilascio in fasi, con milestone verificabili.
Non fanno domande sul tuo business. Se un preventivo arriva senza che nessuno abbia capito come funziona la tua azienda, quel preventivo è costruito su assunzioni. Le assunzioni costano.
Non hanno niente da mostrare. Portfolio assente, nessun caso studio, nessuna referenza verificabile. Un team che costruisce software professionale ha sempre qualcosa da mostrare — anche se anonimizzato per motivi di riservatezza.
Prezzi troppo bassi senza spiegazione. Lo sviluppo software ha un costo reale. Chi offre prezzi molto al di sotto del mercato o sta sottovalutando il progetto (e lo scoprirete a metà lavoro) o sta tagliando su qualità, sicurezza o manutenibilità.
Come valutare una proposta tecnica
Una proposta seria non è solo un prezzo. È un documento che descrive il perimetro del lavoro — cosa è incluso e, soprattutto, cosa non è incluso. Le assunzioni su cui è basata la stima. I rischi identificati. Le fasi e le milestone. Il processo di consegna.
Se una proposta è composta solo da un totale e una lista di funzionalità, manca di tutto ciò che serve per valutarla davvero. Un partner affidabile ti mette in grado di capire cosa stai comprando — non solo quanto stai pagando.