Come scegliere uno sviluppatore freelance per la tua agenzia: 8 domande prima di affidare un progetto

Per un'agenzia, affidare lo sviluppo a un freelance significa mettere nelle sue mani un pezzo del rapporto con un proprio cliente. Il rischio non è tanto tecnico quanto di affidabilità: rispetto dei tempi, qualità che non si vede subito, comunicazione, riservatezza, cosa succede quando il progetto è finito. Lavoro come sviluppatore esterno per agenzie da molti anni; queste sono le domande che farei io, e cosa ascolterei nelle risposte.

1. Che progetti hai fatto, e quali assomigliano al mio?

Non un elenco di tecnologie, ma progetti concreti, con il ruolo avuto in ciascuno. Chiedi quelli più vicini al tuo per tipo (sito istituzionale, e-commerce, applicazione) e per complessità. Un portfolio fatto solo di siti vetrina dice poco su un'integrazione con un gestionale.

Cosa ascoltare: descrizioni precise di problemi risolti, compresi quelli andati storti.

2. Hai già lavorato con altre agenzie?

Lavorare per un'agenzia è diverso dal lavorare per un cliente diretto: ci sono un project manager, processi e strumenti che non decidi tu, consegne intermedie, revisioni del reparto creativo. Chi ci è abituato si inserisce senza attrito.

Cosa ascoltare: familiarità con Figma, gestione dei ticket, repository condivisi, revisioni del codice.

3. Come gestisci white-label e riservatezza?

Il cliente è tuo, e deve restarlo. Chiedi come gestisce la comunicazione, se firma un accordo di riservatezza, come tratta accessi e materiali, se cita i progetti nel proprio portfolio e con quale permesso.

Cosa ascoltare: regole chiare, proposte da lui, senza che tu debba insistere. Approfondisco in White-label nello sviluppo web.

4. Come stimi tempi e costi?

Una stima seria arriva dopo domande sul brief, con ipotesi ed esclusioni dichiarate, divisa per fasi. Le formule più comuni sono a progetto, con prezzo chiuso, o a giornate con un monte ore concordato.

Cosa ascoltare: domande prima dei numeri. Una cifra secca in un'ora, su un progetto complesso, è un campanello d'allarme. Come preparare il brief è in Come scrivere un brief per uno sviluppatore.

5. Come lavori da un design in Figma?

Se il vostro reparto creativo progetta in Figma, lo sviluppatore deve leggere il file, segnalare ambiguità e casi non disegnati prima di stimare, e proteggere la fedeltà su tutte le larghezze.

Cosa ascoltare: domande su componenti, varianti, stati, versione mobile, token. Ne parlo in Da Figma a WordPress.

6. Dove sta il codice e chi lo possiede?

Il codice va in un repository sotto il controllo dell'agenzia o del cliente, con commit leggibili, documentazione e un ambiente di staging. Nessuna dipendenza nascosta: se domani lo sviluppatore non fosse disponibile, un altro deve poter proseguire.

Cosa ascoltare: proposta spontanea di repository, anteprime e documentazione.

7. Cosa succede dopo la consegna?

Bug dopo il lancio, piccole modifiche, aggiornamenti, manutenzione. Chiedi cosa è incluso, con quali tempi di risposta e a quali condizioni continua la collaborazione.

Cosa ascoltare: un periodo di assistenza definito e una proposta chiara per il dopo.

8. Cosa non sai fare?

È la domanda più utile. Nessuno sa fare tutto, e chi lo afferma prima o poi improvviserà sul progetto del tuo cliente.

Cosa ascoltare: limiti dichiarati con naturalezza, e l'indicazione di quando conviene coinvolgere qualcun altro.

Segnali di affidabilità e di allarme

Segnali buoni: domande precise sul brief, proposta di un'anteprima continua del lavoro, contratti e riservatezza chiari, codice in un repository condiviso fin dal primo giorno.

Segnali di allarme: stime immediate senza domande, risposte vaghe sulla proprietà del codice, accessi tenuti a proprio nome, nessuna visibilità sul lavoro fino alla consegna.

Come iniziare

Un progetto pilota circoscritto, con perimetro, scadenza e criteri di accettazione chiari. Mostra metodo, qualità e comunicazione meglio di qualunque colloquio, e riduce il rischio per entrambe le parti.

Come organizzare la collaborazione ogni giorno

Una volta scelto lo sviluppatore, poche regole evitano gran parte degli attriti:

• un canale unico per le richieste, con un referente per parte;
• ticket o attività scritte, non richieste a voce che nessuno ritrova;
• un ramo per ogni tema e un'anteprima online per ogni consegna, consultabile dal project manager;
• un punto settimanale breve su avanzamento, blocchi e priorità;
• criteri di accettazione per ogni consegna, così «finito» significa la stessa cosa per tutti;
• le modifiche fuori perimetro stimate prima di farle, non scoperte in fattura.

Sul rapporto con il cliente finale, la regola è che decide l'agenzia: lo sviluppatore può restare invisibile oppure essere presentato come parte del team tecnico. L'importante è che la scelta sia chiara e mantenuta per tutto il progetto.

Come la vedo io

Lavorare con le agenzie è il centro della mia attività, e ho imparato che quello che conta per un'agenzia non è solo che il codice funzioni: è non avere sorprese. Per questo lavoro sempre con repository condivisi, un ramo per ogni tema, anteprime online consultabili dal project manager prima di ogni rilascio, e regole di riservatezza decise all'inizio. Non cito i clienti delle agenzie senza il loro permesso, e il rapporto con il cliente finale resta a voi.

E rispondo volentieri alla domanda numero 8: dico subito cosa non faccio, e quando un progetto è più adatto a qualcun altro.

Il primo progetto, per me, è sempre anche un test reciproco.

Perché affidarlo a me

Programmo dal 1999, ho consegnato più di 300 progetti e ho lavorato come sviluppatore esterno con circa 30 agenzie, anche in white-label, da Roma e da remoto. Mi inserisco nei vostri processi, lavoro da Figma, consegno codice documentato in repository vostri.

Se cercate uno sviluppatore per la vostra agenzia, scrivetemi: una chiacchierata di circa 20 minuti per capire se possiamo lavorare insieme. Come collaboro con le agenzie è spiegato in Collaborazioni.