Django, Flask o FastAPI: come scegliere il framework Python giusto per il tuo progetto, e quanto costa farlo bene
Python è il linguaggio di programmazione più usato al mondo: nell'indice TIOBE di agosto 2026 vale il 18,53%, davanti a C, C++ e Java, con JavaScript sesto al 2,63%. È un primato che dura da anni e che ha una conseguenza pratica per chi sviluppa su commessa: la domanda non arriva da una nicchia, arriva da tutte le direzioni contemporaneamente — web, automazione, dati, intelligenza artificiale.
Il dato italiano lo conferma. Il 20 agosto 2026 su Indeed Italia gli annunci che citano Python erano 2.215, contro 1.277 per JavaScript, 1.234 per Java e 495 per PHP. Sono ricerche testuali, non tassonomie di ruolo — un annuncio che cita Python fra i "gradito" conta lo stesso — ma come ordine di grandezza relativo il segnale è netto.
C'è però una domanda che questo primato non risolve, ed è quella che conta davvero quando si apre un progetto: quale framework. Perché nel mondo PHP la risposta è quasi obbligata, mentre in Python ci sono tre strade mature e diverse fra loro — Django, Flask e FastAPI — e sceglierne una determina la velocità di sviluppo, il costo di manutenzione, chi puoi assumere e quanto ti costerà cambiare idea fra due anni. Questa guida serve a fare quella scelta con cognizione di causa, e a capire cosa serve saper fare per essere pagati bene mentre la si esegue.
INDICE DEI CONTENUTI
- Python nello sviluppo web: cosa lo rende diverso
- Django: il full-stack con le batterie incluse
- Flask: il micro-framework che non decide al posto tuo
- FastAPI: lo standard di fatto per le API
- Quale framework per quale tipo di progetto
- Quale framework per quale tipo di team
- Costi associati a un progetto Python
- Competenze necessarie per essere un bravo freelance Python
- Ruoli e abilità richiesti nei progetti Python
- Tariffe: quanto costa e quanto si guadagna con Python in Italia
- Importanza di Python nelle organizzazioni
- Conclusioni
- Domande frequenti
Python nello sviluppo web: cosa lo rende diverso
Python non è nato per il web e questo, paradossalmente, è la sua forza attuale. È un linguaggio generalista finito per caso al centro di due mercati che si stanno sovrapponendo: le applicazioni web e l'intelligenza artificiale.
Un linguaggio, due mercati che convergono
Il report Octoverse 2025 di GitHub fotografa bene la situazione: TypeScript ha superato Python come linguaggio numero uno per contributori sulla piattaforma (2,6 milioni contro 2,55), ma 582.196 repository etichettati come AI usano Python, in crescita del 50,7% in un anno. Python ha perso lo scettro generalista e ha vinto quello che nei prossimi anni pesa di più.
Per un freelance questo significa una cosa molto concreta: lo stesso linguaggio con cui costruisci un gestionale ti permette di aggiungerci sopra un modulo di ricerca semantica, un classificatore di documenti o un agente conversazionale, senza cambiare stack, senza introdurre un secondo servizio in un'altra tecnologia e senza dover coordinare due persone diverse. È la ragione per cui, nel 2026, un cliente che parte con "mi serve un portale" finisce spesso per chiedere "e ci si può integrare l'AI?" — e con Python la risposta è sì senza riscrivere nulla.
Tre framework, non uno
La distribuzione degli utilizzi è più equilibrata di quanto si pensi. Nel Python Developers Survey di JetBrains e Python Software Foundation (oltre 30.000 rispondenti), FastAPI è passato dal 21% del 2021 al 38%, superando Django al 35% e Flask al 34%. Nella Stack Overflow Developer Survey 2025 l'ordine si conferma: FastAPI 14,8%, Flask 14,4%, Django 12,6% sul totale dei rispondenti.
Attenzione a come si legge questo dato: non è una classifica di qualità e nemmeno un sorpasso in senso stretto. Le percentuali si sommano a più del 100% perché moltissimi progetti ne usano due insieme — tipicamente Django per il back-office e FastAPI per le API pubbliche. Il messaggio vero è che nessuno dei tre sta morendo, e che la scelta è reale.
Quello che Python non ti regala
Il limite storico è il GIL, il lock che impedisce a più thread di eseguire bytecode Python contemporaneamente. Dal 2026 la situazione si sta muovendo: la PEP 779 ha reso la build free-threaded ufficialmente supportata — non più sperimentale — a partire da Python 3.14, ma resta opzionale e non c'è una data per renderla predefinita. La stessa documentazione ufficiale misura un costo dell'1% su macOS aarch64 e fino all'8% su Linux x86-64 nell'esecuzione a singolo thread, più un consumo di memoria maggiore. Tradotto per un preventivo: nel 2026 il no-GIL non è ancora una leva su cui contare, è una cosa da tenere d'occhio.
Il secondo limite è il deploy. Una applicazione PHP la si mette online caricando file su un hosting condiviso; una applicazione Python richiede un processo che resta vivo, un process manager, un reverse proxy e — nel 2026 — quasi sempre un container. Non è difficile, ma è una competenza in più da avere o da comprare, ed è la ragione principale per cui le tariffe Python partono più alte di quelle PHP.
In sintesi
Python porta in dote un mercato del lavoro largo, il monopolio di fatto sull'AI e la possibilità di coprire web, dati e automazione con una sola competenza. In cambio chiede una scelta architetturale in più all'inizio (quale framework) e un livello di infrastruttura che il mondo PHP tradizionale non richiedeva.
Django: il full-stack con le batterie incluse
Django è il framework più anziano dei tre e il più completo: ORM, sistema di autenticazione e permessi, pannello di amministrazione generato automaticamente, migrazioni, form, template, internazionalizzazione, protezioni di sicurezza attive per impostazione predefinita. La versione stabile attuale è la 6.1, uscita il 5 agosto 2026, mentre la LTS di riferimento resta la 5.2 di aprile 2025, supportata fino ad aprile 2028.
I vantaggi
L'admin è la funzionalità più sottovalutata del settore. Per una categoria intera di progetti — gestionali, cataloghi, portali con redazione, applicazioni interne — il pannello generato da Django copre l'80% di ciò che il cliente chiama "back-office", gratis, il primo giorno. Su un preventivo sono settimane di lavoro che semplicemente non compaiono.
Le decisioni sono già prese. Struttura delle cartelle, ORM, sistema di migrazioni, gestione utenti: due sviluppatori Django che non si sono mai parlati si orientano nello stesso codice in mezza giornata. È una proprietà che vale molto sui progetti destinati a durare e a cambiare mani.
La sicurezza è attiva di default. Protezione CSRF, escaping automatico nei template, query parametrizzate nell'ORM, e dalla versione 6.0 anche la Content Security Policy nativa. Con un micro-framework tutto questo lo devi montare tu, e ricordarti di farlo.
Il ciclo di vita è prevedibile. Le LTS hanno tre anni di supporto, e dal 2028 Django passerà al versionamento per anno con tre anni di supporto per tutte le release, non solo per le LTS. Per un'azienda è la differenza tra pianificare gli aggiornamenti e subirli.
Gli svantaggi
È pesante quando non ti serve tutto. Se il progetto è un servizio che espone sei endpoint JSON e non ha né utenti né back-office, Django ti fa portare in giro un'infrastruttura che non usi.
L'async è arrivato, ma con asterischi importanti. La documentazione ufficiale è esplicita: le transazioni non funzionano ancora in modalità asincrona e vanno isolate in funzioni sincrone chiamate con sync_to_async(); le connessioni persistenti (CONN_MAX_AGE) vanno disabilitate in favore di un pool lato database; chiamare l'ORM sincrono da un contesto async solleva un'eccezione. Chi arriva da Node o da FastAPI e si aspetta un async trasparente resta deluso.
Il framework dei task in background non è ancora completo. Django 6.0 ha introdotto un'API ufficiale per i job asincroni, ma la release include solo il backend immediato per sviluppo e test: il worker di produzione non c'è. Nel 2026 chi ha bisogno di code serie continua a installare Celery, con Redis o RabbitMQ a fianco. Va messo nel preventivo, non dato per incluso.
Sulle prestazioni pure è l'ultimo dei tre, anche se meno di quanto si legga in giro (i numeri sono più avanti, nella sezione sui benchmark).
Chi lo usa
Il backend di Instagram è un monolite Django descritto dal loro blog di ingegneria come "diversi milioni di righe e qualche migliaio di endpoint". Fra i corporate member della Django Software Foundation compaiono Sentry, JetBrains, PostHog, Kraken Tech, American Express e Zapier. È il framework che regge applicazioni grandi e longeve.
Flask: il micro-framework che non decide al posto tuo
Flask fa una cosa sola: instrada richieste HTTP verso funzioni Python. Tutto il resto — ORM, autenticazione, validazione, migrazioni — lo scegli e lo monti tu, di solito con SQLAlchemy, Flask-Login, Marshmallow e Alembic. La versione corrente è la 3.1.3 del 18 febbraio 2026.
I vantaggi
Non ti impone niente. Quando il progetto ha una forma sua — un modello dati che non assomiglia a un CRUD, un database legacy che non puoi toccare, un servizio che fa una cosa strana molto bene — la libertà di Flask è un vantaggio reale, non ideologico.
Si impara in un pomeriggio e si legge in mezz'ora. Una applicazione Flask piccola è comprensibile per intero da una persona sola. Per un tool interno, un webhook, un microservizio o un prototipo da mostrare a un investitore è esattamente ciò che serve.
Consuma poco. Nei benchmark citati più avanti l'impronta di memoria di una app Flask è circa un terzo di quella di una Django equivalente. Su container piccoli e piani di hosting a 512 MB conta.
È ovunque nell'esistente. Una quota enorme di codice Python scritto fra il 2014 e il 2022 è Flask: dashboard interne, script promossi a servizio, API di laboratorio. Saperlo manutenere è un mercato in sé, spesso meno affollato di quello dei progetti nuovi.
Gli svantaggi
Ogni progetto è diverso dal precedente. La stessa libertà che è un pregio al primo giorno diventa un costo al ventesimo mese: due applicazioni Flask scritte da due persone diverse non si somigliano, e l'onboarding di un nuovo sviluppatore è lento perché non c'è una convenzione da conoscere, c'è una casa da esplorare.
La sicurezza è tutta responsabilità tua. Niente CSRF di default, niente policy sulle password, niente permessi. Le dimenticanze in questa lista sono la causa più comune dei problemi che si trovano negli audit su applicazioni Flask.
È sincrono per natura. Il supporto async esiste ma è parziale; il progetto async dei Pallets è Quart, un framework separato. Per un servizio ad alta concorrenza su I/O, Flask non è la scelta giusta nel 2026.
Lo sviluppo è in modalità manutenzione. Dal changelog ufficiale: 3.1.0 a novembre 2024, poi solo patch — 3.1.1, 3.1.2, 3.1.3 — e nessuna minor o major annunciata. Non è un progetto abbandonato, è un progetto finito: la distinzione è importante ma va detta al cliente prima che la scopra da solo.
FastAPI: lo standard di fatto per le API
FastAPI è il più giovane dei tre e ha vinto la sua nicchia in cinque anni. L'idea centrale è usare i type hint di Python come contratto: dichiari i tipi di input e output, e il framework ne ricava validazione, serializzazione, gestione degli errori e documentazione OpenAPI interattiva, senza che tu scriva una riga in più.
I vantaggi
La documentazione si scrive da sola ed è sempre vera. Su un progetto in cui il backend è tuo e il frontend o l'app mobile sono di qualcun altro, questo elimina la classe di problemi più costosa che esista in una collaborazione: la documentazione disallineata dal codice. Da sola vale la scelta.
Validazione seria e gratuita. FastAPI richiede Pydantic v2, il cui motore di validazione è scritto in Rust. I dati sbagliati vengono fermati al confine dell'applicazione con messaggi di errore già formattati, invece di propagarsi fino al database.
È async nativo. Costruito su Starlette e ASGI dal primo giorno, senza strati di compatibilità. Per un backend che passa il tempo ad aspettare — chiamate a servizi esterni, modelli di linguaggio, code — è la differenza tra reggere la concorrenza e comprare server più grandi.
È il framework dell'ecosistema AI. Non è un'impressione: il server OpenAI-compatible di vLLM è costruito con FastAPI, e Apache Airflow, nella versione 3.0, ha riscritto REST API e API interne su FastAPI spostando Flask AppBuilder fuori dal core. Quando un progetto delle dimensioni di Airflow migra, il segnale è forte.
Gli svantaggi
Non c'è niente oltre le API. Nessun ORM, nessuna migrazione, nessun admin, nessuna autenticazione. Servono SQLAlchemy o SQLModel, Alembic, e una gestione utenti scritta a mano o presa da terze parti. Su un progetto che ha bisogno di back-office, il vantaggio iniziale si brucia in fretta.
È ancora in 0.x. La versione corrente è la 0.141.1, e nella roadmap ufficiale non compare né una versione 1.0 né una data. In pratica le rotture sono rare e ben segnalate — e nel frattempo Starlette, la base su cui poggia, ha raggiunto la 1.0 nel marzo 2026 — ma su una gara pubblica o in un capitolato quel "0." va spiegato.
L'async non perdona gli errori. Una singola chiamata bloccante dentro una funzione async blocca l'intero event loop e fa crollare le prestazioni di tutto il servizio. È un errore che un principiante commette il primo giorno e che si manifesta solo sotto carico, cioè in produzione.
Dipende molto da una persona sola. Il progetto ruota attorno al suo autore, Sebastián Ramírez, che ha fondato una società attorno a FastAPI Cloud (public beta, con investimento di Sequoia). Può essere un bene — più risorse per il progetto — ma la concentrazione della governance è un rischio da mettere in conto.
I numeri veri sulle prestazioni
Qui va fatta una precisazione, perché la rete è piena di articoli che dichiarano FastAPI "sei volte più veloce di Flask". Nei benchmark comparabili di Sharkbench (test su richieste concorrenti con I/O e serializzazione JSON) i risultati sono: FastAPI su Uvicorn 1.185 richieste al secondo con 41 MB di memoria, Flask su Gunicorn 1.092 con 90 MB, Django su Gunicorn 950 con 130 MB. Il vantaggio reale di FastAPI è circa il 10% su Flask e il 25% su Django, non un ordine di grandezza.
Il dato più istruttivo di quella tabella è un altro: Django sotto Uvicorn scende a 390 richieste al secondo, meno della metà che sotto Gunicorn. Mettere un server ASGI sotto un'applicazione prevalentemente sincrona la peggiora. Sono le scelte di deploy, non il framework, a fare la differenza più grande — e i benchmark generici a fare i danni peggiori nelle decisioni architetturali.
Quale framework per quale tipo di progetto
Nella pratica la scelta si riduce a poche domande: c'è un back-office? il modello dati è regolare? il frontend è tuo o di qualcun altro? il carico è I/O-bound?
Gestionale, portale, marketplace, SaaS con pannello di amministrazione — Django, senza esitare. L'admin, i permessi e le migrazioni sono il 60% del lavoro e li hai il primo giorno.
API per app mobile o per un frontend React/Vue sviluppato da altri — FastAPI. La documentazione OpenAPI generata automaticamente è il contratto fra te e l'altro team, ed è sempre allineata al codice.
Backend di un prodotto AI, RAG, agenti, integrazione con modelli — FastAPI. È l'ambiente dove vivono gli SDK, le chiamate sono I/O-bound e lo streaming delle risposte è nativo. Se serve anche un back-office per gestire prompt e contenuti, il pattern comune è Django accanto, non al posto.
Microservizio, webhook, integrazione fra sistemi, tool interno — Flask. Poche centinaia di righe, nessuna cerimonia, nessuna dipendenza da mantenere per anni.
Prototipo o MVP da validare in poche settimane — dipende da cosa deve dimostrare. Se deve mostrare un flusso completo con utenti e dati, Django. Se deve dimostrare che una singola idea tecnica funziona, Flask o FastAPI.
E-commerce — Django con Saleor o Oscar se il negozio ha logiche fuori standard (B2B, listini per cliente, configuratori). Se invece è un catalogo con carrello e basta, una piattaforma dedicata come Shopify o WooCommerce costa meno di qualunque sviluppo su misura, ed è onesto dirlo al cliente.
Dashboard e strumenti sui dati — FastAPI come strato API sopra il data warehouse, oppure Django se gli utenti devono anche inserire e correggere dati, non solo guardarli.
Applicazione esistente da manutenere — il framework che c'è già. La riscrittura si giustifica solo con numeri alla mano (costo di manutenzione attuale contro costo della migrazione), mai con l'argomento "è vecchio".
In sintesi
Django quando il progetto ha utenti, ruoli e un back-office; FastAPI quando il prodotto è l'API o quando c'è di mezzo l'AI; Flask quando il progetto è piccolo, strano o entrambe le cose. E la combinazione Django più FastAPI nello stesso sistema non è un fallimento della scelta: è la configurazione più diffusa nei progetti maturi.
Quale framework per quale tipo di team
La parte che nei confronti tecnici manca quasi sempre: il framework giusto non dipende solo dal progetto, dipende da chi lo scriverà e da chi lo manterrà dopo.
Il freelance che lavora da solo
Django, nella maggior parte dei casi. Quando sei una persona sola il collo di bottiglia non è la velocità di esecuzione del codice, è la tua giornata: ogni componente che non devi scrivere e non dovrai debuggare a fine progetto è margine. L'eccezione è il freelance specializzato in integrazioni e AI, per cui FastAPI è la scelta naturale.
Team piccolo, da due a cinque persone
Qui la scelta si gioca sulla separazione. Se backend e frontend sono persone diverse, FastAPI con OpenAPI riduce drasticamente le riunioni di allineamento: il contratto è generato dal codice. Se invece il team lavora a tutto tondo sullo stesso prodotto, Django con i template e — dalla 6.0 — i template partials evita di costruire e mantenere due applicazioni per un prodotto solo.
Team strutturato o azienda con più squadre
Django per il cuore del sistema, FastAPI per i servizi periferici. Le convenzioni di Django valgono più della flessibilità quando le persone sono tante e cambiano: un nuovo assunto è produttivo in giorni, non in settimane. Flask, in questo contesto, è il framework che genera più debito, perché ogni squadra costruisce le proprie convenzioni e poi non si parlano.
Team con turnover alto o consulenti che si alternano
Django, senza discussione. È il framework in cui il codice scritto da chi se n'è andato resta leggibile da chi arriva, perché la struttura è imposta dall'esterno. È anche l'unico dei tre con un bacino di sviluppatori italiani ampio e con esperienza pluriennale su progetti grandi.
Team che viene dai dati e non dal web
Data scientist e ricercatori che devono esporre un modello arrivano quasi sempre a FastAPI, ed è corretto: la distanza fra una funzione Python e un endpoint documentato è di due righe. Il rischio da presidiare è opposto — quel servizio nato come esperimento finisce in produzione senza autenticazione, senza log e senza test — ed è esattamente il punto in cui un freelance esperto viene chiamato e pagato bene.
In sintesi
Più il team è numeroso, più cambia nel tempo e meno controllo hai su chi ci lavorerà dopo di te, più le convenzioni di Django valgono. Più il team è piccolo, specializzato e stabile, più la libertà di Flask e FastAPI diventa un vantaggio invece che un rischio.
Costi associati a un progetto Python
Il framework è gratis, il progetto no
Django, Flask e FastAPI sono open source e senza licenze commerciali: a differenza del mondo PHP, dove un pannello di amministrazione professionale è spesso un prodotto a pagamento, in Python l'admin di Django è incluso. La spesa vera, come sempre, sono le persone e il tempo.
Hosting: tre strade con prezzi molto diversi
La strada PaaS è la più semplice: si consegna il codice e la piattaforma fa il resto. Render parte da 7 dollari al mese per un'istanza sempre attiva (il piano gratuito esiste ma spegne il servizio dopo 15 minuti di inattività, con circa un minuto di risveglio); Railway da 5 dollari di crediti a consumo; Heroku da 5 dollari (dorme) o 7 sempre attivo; DigitalOcean App Platform da 5 dollari; PythonAnywhere da 10 dollari. A questi va quasi sempre aggiunto un database gestito, dai 5-6 dollari al mese in su.
La strada serverless conviene ai carichi intermittenti: AWS Lambda costa 0,20 dollari per milione di richieste più il tempo di calcolo, con un milione di richieste al mese gratuite; Google Cloud Run ha una logica analoga. Il conto è vicino a zero per un servizio poco usato, ma i cold start e i limiti sulle connessioni al database vanno progettati, non scoperti.
La strada VPS resta la più economica in rapporto alle risorse: un Hetzner CX23 costa 5,49 euro al mese per 2 vCPU e 4 GB di RAM — cinque o dieci volte le risorse di un PaaS allo stesso prezzo — in cambio della gestione del server, che è lavoro tuo o di qualcuno che paghi. Da segnalare che Hetzner ha aumentato i listini il 15 giugno 2026, in alcuni casi in modo consistente: è il promemoria che l'infrastruttura a basso costo non è un dato acquisito per sempre.
C'è infine una novità del 2026: FastAPI Cloud, la piattaforma degli autori del framework, in public beta con un piano gratuito e un Pro a 20 dollari per utente. È presto per legarci un progetto di produzione, ma è un'opzione da conoscere.
Servizi esterni e componenti a pagamento
Le voci ricorrenti sono le stesse di qualunque progetto web — email transazionali, storage per i file, monitoraggio degli errori, CDN, pagamenti — a cui in un progetto Python si aggiungono spesso Redis (per cache e code Celery) e, se c'è AI, il consumo dei modelli. Quest'ultima voce è quella che sfugge più facilmente: è a consumo, cresce con l'uso e va stimata con un tetto di spesa fin dal primo giorno, altrimenti si scopre a fine mese.
Manutenzione e ciclo di vita
Python rilascia una versione all'anno con cinque anni di supporto — la 3.14 è del 2025, la 3.15 è attesa per il 1° ottobre 2026 — e Django ha un calendario di LTS pubblicato con anni di anticipo. La manutenzione quindi si può pianificare, ma esiste: mettere a budget una o due giornate a semestre per aggiornamenti di sicurezza e dipendenze è realismo, non prudenza eccessiva. Il rischio maggiore non sono i framework, sono le librerie di contorno: un progetto Flask con quaranta dipendenze scelte una per una invecchia molto peggio di un progetto Django con dieci.
In sintesi
Il costo di ingresso di un progetto Python è basso — dai 5 ai 15 euro al mese di infrastruttura per un'applicazione piccola — e la voce dominante restano le giornate uomo. Le due sorprese classiche sono il consumo dei modelli AI e le code in background, che con Django 6 sembrano incluse ma in produzione richiedono ancora Celery e un broker.
Competenze necessarie per essere un bravo freelance Python
Python prima del framework
Vale qui quanto vale altrove: chi conosce Django ma non Python si blocca al primo problema che non sta nella documentazione. Le cose che fanno la differenza nella pratica quotidiana sono i generatori e la valutazione pigra, i context manager, i decoratori, asyncio e il modello a event loop, la gestione della memoria e degli oggetti mutabili condivisi. Non è accademia: sono le cause del 90% dei bug che si manifestano solo sotto carico.
Async, capito davvero
Nel 2026 questa è la competenza che separa chi prende una tariffa media da chi prende una tariffa alta. Non basta saper scrivere async def: bisogna sapere cosa succede quando dentro una funzione asincrona si chiama una libreria bloccante, quando conviene restare sincroni, come si dimensionano i worker (la regola di Gunicorn è due volte i core più uno, e la documentazione avverte che quattro-dodici worker bastano per centinaia o migliaia di richieste al secondo), e perché mettere Uvicorn sotto un'applicazione Django sincrona la rallenta invece di accelerarla.
Database e ORM, in entrambe le direzioni
Saper usare l'ORM di Django o SQLAlchemy è il minimo; saper leggere il SQL che generano è ciò che ti fa risolvere in un'ora il problema di lentezza su cui il cliente ha perso un mese. Indici, piani di esecuzione, query N+1 — un tema su cui, per inciso, Django 6.1 ha introdotto i fetch mode dei campi, pensati proprio per intercettarle — e transazioni. E la consapevolezza che una migrazione su una tabella da dieci milioni di righe non si lancia in produzione alle undici del mattino.
Tipizzazione e validazione
I type hint non sono più opzionali in un progetto professionale. Pydantic è di fatto uno standard trasversale — non solo in FastAPI — e mypy o Pyright in pipeline sono ciò che rende manutenibile un progetto Python grande. È anche la risposta più efficace all'obiezione classica del cliente che arriva dal mondo Java o C#: "ma Python non è tipizzato".
Testing
Pytest, fixture, factory per i dati di test, mock dei servizi esterni, e almeno una copertura seria sui flussi che toccano soldi o dati sensibili. In un progetto freelance i test non servono a fare bella figura: servono a poter dire "sì" a una modifica dell'ultimo minuto senza passare la notte a controllare a mano tutto il resto.
Deploy, container e osservabilità
Docker come minimo sindacale, una pipeline CI che esegua i test e faccia il deploy, log strutturati, un servizio di error tracking e qualche metrica. In Python questa parte pesa più che altrove — non esiste l'equivalente del "carico i file via FTP" — ed è la competenza che permette di prendersi in carico un progetto intero, che è poi la ragione per cui un cliente paga un freelance senior invece di due junior.
Un frontend, a scelta, ma serio
Chi lavora con Django può cavarsela benissimo con template, HTMX e Alpine, coprendo la maggioranza dei gestionali senza mai scrivere una SPA. Chi lavora con FastAPI ha bisogno di React o Vue almeno a livello di lettura, per parlare con il team frontend. La scelta non conta, la superficialità sì: mezzo frontend è la fonte principale dei progetti che sforano.
AI: la competenza che sposta la tariffa
L'ecosistema si è consolidato: LangChain e LangGraph hanno raggiunto la 1.0 nell'ottobre 2025, gli SDK ufficiali di OpenAI e Anthropic sono maturi, PyTorch resta lo standard per l'addestramento. Ma la competenza che i clienti pagano non è "so usare una libreria": è saper progettare una pipeline RAG che non allucina, valutare la qualità delle risposte con metriche invece che a sensazione, tenere sotto controllo i costi di inferenza e gestire l'idempotenza quando il modello sbaglia. Il contesto italiano la rende una scommessa ragionevole: secondo Istat, nel 2025 il 16,4% delle imprese con almeno 10 addetti usava già una tecnologia AI (era l'8,2% l'anno prima), e il 58,6% di chi ha valutato un investimento senza farlo indica come ostacolo la mancanza di competenze adeguate.
Le competenze che non stanno nel CV
Stimare senza sottostimare, dire di no a una richiesta fuori perimetro senza rompere il rapporto, scrivere una mail di aggiornamento che un non tecnico capisce, fatturare e farsi pagare. Sono le competenze che determinano se dopo tre anni fai ancora questo mestiere, ed è la ragione per cui due sviluppatori con la stessa bravura tecnica possono guadagnare il doppio l'uno dell'altro.
In sintesi
Le competenze tecniche ti fanno entrare nel mercato Python; async, database e deploy ti fanno restare; l'AI e la capacità di prendere in carico un progetto intero sono ciò che sposta la tariffa verso l'alto.
Ruoli e abilità richiesti nei progetti Python
Un progetto Python di media dimensione mette al lavoro competenze che sulla carta sono ruoli diversi, e che nella realtà italiana ricadono spesso su una o due persone.
Backend developer Python — il centro del progetto: modello dati, logica applicativa, API, integrazioni. È il ruolo più richiesto e quello con il bacino più ampio.
API developer e integratore — una specializzazione a sé quando il lavoro consiste nel far parlare sistemi che non si sono mai parlati: ERP, CRM, gestionali, servizi di pagamento. Qui contano più i protocolli, la gestione degli errori e l'idempotenza che il framework.
Frontend developer — necessario quando l'interfaccia è complessa; superfluo su un gestionale Django ben fatto con template e HTMX. È la prima voce da valutare onestamente, perché è quella che raddoppia i preventivi.
Data engineer — pipeline, ETL, orchestrazione con Airflow o Prefect, qualità del dato. Sempre più spesso presente anche in progetti che nascono come "semplice" applicazione web, perché il cliente vuole i report.
AI/ML engineer — dall'integrazione di modelli via API fino al fine-tuning e al deploy di modelli propri. È il ruolo con il differenziale di tariffa più alto e con il bacino più stretto.
DevOps — container, CI/CD, infrastruttura, monitoraggio. Su progetti piccoli è il backend developer che se ne occupa; oltre una certa dimensione è un errore pensare che continui a bastare.
QA — test automatici e test esplorativi. Raramente una figura dedicata nei progetti freelance, quasi sempre una responsabilità distribuita.
Project manager o punto di contatto — su un progetto freelance è il freelance stesso, ed è tempo che va fatturato, non regalato.
Come si combinano nella pratica
Su un progetto piccolo, una persona copre backend, deploy e rapporto col cliente. Su un progetto medio si formano due nuclei — applicazione e dati — che devono concordare i contratti fra loro all'inizio, non a metà. Il momento più critico da presidiare non è "chi fa cosa", ma chi decide, il primo giorno, se il frontend è servito dal backend o è un'applicazione separata che consuma API: da quella scelta discende quanto coordinamento servirà per tutto il resto del progetto, e quale dei tre framework ha senso usare.
Tariffe: quanto costa e quanto si guadagna con Python in Italia
Il riferimento da dipendente
Serve come pavimento del ragionamento. Talent.com indica per uno sviluppatore Python in Italia una RAL media di 35.000 euro, con 30.000 in ingresso e 40.640 per i senior; Indeed riporta 31.275 euro su un campione più piccolo. Il breakdown per anzianità più solido disponibile in Italia è quello di TechCompenso sul ruolo generico di developer, su circa 1.900 segnalazioni: 27.775 euro sotto l'anno di esperienza, 31.181 fra uno e tre anni, 39.417 fra quattro e sei, 43.383 fra sette e nove, 52.363 oltre i dieci. Per contesto, la RAL media del settore privato italiano nel 2025 era di 32.991 euro.
Le tariffe freelance
Qui va detto con chiarezza un limite delle fonti: in Italia non esiste un barometro pubblico delle tariffe freelance per linguaggio paragonabile a quelli che Malt pubblica per Francia, Spagna e Regno Unito. I dati italiani disponibili sono autodichiarati e su campioni piccoli: le statistiche di LiberiPro indicano 318 euro al giorno per un backend developer, su appena diciannove rilevazioni.
Il dato europeo più utile, e il più citabile, viene dal barometro 2026 di Malt in Francia, costruito su quasi 40.000 sviluppatori freelance attivi: la tariffa giornaliera media di un backend è di 562 euro, e disaggregata per linguaggio dà Python a 601 euro, JavaScript/Node a 576 e PHP a 503. Python vale cioè circa il 19% in più del PHP a parità di ruolo. Il mercato italiano è strutturalmente più basso di quello francese, ma il differenziale fra linguaggi è l'informazione che si può trasferire.
Un modo pragmatico di leggere i numeri italiani: un senior con 45-50.000 euro di RAL costa all'azienda circa 70.000 euro l'anno; distribuito su 200 giornate effettivamente fatturabili — non 220, perché le ferie, la formazione, le offerte non vinte e l'amministrazione esistono — si ottiene una soglia di pareggio intorno ai 350 euro al giorno. Sotto quella cifra un freelance sta lavorando per meno di quanto varrebbe da dipendente, senza le tutele.
Quanto vale specializzarsi
Il differenziale è netto e concorde su più mercati. Su Upwork la mediana di uno sviluppatore Python è 30 dollari l'ora, mentre un DevOps engineer sta a 60 e un esperto di machine learning a 100: rispettivamente il doppio e più del triplo. Negli Stati Uniti la salary guide 2026 di Robert Half mette un AI/ML engineer a 170.750 dollari mediani contro i 142.000 di un software engineer, con l'87% dei responsabili IT che dichiara di pagare di più le competenze specializzate. In Francia, sempre secondo Malt, un esperto dati sta a 666 euro al giorno contro i 576 di uno sviluppatore.
In Italia il differenziale misurabile è molto più compresso — su TechCompenso un DevOps prende il 7,5% in più di un developer generico, un data scientist il 4% — ma quel dato riguarda il lavoro dipendente, dove la retribuzione si muove lentamente. Sul lavoro freelance, dove il prezzo lo fa la scarsità, la forbice è più simile a quella internazionale.
Perché la domanda regge
Il contesto italiano aiuta chi ha competenze solide. L' Osservatorio delle Competenze Digitali 2025 di AICA, Anitec-Assinform e Assintel ha contato 136.000 annunci ICT su LinkedIn in dodici mesi a fronte di 73.000 nuovi professionisti entrati sul mercato: un ingresso ogni due posizioni aperte. Sul fronte della spesa, l' Assintel Report 2025 dà il mercato digitale italiano a 44,3 miliardi di euro, in crescita del 4,5%, con l'intelligenza artificiale in aumento del 35,3%. E secondo Unioncamere-Excelsior, nei servizi informatici e delle telecomunicazioni le imprese dichiarano difficoltà di reperimento per oltre il 50% delle posizioni che cercano.
In sintesi
In Italia il riferimento realistico per un freelance Python è una fascia che parte da 250-300 euro al giorno per un profilo mid e supera i 450-500 per un senior con specializzazione riconoscibile, con la soglia di pareggio rispetto al lavoro dipendente intorno ai 350. Il linguaggio da solo vale un premio modesto: la tariffa alta la fa la combinazione fra Python e un secondo dominio — AI, dati o infrastruttura.
Importanza di Python nelle organizzazioni
Dal punto di vista di un'azienda che deve scegliere su cosa investire, Python ha tre proprietà che contano più dell'eleganza del codice.
Riduce il numero di stack da mantenere. L'applicazione web, gli script di integrazione, i job notturni, i report e i prototipi di AI possono stare tutti nello stesso linguaggio, con lo stesso team e la stessa pipeline. Per un'organizzazione media è la voce di risparmio più grande e la meno visibile in fase di preventivo.
Riduce la dipendenza da una singola persona. Il bacino di sviluppatori Python è ampio e in crescita, e su Django in particolare esiste in Italia una comunità con esperienza pluriennale su progetti grandi. Un progetto Django scritto con le convenzioni standard è un progetto che qualcun altro può riprendere in mano — che è la vera domanda dietro ogni scelta tecnologica aziendale.
Tiene aperta la porta dell'AI senza pagarla in anticipo. Un'azienda che costruisce oggi il suo gestionale in Python non deve decidere adesso se e quando introdurrà ricerca semantica, classificazione automatica dei documenti o un assistente interno. Quando arriverà il momento, sarà un modulo in più nello stesso progetto, non un secondo sistema da integrare. Dato che l'adozione dell'AI nelle imprese italiane è raddoppiata in un anno, è un'opzione che vale.
Il rovescio della medaglia, da dire con onestà: se il progetto è un sito vetrina, un blog o un e-commerce standard, Python è la scelta sbagliata. Lì WordPress, Shopify o un framework PHP come Laravel — di cui abbiamo parlato nella guida dedicata al freelance Laravel — costano meno e arrivano prima. Python conviene quando c'è logica di dominio vera, integrazioni, dati o intelligenza artificiale.
Conclusioni
Python nel 2026 non è una scommessa: è il linguaggio con la domanda più larga del mercato italiano e il monopolio di fatto sull'intelligenza artificiale. La decisione che conta non è "Python sì o no", è quale dei suoi tre framework usare, e quella scelta va fatta guardando due cose: la forma del progetto — c'è un back-office? il prodotto è l'API? — e la forma del team che lo manterrà nei prossimi tre anni.
Django quando servono utenti, ruoli e amministrazione, e quando il codice dovrà sopravvivere a chi lo ha scritto. FastAPI quando il prodotto è l'interfaccia programmatica, quando il carico è fatto di attese e quando c'è di mezzo l'AI. Flask quando il progetto è piccolo o ha una forma tutta sua e la libertà vale più delle convenzioni. Non sono scelte irreversibili e non si escludono: la configurazione più comune nei progetti maturi è Django e FastAPI che convivono, ciascuno dove rende meglio.
Per chi lavora da freelance il messaggio dei dati è coerente su tutti i mercati osservati: il linguaggio da solo vale un premio modesto rispetto alla concorrenza, mentre la specializzazione — AI, dati, infrastruttura — vale un multiplo. Python è il punto di partenza migliore che ci sia in questo momento, proprio perché è anche il punto di partenza di tutto il resto.
Domande frequenti
Meglio Django, Flask o FastAPI per iniziare?
Django, per una ragione pratica: essendo completo, ti costringe a incontrare tutti i pezzi di un'applicazione reale — modelli, migrazioni, autenticazione, permessi, form, sicurezza — invece di scoprirli uno alla volta quando qualcosa si rompe. Chi impara prima su Flask spesso scrive codice che funziona ma non regge la manutenzione. FastAPI è il secondo da imparare, non il primo, perché dà il meglio di sé quando si sa già cosa serve in un backend.
FastAPI ha davvero sostituito Flask e Django?
No, li ha affiancati. Nelle survey FastAPI è primo per adozione, ma le percentuali si sommano a più del 100%: moltissimi progetti usano due framework insieme. E la differenza di prestazioni è nell'ordine del 10-25% nei benchmark comparabili, non delle "sei volte più veloce" che si leggono nei confronti superficiali. Su un progetto con back-office, Django resta più economico da costruire e mantenere, punto.
Quanto guadagna un freelance Python in Italia?
La forbice realistica va dai 250-300 euro al giorno di un profilo mid ai 450-500 e oltre di un senior specializzato. La soglia sotto la quale non conviene lavorare è intorno ai 350 euro giornalieri, che è l'equivalente del costo aziendale di un dipendente senior distribuito su 200 giornate fatturabili. Il salto di tariffa non lo fa la seniority in Python, lo fa la seconda competenza: AI, dati o infrastruttura.
Conviene passare da PHP a Python?
Dipende da dove si vuole arrivare. In Italia il volume di annunci che citano Python è circa quattro volte e mezzo quello del PHP, e in Francia il differenziale di tariffa freelance fra i due linguaggi è del 19% a favore di Python. Ma il mercato PHP è più affollato di offerta e di domanda su progetti piccoli, che sono anche i più accessibili a chi comincia. La ragione migliore per spostarsi non è la tariffa in sé: è che Python è l'unica porta d'ingresso naturale al lavoro sull'intelligenza artificiale.
Serve saper fare frontend per lavorare con Python?
Non necessariamente una SPA. Con Django, template più HTMX e Alpine coprono la maggioranza dei gestionali e dei portali senza scrivere una riga di JavaScript strutturato. Serve però saper leggere e discutere il codice frontend quando l'interfaccia la fa qualcun altro, altrimenti ogni allineamento diventa una riunione. La regola pratica: o si conosce un framework frontend abbastanza da essere autonomi, o si conosce abbastanza da collaborare — la via di mezzo è quella che fa sforare i progetti.
Quanto costa mantenere online un'applicazione Python?
Per un'applicazione piccola con database gestito si sta fra i 10 e i 25 euro al mese su una piattaforma PaaS, o intorno ai 6 euro su un VPS in cambio della gestione del server. Le voci che fanno saltare il conto sono altre due: le code in background, che richiedono ancora un broker e un worker dedicato, e il consumo dei modelli AI, che è a consumo e va presidiato con un tetto di spesa dal primo giorno.