Come scegliere uno sviluppatore app mobile freelance

Requisiti, canali, portafoglio sugli store, competenze, budget, colloquio e manutenzione obbligatoria: le otto fasi della scelta, e i vincoli che nessuno racconta prima di firmare

Scegliere uno sviluppatore di app mobile ha una differenza sostanziale rispetto a qualunque altro progetto software: fra te e i tuoi utenti ci sono due aziende che decidono le regole, e le cambiano ogni anno. Apple e Google non si limitano a distribuire l'app: impongono su quale account viene pubblicata, con quali strumenti va ricompilata, entro quali date, e quali dati devi rendere pubblici. Una parte consistente del lavoro — e dei litigi di fine progetto — non riguarda il codice ma questo.

Questa guida percorre le otto fasi della scelta di un freelance per un'app: requisiti, canali, portafoglio, competenze, budget, selezione, verifica dell'identità e tempi. Dove esistono dati verificabili li riporta con la fonte — le pagine ufficiali degli store, i barometri europei delle tariffe, le ricerche sulla validità dei metodi di selezione — e dove i dati non esistono lo dice, perché nel mondo delle app le statistiche più citate sono spesso ferme al 2024 o vengono da chi vende il servizio.

La fase più importante non è il colloquio: è la decisione, da prendere prima di firmare, su chi possiede l'account sviluppatore e chi si occupa degli adeguamenti obbligatori dei prossimi due anni. Ci arriviamo nella fase 4, ma vale la pena saperlo dalla prima riga.

Se invece il progetto che hai in mente è un sito, un e-commerce o un'applicazione che gira nel browser, la guida gemella è Come scegliere uno sviluppatore web freelance.

INDICE DEI CONTENUTI

Che cosa stai scegliendo davvero
Fase 1 — I requisiti: cosa deve esistere prima di cercare
Fase 2 — Dove si cercano gli sviluppatori di app freelance
Fase 3 — Valutare il portafoglio: si guarda sugli store
Fase 4 — Le competenze: la parte che non è codice
Fase 5 — Il budget
Fase 6 — La selezione: cosa funziona e cosa no
Fase 7 — Verificare che sia chi dice di essere
Fase 8 — Disponibilità e tempi di consegna
Dopo la pubblicazione: la manutenzione è obbligatoria, non opzionale
Il contratto: account, chiavi di firma, codice
La scelta in pratica, per tipo di progetto
Conclusioni
Domande frequenti

Che cosa stai scegliendo davvero

Quando affidi un'app a un freelance compri tre cose insieme: la sua competenza tecnica, il suo tempo in quel periodo e la sua disponibilità futura a rimettere le mani su quello che ha scritto. Nelle app la terza pesa molto più che altrove, perché un'app non manutenuta non invecchia lentamente: a una data precisa smette di poter essere aggiornata, e in alcuni casi viene rimossa dallo store.

La disponibilità futura non puoi verificarla in alcun modo. Puoi solo renderla meno necessaria: account intestati a te, chiavi di firma in tuo possesso, codice sul tuo repository, consegne frequenti. Ogni scelta che va in quella direzione vale più di quanto costi; ogni scelta che aumenta la dipendenza da una persona specifica va pagata con uno sconto o rifiutata.

Fase 1 — I requisiti: cosa deve esistere prima di cercare

Un perimetro scritto male non produce un preventivo sbagliato: produce tre preventivi non confrontabili fra loro, perché ognuno ha immaginato un progetto diverso. Nelle app succede più che altrove, perché metà delle scelte non riguarda le funzioni ma il contesto in cui girano.

Le cinque cose che stanno in due pagine

Chi userà l'app e in quale situazione. Non "un'app per i clienti", ma "i tecnici in cantiere, spesso senza campo, con i guanti, che oggi compilano un modulo di carta e lo perdono". Il secondo enunciato contiene già le due decisioni tecniche più costose: funzionamento senza rete e dimensione dei comandi.

Le tre o quattro azioni principali, dal punto di vista di chi le compie. Sono quelle su cui si misurerà se il lavoro è finito.

Cosa esiste già: un gestionale con cui parlare, un sito, un'utenza già registrata altrove, un'identità grafica, dati da migrare. Ogni integrazione con un sistema esistente è la voce che più spesso fa saltare le stime, perché il suo costo dipende da com'è fatto il sistema dall'altra parte.

Cosa è fuori perimetro. Scriverlo è più efficace che scrivere cosa è dentro.

Il vincolo che comanda: una data, un tetto di spesa, un obbligo normativo. Uno solo.

Le sei domande specifiche delle app

Sono quelle che i committenti scoprono a progetto avviato, e ognuna sposta il preventivo:

Su quali sistemi e da quale versione in su. Supportare due versioni di Android in più non è una spunta: è codice, prove e tempo.

