White-label nello sviluppo web: come funziona davvero tra agenzia e sviluppatore

White-label, nello sviluppo web, significa che un'agenzia consegna al proprio cliente un lavoro realizzato in tutto o in parte da uno sviluppatore esterno, con il proprio marchio. Per il cliente il fornitore è l'agenzia. È una formula diffusissima, e funziona bene a una condizione: che i confini siano chiari fin dal primo giorno. Lavoro così con molte agenzie; ecco come la imposto.

Perché le agenzie la scelgono

• Capacità elastica: gestire picchi di lavoro senza assumere.
• Competenze specifiche: un'integrazione, un'applicazione, una migrazione che il team interno non copre.
• Concentrazione sul proprio mestiere: strategia, design, relazione con il cliente.
• Costi prevedibili: formule a progetto o a monte ore.

I confini con il cliente

È la regola che non si negozia: il cliente è dell'agenzia. Lo sviluppatore non lo contatta direttamente, non propone servizi propri, non usa canali paralleli. Quando serve un confronto tecnico diretto, avviene nelle modalità decise dall'agenzia: in sua presenza, con un indirizzo dell'agenzia, o presentando lo sviluppatore come parte del team tecnico.

Riservatezza e accordi

Prima di iniziare, per iscritto:

• accordo di riservatezza su materiali, dati e informazioni commerciali;
• divieto di contatto diretto con il cliente, anche dopo la fine del progetto, per un periodo definito;
• proprietà del codice e dei diritti, che passano all'agenzia o al cliente secondo il loro contratto;
• uso nel portfolio solo con permesso esplicito.

Codice, repository e account

È il punto in cui molte collaborazioni si incrinano mesi dopo. Il mio approccio:

• repository dell'agenzia (o del cliente), con lo sviluppatore invitato come collaboratore;
• account intestati all'agenzia o al cliente: hosting, dominio, servizi esterni, store, chiavi API;
• credenziali condivise con strumenti sicuri, mai via email;
• documentazione sufficiente perché un altro sviluppatore possa proseguire.

Se domani lo sviluppatore sparisse, l'agenzia non deve perdere nulla.

Il flusso di lavoro

1. Brief dall'agenzia, con obiettivi, design e criteri di accettazione (ne parlo in Come scrivere un brief per uno sviluppatore).
2. Domande e stima con ipotesi ed esclusioni.
3. Sviluppo per rami, con commit leggibili.
4. Anteprime online su indirizzi neutri, che l'agenzia può mostrare al cliente senza riferimenti allo sviluppatore.
5. Revisione dell'agenzia, correzioni, approvazione.
6. Rilascio e periodo di assistenza concordato.

Le anteprime sono il cuore del metodo: l'agenzia controlla il lavoro in ogni momento e decide lei cosa e quando mostrare al cliente.

Formule

• A progetto, con prezzo chiuso, quando il perimetro è definito.
• A giornate, quando il lavoro è esplorativo o le richieste cambiano.
• Continuativa, con un monte ore mensile, quando l'agenzia ha bisogno di capacità di sviluppo stabile.

Gli errori che rovinano la collaborazione

• Accordi a voce su perimetro e proprietà.
• Accessi intestati allo sviluppatore.
• Comunicazione che salta l'agenzia «per fare prima».
• Nessuna visibilità sul lavoro fino alla consegna.
• Stime senza ipotesi, che diventano conflitti a fine progetto.

Come proporlo ai clienti

L'agenzia ha tre modi di gestire la presenza dello sviluppatore esterno, tutti legittimi:

• white-label puro: lo sviluppatore non compare mai, tutte le comunicazioni passano dall'agenzia;
• membro del team tecnico: presentato come parte della squadra dell'agenzia, partecipa alle riunioni tecniche quando serve, sempre con l'agenzia presente;
• partner dichiarato: l'agenzia presenta lo sviluppatore come specialista esterno per una parte del progetto.

La scelta dipende dal cliente e dal tipo di progetto. Conta la coerenza: decisa all'inizio, mantenuta fino alla fine, rispettata anche nei dettagli (indirizzi email, firme, nomi nei repository visibili al cliente).

Una checklist prima di iniziare

• Accordo di riservatezza e di non contatto firmato.
• Perimetro, criteri di accettazione e formula economica per iscritto.
• Repository, hosting e servizi a nome dell'agenzia o del cliente.
• Ambiente di staging e indirizzi di anteprima neutri.
• Canale di comunicazione e referenti definiti.
• Regole su portfolio e citazioni.

Come la vedo io

Lavorare in white-label richiede una cosa più del talento tecnico: affidabilità silenziosa. L'agenzia mette in gioco la propria reputazione su un lavoro che non fa con le proprie mani, e deve potersi fidare senza controllare tutto. Per questo propongo io le regole all'inizio: repository e account dell'agenzia, anteprime su indirizzi neutri, nessun contatto con il cliente se non deciso da voi, nessuna citazione nel portfolio senza permesso. È anche il motivo per cui alcuni progetti che ho sviluppato per agenzie non compaiono nei miei lavori: il cliente è loro.

Aggiungo una cosa che ho imparato con gli anni: il white-label funziona meglio quando non è un ripiego per i picchi, ma una relazione continuativa. Un'agenzia che lavora con lo stesso sviluppatore esterno su più progetti accumula un vantaggio concreto: convenzioni condivise, repository impostati allo stesso modo, stime più precise perché basate su lavori già fatti insieme, e un referente tecnico che conosce i clienti senza averli mai incontrati. È la ragione per cui propongo, quando ha senso, la formula continuativa con un monte ore mensile: dà all'agenzia capacità di sviluppo stabile e a me la possibilità di lavorare con continuità sul codice, che è la condizione migliore per farlo bene. E quando un progetto non è adatto a me, lo dico subito: per un'agenzia, un rifiuto chiaro vale più di un sì improvvisato.

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 e nei vostri strumenti, e il rapporto con il cliente resta vostro.

Se avete un progetto in arrivo o un picco di lavoro, scrivetemi: una chiacchierata di circa 20 minuti per capire come lavorare insieme. Come collaboro in white-label è spiegato in Collaborazioni.