Cinque domande da fare prima di assumere uno sviluppatore freelance

Le domande che separano un buon inizio da un progetto problematico

Prima di firmare un contratto o accettare un preventivo, ci sono domande che possono evitare mesi di frustrazione. Non sono domande trabocchetto: sono domande che un freelance serio si aspetta e a cui risponde volentieri. Anzi, la qualità delle risposte è uno dei migliori indicatori per capire con chi stai per lavorare.

Ho visto progetti partire male non per incompetenza tecnica, ma per aspettative disallineate. Il cliente si aspettava consegne settimanali, il freelance lavorava in modalità "consegna finale". Il cliente pensava che la manutenzione fosse inclusa, il freelance considerava il progetto chiuso al deploy. Queste incomprensioni si prevengono con le domande giuste al momento giusto.

Le cinque domande essenziali

1. Come organizzi il lavoro?

Questa domanda rivela più di qualsiasi portfolio. Iterazioni brevi o consegna unica? Strumenti condivisi o aggiornamenti via email? Il metodo di lavoro conta quanto la competenza tecnica. Un sviluppatore freelance con un processo strutturato — board condivisa, demo periodiche, comunicazione asincrona organizzata — è uno che ha gestito abbastanza progetti da sapere cosa funziona e cosa no.

Approfondisci chiedendo: con quale frequenza riceverò aggiornamenti? Usiamo un tool condiviso per tracciare il progresso? Come gestisci le priorità quando hai più clienti contemporaneamente? Le risposte concrete valgono più delle promesse generiche.

2. Posso vedere codice che hai scritto?

Un portfolio con screenshot è diverso da un repository con codice reale. Il codice racconta più di qualsiasi presentazione: come è organizzato, se ci sono test, se i commit sono chiari, se la documentazione esiste. Non serve essere tecnici per valutare un repository — basta guardare se è ordinato, se i file hanno nomi comprensibili, se c'è un README che spiega come far partire il progetto.

Se il freelance non ha codice pubblico, chiedi un code sample o un progetto demo. Un professionista che scrive buon codice è orgoglioso di mostrarlo. Chi si rifiuta potrebbe avere ragioni legittime (NDA, codice proprietario), ma dovrebbe poter offrire alternative: un progetto personale, un contributo open source, un caso studio tecnico dettagliato.

3. Cosa succede dopo il lancio?

Questa è la domanda che la maggior parte dei clienti dimentica di fare — e che genera il maggior numero di problemi post-progetto. Manutenzione inclusa? Supporto a ore? Passaggio di consegne a un altro team? Sapere cosa succede dopo evita la situazione in cui il sito è online, qualcosa si rompe e non c'è nessuno a cui rivolgersi.

Un buon freelance propone attivamente un piano post-lancio: un pacchetto ore mensile per piccoli interventi, aggiornamenti di sicurezza, monitoring. Non perché vuole vendere servizi in più, ma perché sa che un'applicazione senza manutenzione è un problema che aspetta di esplodere.

4. Come gestisci i cambiamenti di requisiti?

I requisiti cambiano sempre. Sempre. Un processo chiaro per gestire le modifiche è più importante di un preventivo perfetto. Cerca un freelance che abbia un metodo: change request documentata, stima dell'impatto su tempi e costi, approvazione prima di procedere. Questo protegge entrambi: il cliente sa quanto costerà la modifica, il freelance sa che il lavoro extra è riconosciuto.

Diffida di chi dice "non c'è problema, lo aggiungiamo". Senza un processo, le modifiche si accumulano, i tempi slittano e alla fine nessuno sa più cosa era nel preventivo originale e cosa è stato aggiunto dopo. Questo è il terreno fertile per le dispute.

5. Quali sono i rischi di questo progetto?

Un freelance che dice "nessuno" non sta pensando abbastanza. Ogni progetto ha rischi: integrazioni complesse con sistemi che non si controllano, tempi stretti che non lasciano margine per imprevisti, requisiti ambigui che potrebbero rivelare complessità nascosta, dipendenze da terze parti che potrebbero ritardare.

Un professionista esperto identifica i rischi proattivamente e propone mitigazioni: un prototipo per validare l'integrazione più rischiosa, un buffer temporale per le fasi con più incertezza, una fase di discovery pagata prima del preventivo definitivo. Questa onestà è un segnale di maturità professionale, non di insicurezza.

Oltre le cinque domande: segnali da osservare

Oltre alle risposte esplicite, osserva come il freelance risponde:

• Fa domande a sua volta? Un freelance che accetta il progetto senza chiedere nulla non ha capito cosa deve fare
• Dice di no a qualcosa? Chi dice sì a tutto o non ha capito la complessità o non intende mantenere le promesse
• Propone alternative? "Potresti fare X, ma Y sarebbe più efficace perché..." — questo dimostra che sta pensando al tuo problema, non solo alla fattura
• È trasparente sui limiti? "Questo lo so fare bene, quest'altro non è la mia specialità" — meglio saperlo prima che scoprirlo durante il progetto
• Ha referenze verificabili? Clienti precedenti che puoi contattare, non solo testimonial anonimi su un sito web

Il costo di scegliere male

Investire un'ora in queste domande può risparmiare mesi di problemi. Il costo di uno sviluppatore freelance sbagliato non è solo il budget sprecato — è il tempo perso, le opportunità mancate e lo stress di un progetto che non va da nessuna parte. Le risposte a queste domande dicono più del prezzo. Un freelance che risponde con chiarezza è quello con cui vuoi lavorare.