Serve funzionare senza rete? È la domanda che divide un'app semplice da un'app complessa, perché comporta la sincronizzazione dei dati e la gestione dei conflitti.

Servono notifiche push? Comportano un servizio server e la gestione dei consensi.

Quali permessi del telefono — posizione, fotocamera, contatti, salute: ogni permesso richiesto va motivato agli store e riduce la percentuale di utenti che accettano.

Ci sono pagamenti dentro l'app? Se vendi contenuti o funzioni digitali le regole degli store si fanno stringenti e trattengono una commissione; se vendi beni fisici o servizi del mondo reale no. La distinzione va chiarita prima.

Su quale account sviluppatore esce l'app? È la clausola contrattuale più importante dell'intero progetto, e ha una sezione dedicata più avanti.

Il perimetro decide la forma del contratto

Il Project Management Institute distingue prezzo fisso, rimborso dei costi e tempo e materiali. Nel prezzo fisso il rischio di sforamento è del fornitore, che quindi lo prezza: a parità di lavoro il prezzo fisso costa di più. Il tempo e materiali è indicato proprio quando il perimetro è difficile da definire, ma il rischio è tuo.

La regola pratica: prezzo fisso solo su ciò che sai descrivere in due pagine. Il compromesso che funziona quasi sempre è a due tempi: una prima fase breve e a prezzo fisso in cui il freelance analizza e produce la specifica — pagata e tua da portare via anche se poi cambi fornitore — e solo dopo il preventivo sul resto. Nelle app questa fase produce anche una cosa concreta e verificabile: l'elenco dei permessi e dei servizi esterni che l'app userà, cioè quello che dovrai dichiarare agli store.

Non esistono statistiche pubbliche su quanti progetti freelance siano contrattualizzati a prezzo fisso o a tempo: chi le cita, le sta stimando.

Fase 2 — Dove si cercano gli sviluppatori di app freelance

I canali non differiscono solo per quanti profili contengono, ma per chi paga la commissione, chi fa la selezione e chi si assume il rischio se il lavoro non arriva. Per le app c'è una differenza in più rispetto al web: la platea è molto più piccola, perché richiede competenze su due piattaforme e sui rispettivi processi di pubblicazione.

I marketplace aperti: Upwork e Fiverr

Cataloghi mondiali senza selezione preventiva, con filtro reputazionale. Su Upwork la commissione a carico del freelance va da 0% a 15% per contratto — il "10% fisso" che si legge ovunque non è più il listino ufficiale — e al committente si applica una commissione fino al 7,99%. Su Fiverr il modello è opposto: prezzo esposto, 5,5% a carico dell'acquirente più 3,50 dollari sotto i 200, e 20% trattenuto al venditore.

Su questi canali, per un'app, il rischio specifico è un altro: trovare qualcuno che sviluppa bene e non ha mai pubblicato. Chiedi sempre il collegamento a una scheda pubblica su uno store, non uno screenshot dell'emulatore.

Le piattaforme europee e quelle selezionate: Malt e Toptal

Malt trattiene il 5% al freelance e 10% o 15% al committente a seconda del piano, ma non opera in Italia: le pagine ufficiali elencano Francia, Spagna, Belgio, Regno Unito, Paesi Bassi, paesi nordici e Medio Oriente. Toptal dichiara di accettare meno del 3% delle candidature — dato autodichiarato, non verificato da terzi — con un abbonamento cliente di 79 dollari al mese e una prova fino a due settimane.

In Italia: cosa esiste davvero

Twago è dismessa: il dominio non risolve, il servizio è stato integrato in Randstad Sourceright dopo l'acquisizione. AddLance è gratuita per il committente e si finanzia facendo pagare crediti al freelance per ogni offerta. LinkedIn resta il canale dominante della domanda: l'Osservatorio Competenze Digitali ha contato oltre 222.000 annunci ICT fra gennaio 2024 e settembre 2025. Sul passaparola non esiste alcun dato italiano quantificato.

Restano le piattaforme verticali italiane, dove i progetti nascono già classificati per categoria e tecnologia, come questa: il vantaggio non è il numero di iscritti, è che la richiesta arriva strutturata e le offerte che ricevi sono confrontabili — cioè il problema della fase 1.

Quanto pesa la scarsità di sviluppatori

Secondo Eurostat, nel 2025 gli specialisti ICT erano il 5,0% degli occupati nell'Unione europea e il 3,8% in Italia: terzultimo posto. L'Osservatorio Competenze Digitali quantifica il divario in 236.000 occupati ICT mancanti, con 73.000 nuovi professionisti l'anno contro 136.000 annunci: un professionista nuovo ogni due posizioni aperte. I freelance bravi non sono in coda: un processo con tre colloqui e una prova non pagata seleziona chi non ha alternative.

Fase 3 — Valutare il portafoglio: si guarda sugli store

Nelle app la verifica del portafoglio è più semplice e più impietosa che nel web, perché le schede pubbliche di App Store e Google Play contengono già quasi tutto quello che ti serve sapere. Chiedi i collegamenti alle schede, non le immagini.

Le cinque cose che si leggono in un minuto

La data dell'ultimo aggiornamento. Se sono passati più di dodici mesi, quasi certamente quell'app non rispetta più i requisiti di target SDK di cui parliamo nella fase 4: è un'app in attesa di essere bloccata.

A nome di chi è pubblicata. È il dato più informativo di tutti. Se le app del portafoglio sono tutte sull'account del freelance, i suoi clienti non possiedono le proprie app. Sapendolo, sai già quale clausola dovrai negoziare.

Cosa dicono le recensioni negative. Non il voto medio: il contenuto. Se parlano di crash, di accessi che non funzionano o di dati persi, stai leggendo la qualità tecnica del lavoro nelle parole degli utenti.

Se lo sviluppatore risponde alle recensioni. Racconta il rapporto che ha con le app dopo la consegna.

La sezione sulla privacy e sui dati raccolti. Deve esistere, essere coerente con quello che l'app fa e non dichiarare raccolte che il committente non aveva chiesto.

Provale, non guardarle

Scarica due app del portafoglio sul tuo telefono e usale cinque minuti, possibilmente con la rete lenta o disattivata. Quanto ci mette ad aprirsi la prima volta, cosa succede se metti il telefono in aereo a metà di un'operazione, come si comporta se ruoti lo schermo o se il testo di sistema è ingrandito. Sono esattamente i tre punti in cui si vede la differenza fra un'app finita e una consegnata.

Il codice pubblico, se c'è

Un profilo GitHub attivo è un segnale, la sua assenza non è un segnale contrario: molti professionisti lavorano solo su repository privati dei clienti. Se il codice c'è, guarda due cose e non le stelline: se i messaggi dei commit spiegano perché è stato fatto un cambiamento e non solo cosa, e se esistono dei test. Nelle app c'è un terzo indizio utile: la presenza di una configurazione di build automatica, che è ciò che rende ripetibile la pubblicazione e non dipendente dal computer di una persona.

Fase 4 — Le competenze: la parte che non è codice

Nelle app mobile una quota consistente del lavoro non è programmazione, ed è la parte che i committenti scoprono a progetto finito. Sono tutte cose da decidere nel contratto.

Gli account costano e sono intestati a qualcuno

L'Apple Developer Program costa 99 dollari all'anno, l'account Google Play 25 dollari una tantum. Per pubblicare a nome di una società serve un numero D-U-N-S, gratuito ma da richiedere con settimane di anticipo; Google richiede documento d'identità e, per i nuovi account organizzazione, la verifica del sito web.

La regola, salvo motivi molto specifici, è una sola: l'account è tuo, il freelance vi è aggiunto come utente. Recuperare un'app pubblicata sull'account di qualcun altro, quando i rapporti si sono guastati, è una pratica lunga e a esito incerto — e nel frattempo non puoi aggiornarla.

Il trader status europeo rende pubblici indirizzo e telefono

Per il Digital Services Act, dal 16 ottobre 2024 Apple chiede la dichiarazione di trader per aggiornare le app nell'Unione europea, e dal 17 febbraio 2025 rimuove dallo store europeo le app di chi non l'ha fornita. Chi è trader deve pubblicare sulla pagina prodotto indirizzo, telefono ed email.

Un freelance con partita IVA è quasi sempre un trader. Significa che, se l'app esce dal suo account, i suoi recapiti personali finiscono sulla scheda della tua app in 27 paesi — e viceversa, se esce dal tuo, saranno i tuoi. È una decisione da prendere prima, non dopo.

Su Google Play, invece, un obbligo di trader status con una data non esiste: nessuna pagina ufficiale Google lo impone. Google ottiene lo stesso risultato di tracciabilità con la verifica dell'identità dello sviluppatore. Se leggi il contrario, chiedi la fonte.

Le scadenze tecniche sono annuali e non negoziabili

Google Play impone di aggiornare il target API level: entro il 31 agosto 2026 serve API 36 (Android 16), con proroga su richiesta al 1° novembre. Apple impone la ricompilazione con l'SDK più recente: dal 28 aprile 2026 servono Xcode 26 e gli SDK 26. Un'app che salta queste date non "invecchia": smette di poter essere aggiornata.

Dal 2026 conta anche dove distribuisci: Google ha avviato la verifica degli sviluppatori Android anche per le app installate fuori dal Play Store, con entrata in vigore il 30 settembre 2026 in Brasile, Indonesia, Singapore e Thailandia ed espansione globale annunciata dal 2027. Distribuire un file APK dal proprio sito senza registrarsi smetterà di essere un'opzione a costo zero.

Nativo o cross-platform

Qui bisogna dire una cosa scomoda sui dati: le statistiche aggiornate che tutti citano non esistono. La Stack Overflow Developer Survey ha rimosso nel 2025 la sezione sui framework mobile, quindi l'ultimo dato disponibile su Flutter e React Native è quello del 2024 (rispettivamente 9,4% e 8,4% fra tutti i rispondenti). I materiali sui vantaggi di Kotlin Multiplatform vengono da JetBrains, cioè da chi produce il linguaggio. L'ultimo dato ufficiale su Flutter è di dicembre 2024: oltre un milione di sviluppatori attivi al mese e circa il 30% delle nuove app iOS.

Per il committente il criterio non è "quale tecnologia è migliore", è quanto sarà facile trovare qualcun altro se questo rapporto finisce. Su questo i dati recenti esistono solo per i linguaggi nativi: nella rilevazione 2025 Kotlin è usato dal 10,8% degli sviluppatori e Swift dal 5,4%. Due criteri pratici: se l'app dipende molto dalle funzioni del telefono, il nativo riduce i problemi; se deve stare su entrambi i sistemi con budget limitato, il cross-platform riduce il costo iniziale — ma non dimezza la manutenzione, perché le scadenze di Apple e Google restano identiche e si aggiunge la dipendenza dal ciclo di rilascio del framework.

La parte che sta sul server

Quasi nessuna app vive da sola: dietro c'è un server che conserva i dati, gestisce gli accessi e invia le notifiche. Chiedi esplicitamente chi lo sviluppa e chi lo mantiene, perché è la voce che più spesso manca dai preventivi delle app e perché richiede competenze diverse. Un freelance che fa solo la parte sullo schermo va benissimo, a patto che tu sappia in anticipo che il resto è a tuo carico. E chiedi dove sono ospitati i dati: se l'app tratta dati personali di utenti europei, la risposta ti serve per iscritto.

L'intelligenza artificiale ha cambiato la domanda giusta

Chiedere se usa l'intelligenza artificiale non ha più senso: nella Stack Overflow Developer Survey 2025, su oltre 49.000 rispondenti, l'84% la usa o prevede di usarla e il 51% dei professionisti la usa ogni giorno; la rilevazione JetBrains su 24.534 sviluppatori dà l'85%. Ma nella stessa indagine solo il 3,1% ripone alta fiducia nell'accuratezza dei risultati, il 66% indica come frustrazione principale le soluzioni "quasi giuste ma non del tutto" e il 45% dice che il debug del codice generato richiede più tempo.

La domanda da fare non è se la usa ma come verifica quello che produce. E per le app c'è una domanda in più che vale la pena porre: come si comporta il codice generato con le regole di privacy degli store, dove una libreria inserita senza accorgersene può obbligarti a dichiarare una raccolta di dati che non avevi previsto.

Fase 5 — Il budget

Sulle app esistono più numeri che sul web, ma vanno letti sapendo da dove vengono.

I pochi numeri verificabili in Europa

I barometri Malt sono l'unica rilevazione europea con metodo dichiarato e campione grande. Per i profili esperti, edizione 2026: in Francia la mediana è 576 € al giorno e i profili mobile stanno a 551 €; in Spagna la mediana è 313 € e il mobile 291 €. Per anzianità, in Francia: 317 € fino a due anni, 435 € fra tre e sette, 576 € fra otto e quindici, 671 € oltre i quindici; in Spagna 183, 249, 313 e 388 €.

Stesso metodo, stessa piattaforma, stesso anno: fra Francia e Spagna corre un fattore 1,8 a parità di anzianità. È il modo più onesto per collocare l'Italia, che somiglia più al mercato spagnolo — dichiarando però che si tratta di un'inferenza e non di una misura. Nell'area di lingua tedesca lo studio freelancermap 2026, su oltre 5.400 freelance, dà 103 € l'ora di media per l'IT.

In Italia un barometro non esiste

Nessuna fonte italiana pubblica tariffe freelance per sviluppatori con una metodologia verificabile. Non Assintel, non gli Osservatori del Politecnico di Milano, non ISTAT, non AlmaLaurea. L'unica rilevazione in circolazione riporta una media di 281 € al giorno ma è costruita su un numero di rilevazioni a una o due cifre per ruolo: è un indizio, non una statistica.

L'unico riferimento italiano solido è indiretto: la Salary Guide 2026 di Hays indica 56.360 euro lordi di retribuzione media nazionale per i dipendenti, 59.700 fra cinque e dieci anni di esperienza, 78.850 oltre i dieci. Un freelance non costa quella cifra divisa per i giorni lavorativi: confrontare una tariffa giornaliera con una RAL divisa per 220 è l'errore più comune e produce offerte che i professionisti bravi non prendono in considerazione.

Quanto costa un'app

Due directory commerciali pubblicano cifre con metodo dichiarato. GoodFirms, su 267 aziende, colloca un'app semplice fra 15.000 e 40.000 dollari con 3-6 mesi di lavoro, una di media complessità fra 40.000 e 120.000 con 6-9 mesi, una avanzata oltre i 100.000. Clutch indica tariffe orarie tipiche fra 25 e 49 dollari, un costo medio di progetto di circa 90.000 dollari e una durata media di 11 mesi.

Vanno lette per quello che sono: directory che vivono di segnalazione di clienti alle agenzie censite, con campioni auto-selezionati di fornitori, e riferite ad agenzie e non a freelance. Sono le migliori fonti disponibili con una metodologia esplicita, non statistiche indipendenti. GoodFirms aggiunge un'avvertenza che vale più delle cifre: prevedere un 20-30% oltre il preventivo iniziale.

Equo compenso: quando è la legge a fissare un minimo

La Legge 49/2023 sull'equo compenso copre anche i professionisti non iscritti a un ordine, quindi anche gli sviluppatori, ma si applica solo ai committenti che siano imprese con più di 50 dipendenti oppure oltre 10 milioni di euro di fatturato, oltre a banche, assicurazioni e pubblica amministrazione. Per quei committenti le clausole con compenso inferiore ai parametri ministeriali sono nulle. Una PMI sotto entrambe le soglie non vi è soggetta.

Le voci che un preventivo per un'app deve contenere

Oltre alle voci di qualunque progetto — analisi, interfaccia, sviluppo, integrazioni, test, formazione — un preventivo per un'app deve dire esplicitamente:

La parte server, se c'è, separata dal resto.
La pubblicazione sugli store, che è lavoro a sé: schede, immagini, descrizioni, questionari sulla privacy, classificazione per età.
Le quote annuali di Apple e Google, con l'indicazione di chi le paga e chi le rinnova.
Le eventuali revisioni rifiutate: quante correzioni sono incluse se lo store respinge l'app.
La manutenzione dei dodici mesi successivi, con quante ore incluse e cosa succede quando finiscono. In un'app non è una voce facoltativa: è la voce che decide se l'app esisterà ancora fra due anni.

Fase 6 — La selezione: cosa funziona e cosa no

La classifica dei metodi è cambiata nel 2022

La meta-analisi più citata della storia della selezione, quella di Schmidt e Hunter del 1998, attribuiva ai test pratici 0,54 di correlazione con la prestazione e ai test cognitivi 0,51. Quei numeri sono ancora ovunque nelle infografiche e sono stati corretti: nel 2022 Sackett, Zhang, Berry e Lievens hanno dimostrato che le correzioni statistiche dell'epoca gonfiavano le stime, e le hanno ricalcolate. La nuova classifica, confermata dalla Society for Industrial and Organizational Psychology:

colloquio strutturato 0,42
test di conoscenza del mestiere 0,40
prova pratica 0,33
test cognitivi 0,31
colloquio non strutturato 0,19
anni di esperienza 0,07

Due conseguenze grosse. Fra colloquio strutturato e non strutturato corre un fattore due e mezzo, il divario più ampio della tabella: non conta fare un colloquio, conta strutturarlo. E gli anni di esperienza predicono quasi nulla: il filtro "minimo dieci anni" scarta persone in base al criterio meno informativo che esista.

Il colloquio strutturato in un'ora

Strutturato significa quattro cose: le stesse domande a tutti, nello stesso ordine; domande su situazioni reali già vissute e non su ipotesi; una scala di valutazione decisa prima di sentire le risposte; valutazioni annotate durante il colloquio.

Cinque domande che funzionano su qualunque progetto di app: come si è svolta l'ultima pubblicazione su uno store, dall'inizio all'approvazione; l'ultima volta che uno store ha respinto un'app, perché e come è stata risolta; come gestisce l'aggiornamento annuale del target SDK sulle app dei suoi clienti; cosa succede se si ammala a metà progetto; e cosa consegna esattamente il giorno della chiusura, oltre all'app funzionante. La terza domanda è quella che separa chi ha rapporti duraturi da chi consegna e sparisce.

La prova pratica: breve, pagata, in autonomia

La prova pratica resta utile — 0,33 non è poco — ma va disegnata bene. Nel 2020, in una ricerca randomizzata su 48 studenti di informatica presentata a ESEC/FSE, Behroozi e colleghi hanno confrontato l'esercizio alla lavagna sotto osservazione, con obbligo di pensare ad alta voce, con lo stesso esercizio svolto in una stanza privata: chi era osservato ha reso la metà, con stress e carico cognitivo significativamente più alti (comunicato della North Carolina State University). Gli autori hanno rilevato anche un effetto di genere marcato, avvertendo che il sotto-campione era troppo piccolo per generalizzare.

Tradotto: una prova breve, in autonomia e retribuita dice molto più di un esercizio sotto osservazione. Retribuita non è un vezzo etico: è ciò che ti permette di chiedere una prova sul tuo problema invece di un rompicapo generico. Per un'app la prova più informativa non è scrivere una schermata: è prendere un'app esistente e farla girare, cioè ricostruire l'ambiente, compilarla e consegnarti un file installabile. È esattamente ciò che dovrà fare ogni volta, e mette in luce in due ore chi sa gestire firme, certificati e dipendenze.

La parte più informativa non è il risultato: è la mezz'ora in cui te lo spiega, dove si vede se sa raccontare le scelte a un non tecnico.

Quiz, live coding e presentazione

I quiz misurano la conoscenza nozionistica — la voce "test di conoscenza del mestiere", 0,40 — ma dicono poco sull'autonomia, che per un freelance è ciò che conta. Usali al massimo come filtro iniziale. Il live coding, alla luce dello studio citato, misura in buona parte la resistenza all'ansia da prestazione: se lo usi, rendilo collaborativo e osserva come ragiona, non se arriva alla soluzione.

Il formato più sottovalutato è la presentazione di un'app già pubblicata: venti minuti su un progetto scelto da lui. Cosa doveva risolvere, quali alternative aveva, cosa ha scelto e perché, cosa rifarebbe diversamente, e come è andata la fase di approvazione. Un professionista solido ha sempre pronta la risposta all'ultima domanda.

Fase 7 — Verificare che sia chi dice di essere

Gartner prevede che entro il 2028 un profilo di candidato su quattro nel mondo sarà falso, con una falsificazione sostanziale dell'identità; nella stessa rilevazione i metodi con cui si scoprono sono la videochiamata (81%) e il colloquio in presenza (74%). Il fenomeno meglio documentato riguarda i lavoratori IT nordcoreani che si fanno assumere da remoto: l' avviso congiunto di Dipartimento di Stato, Tesoro e FBI stima oltre 300.000 dollari l'anno per singolo lavoratore e cita esplicitamente le piattaforme di freelance come canale d'ingaggio. Nel 2025 il Dipartimento di Giustizia americano ha annunciato azioni che hanno riguardato oltre 100 aziende a giugno e 136 aziende vittime a novembre; in alcuni casi, avverte l' FBI, dopo l'ingaggio è seguita l'estorsione, con codice e dati tenuti in ostaggio.

Gli indicatori dell' avviso FBI del 23 luglio 2025 sono verificabili da chiunque: rifiuto sistematico delle videochiamate o sfondo sempre oscurato; persona diversa al colloquio rispetto a chi poi lavora — l'FBI consiglia di conservare un'immagine del primo incontro; storia formativa non verificabile presso le fonti dichiarate; documenti con errori e recapiti che non combaciano con i profili pubblici; richiesta di pagamento in criptovaluta o cambi frequenti di coordinate bancarie.

Nelle app c'è una contromisura specifica che vale la pena adottare a prescindere: l'account sviluppatore resta tuo e il freelance vi accede come utente invitato, con permessi limitati e revocabili in un click. È il modo più semplice per rendere reversibile una scelta sbagliata.

Fase 8 — Disponibilità e tempi di consegna

Le domande che rivelano la disponibilità vera

Non chiedere "sei disponibile": ti risponderanno tutti di sì. Chiedi quante ore a settimana può dedicare al progetto e su quali giorni; quanti altri incarichi ha in corso e quando scadono; qual è il primo giorno utile per iniziare davvero, non per firmare; e cosa succede se arriva un cliente più grande a metà strada. Un professionista serio dichiara una capacità parziale — "posso darti due giorni a settimana" — ed è un'ottima risposta.

Il tempo che non dipende da nessuno dei due

Nelle app c'è una variabile che non controlli: la revisione degli store. Apple dichiara di esaminare la maggior parte delle app entro 24 ore, ma un rifiuto per una regola interpretata diversamente può costare giorni, e in prossimità delle festività i tempi si allungano. Il piano di consegna deve tenerne conto: la data di pubblicazione non è la data di consegna del codice, e chi te le presenta come la stessa cosa non ha mai pubblicato sotto scadenza.

I dati sui tempi, per quel che valgono

Gli unici numeri con metodo dichiarato sono quelli già citati: 3-6 mesi per un'app semplice, 6-9 per una di media complessità secondo GoodFirms; 11 mesi di durata media secondo Clutch. Sono medie di agenzie e vengono da directory commerciali. Servono a una cosa sola ma importante: riconoscere una promessa impossibile. Se qualcuno ti offre in sei settimane ciò che il resto del mercato consegna in sei mesi, non stai facendo un affare.

Consegne a fette e diritto di uscita

La tecnica che protegge di più non è una penale: è la frequenza delle consegne. Nelle app significa una cosa precisa: pretendere ogni due o tre settimane un'installazione di prova sul tuo telefono, non uno screenshot e non un video. Se al secondo rilascio qualcosa non torna, hai perso un mese e non un anno.

Con la stessa logica va scritta la possibilità di interrompere: una clausola di uscita al termine della prima fase, senza penali, con il codice già tuo e già sul tuo repository. In trattativa non costa quasi nulla e nel caso peggiore vale l'intero progetto.

Dopo la pubblicazione: la manutenzione è obbligatoria, non opzionale

Questa è la differenza più grande fra un'app e un sito, e va detta a chiare lettere prima di firmare. Le scadenze ricorrenti documentate sulle pagine ufficiali dei due store sono almeno quattro all'anno: la scadenza SDK di Apple in aprile, la release Android maggiore con cambiamenti di comportamento intorno a giugno, la scadenza del target API di Google Play il 31 agosto, il rilascio della nuova versione di iOS a settembre. Android è passato peraltro a quattro rilasci SDK all'anno, pur mantenendo un solo obbligo annuale di target API.

A queste si aggiungono i requisiti puntuali, imprevedibili: solo nei ventiquattro mesi fra ottobre 2024 e settembre 2026 se ne contano oltre una dozzina fra i due store, dal trader status europeo alle nuove classificazioni per età, fino all'obbligo di registrare tutte le app in Play Console entro il 30 settembre 2026, pena la rimozione.

Un'app senza un accordo di manutenzione non è un'app più economica: è un'app con una data di scadenza che nessuno ha scritto sul contratto. L'accordo deve dire quante ore l'anno sono incluse, in quanto tempo il freelance risponde a un blocco, e chi si occupa degli adeguamenti obbligatori — che vanno fatti anche se l'app non cambia di una virgola.

Il contratto: account, chiavi di firma, codice

Tre clausole valgono più di tutto il resto.

Gli account sono tuoi. Apple Developer, Google Play Console, i servizi esterni a pagamento, il dominio: intestati alla tua azienda, con le tue credenziali di recupero e il freelance aggiunto come utente. Vale anche per il servizio di notifiche e per gli strumenti di statistica, che spesso restano dimenticati sull'account di chi ha fatto il lavoro.

Le chiavi di firma sono tue e vanno consegnate. È il punto più tecnico e il più pericoloso: senza la chiave di firma originale un'app Android non può essere aggiornata da nessun altro. Non è una difficoltà: è un'impossibilità, che si risolve solo pubblicando una nuova app e chiedendo a tutti gli utenti di reinstallarla. Va scritto nel contratto che le chiavi e i certificati vengono consegnati alla chiusura, e va verificato che sia successo davvero.

La proprietà del codice va ceduta per iscritto. In Italia la norma che assegna al committente i diritti di utilizzazione economica riguarda il lavoro dipendente: non si applica al freelance. Se il contratto tace, i diritti patrimoniali restano a chi ha scritto il codice e la consegna dei sorgenti non è automatica. Servono la cessione esplicita, l'obbligo di consegna e il repository intestato a te fin dal primo giorno, con il freelance invitato come collaboratore.

La scelta in pratica, per tipo di progetto

App semplice, senza server proprio. Un freelance singolo va benissimo. Verifica il portafoglio sugli store, chiedi una prova pagata di compilazione e consegna, e metti nel contratto account e chiavi di firma. Il rischio principale non è tecnico: è che l'app resti ferma dopo la consegna.

App con server, accessi e notifiche. Chiarisci subito chi fa la parte server e chi la mantiene: è la voce che manca più spesso nei preventivi. Prima fase di analisi a prezzo fisso e separata, consegne ogni due settimane con installazione di prova sul tuo telefono.

App su entrambi i sistemi con budget limitato. Il cross-platform riduce il costo iniziale, ma chiedi al freelance di dirti esplicitamente cosa non potrà fare con quella scelta, e quanto costerebbe aggiungerlo dopo in nativo.

App che deve durare anni. Un freelance singolo va bene se — e solo se — il contratto rende il progetto indipendente da lui: account tuoi, chiavi consegnate, repository tuo, ambiente ricostruibile, e un accordo di manutenzione che copra esplicitamente le scadenze annuali degli store. Senza quelle condizioni, a parità di prezzo, la continuità di una struttura vale la differenza.

Conclusioni

Se di questa guida dovesse restare una riga sola, per le app non è la stessa del web: l'app che stai comprando è di chi possiede l'account e le chiavi di firma. Tutto il resto — la qualità del codice, l'eleganza dell'interfaccia, il rispetto dei tempi — conta moltissimo, ma si può recuperare cambiando fornitore. Un'app pubblicata sull'account di qualcun altro, con una chiave di firma che non hai, no.

Sul resto, i dati dicono cose abbastanza chiare: scrivi due pagine di requisiti prima di cercare; struttura il colloquio, perché è l'unica mossa che raddoppia la qualità della previsione; paga le prove pratiche e chiedi una compilazione vera invece di un esercizio; ignora gli anni di esperienza come criterio di scrematura; verifica il portafoglio sulle schede degli store e non sugli screenshot; e metti a preventivo la manutenzione, perché sulle app non è una scelta ma un obbligo con quattro scadenze all'anno.

Domande frequenti

Quanto costa sviluppare un'app con un freelance?

Le uniche cifre con metodo dichiarato vengono da directory commerciali: GoodFirms, su 267 aziende, colloca un'app semplice fra 15.000 e 40.000 dollari e una di media complessità fra 40.000 e 120.000; Clutch indica un costo medio di progetto di circa 90.000 dollari e tariffe fra 25 e 49 dollari l'ora. Sono medie di agenzie, non di freelance, e i campioni sono auto-selezionati. Sulle tariffe, i barometri Malt 2026 danno per i profili mobile esperti 551 € al giorno in Francia e 291 € in Spagna; in Italia un barometro pubblico non esiste.

L'app va pubblicata sul mio account sviluppatore o su quello del freelance?

Sul tuo, salvo motivi molto specifici. Costa 99 dollari l'anno per Apple e 25 una tantum per Google, e ti evita di dover recuperare un'app da un account altrui quando il rapporto finisce. C'è anche una ragione che riguarda il freelance: per il Digital Services Act chi pubblica come "trader" deve esporre indirizzo, telefono ed email sulla pagina dell'app in tutta l'Unione europea, e dal 17 febbraio 2025 Apple rimuove le app di chi non ha fornito lo status. Se l'app esce dal suo account, sulla tua scheda compaiono i suoi recapiti personali.

Conviene un'app nativa o cross-platform?

Dipende da quanto l'app usa le funzioni del telefono e da quanto ti importa poter cambiare fornitore. Il cross-platform riduce il costo iniziale ma non dimezza la manutenzione: le scadenze annuali di Apple e Google valgono uguali, e si aggiunge la dipendenza dal ciclo di rilascio del framework. Un avvertimento sui dati: le statistiche aggiornate su Flutter e React Native che circolano non esistono, perché la Stack Overflow Survey ha rimosso quella sezione nel 2025 e l'ultimo dato disponibile è del 2024.

Cosa succede se dopo la consegna nessuno aggiorna l'app?

Smette di poter essere aggiornata, e in alcuni casi viene rimossa. Le scadenze ricorrenti dei due store sono almeno quattro all'anno: l'obbligo di ricompilare con l'SDK più recente di Apple in aprile, la release Android maggiore a giugno, la scadenza del target API di Google Play il 31 agosto, la nuova versione di iOS a settembre. Nei soli ventiquattro mesi fra ottobre 2024 e settembre 2026 si contano oltre una dozzina di requisiti puntuali aggiuntivi. Un accordo di manutenzione con un monte ore annuo fa parte del preventivo iniziale.

Come faccio a capire se il portafoglio che mi mostra è davvero suo?

Chiedi i collegamenti alle schede pubbliche sugli store, non gli screenshot dell'emulatore, e leggi cinque cose: la data dell'ultimo aggiornamento, a nome di chi è pubblicata l'app, il contenuto delle recensioni negative, se lo sviluppatore risponde, e la sezione sui dati raccolti. Poi scaricane due e usale cinque minuti con la rete disattivata. Se le app del portafoglio sono tutte pubblicate sull'account del freelance, sai già che i suoi clienti non possiedono le proprie app.

Di chi è il codice e chi tiene le chiavi di firma?

Il codice è di chi lo ha scritto, se il contratto non dice il contrario: la norma italiana che assegna al committente i diritti di utilizzazione economica riguarda il lavoro dipendente e non si applica ai freelance. Le chiavi di firma sono un problema ancora più concreto: senza la chiave originale un'app Android non può essere aggiornata da nessun altro, e l'unica via d'uscita è pubblicare una nuova app e far reinstallare tutti gli utenti. Vanno scritte tre cose: cessione dei diritti, consegna di sorgenti, certificati e chiavi alla chiusura, e repository intestato a te fin dal primo giorno.

Come Scegliere uno Sviluppatore App Mobile Freelance nel 2026