Da sviluppatore a consulente IT: la transizione, le insidie e cosa cambia davvero

Nel gennaio 2014 ho lasciato un contratto a tempo indeterminato come tech lead in una software house per avviare l'attività di consulente informatico freelance. Lo stipendio era sopra la media del mercato per il ruolo (1.800-2.000 euro netti al mese di allora), la posizione era stabile, il rapporto col management era buono. La decisione di uscire è stata mossa da una combinazione di insofferenza per la struttura gerarchica di progetto dove non potevo portare il valore che vedevo chiaro di dover portare, e dalla convinzione - si è rivelata in parte ingenua - che fare l'autonomo sarebbe stato "come fare il dev ma con più libertà". Negli undici anni successivi ho capito quanto quella convinzione fosse sbagliata nei dettagli che contano, e quanto il salto da sviluppatore senior a consulente indipendente sia una trasformazione professionale molto più sostanziale di quanto appaia dall'esterno.

I primi due anni sono stati un disastro economico mitigato solo dal fatto che avevo qualche risparmio e un costo della vita contenuto. Ho fatto tutti gli errori standard che vedo commettere oggi a colleghi che stanno pensando il salto: accettare lavori senza contratti scritti, quotare progetti a forfait sottostimando massicciamente gli effort, subire scope creep senza rinegoziare, accettare clienti che sapevo non mi avrebbero pagato in tempo, non costruire un pipeline commerciale che mi proteggesse da buchi di fatturato, sottovalutare il peso della fiscalità e del costo del mio tempo non-fatturabile. Nel terzo anno ho iniziato a correggere questi errori - alcuni sistematicamente, altri solo dopo essermi bruciato di nuovo - e dal quarto anno in poi l'attività è diventata economicamente solida. Questo articolo è il distillato pratico di quegli errori, per chi stia pensando al passaggio autonomo e voglia ridurre la curva di apprendimento rispetto a quello che ho fatto io. Non è una guida motivazionale - è la versione onesta che avrei voluto leggere nel dicembre 2013.

Il cambio mentale: da "produrre codice" a "produrre valore misurabile al cliente"

Il primo e più profondo cambiamento è mentale. Da sviluppatore, il valore che produci è implicito nel fatto che sei pagato uno stipendio - il tuo datore di lavoro ha deciso che i tuoi giorni di lavoro valgono X euro, e tu produci code a quel rate. Non devi articolare il valore del tuo output settimana per settimana. Da consulente, ogni singolo intervento deve essere commisurato a valore misurabile che il cliente percepisce e accetta di pagare. Scrivere codice "perché è interessante" senza legame esplicito con un risultato di business non è più un'opzione - è la ricetta del fallimento.

Questa transizione è particolarmente difficile per i developer senior, perché abbiamo tipicamente un'identità forte legata al "fare software bene". Ci piace il refactoring elegante, le architetture pulite, l'applicazione di pattern sofisticati. Da consulente, se un cliente paga per un gestionale funzionante in 8 settimane, devo consegnare un gestionale funzionante in 8 settimane - anche se il codice risultante è più "spaghetti" di quanto mi piacerebbe, anche se ci sono pattern che implementerei diversamente con più tempo. La disciplina del "shipping" prevale sulla ricerca del bello. I primi due anni ho spesso sforato budget perché "volevo farlo meglio". Ho imparato che la consulenza seria rispetta il budget del cliente, comunicando chiaramente i trade-off quando servono più soldi per più qualità.

Il secondo cambiamento mentale riguarda chi paga cosa. Come dipendente, il tuo tempo non produttivo (formazione, riunioni, burocrazia) è implicitamente pagato dall'azienda - fai queste cose in tempo "aziendale". Come autonomo, il tempo non fatturabile è a tuo carico. Calcolare una tariffa oraria sostenibile significa capire che le ore "fatturabili" sono molto meno del totale delle ore lavorate. Nei miei primi anni, lavoravo 60-70 ore/settimana ma ne fatturavo solo 25-35 - il resto era speso in commerciali, amministrazione, formazione, gestione operativa dell'attività. La tariffa oraria deve compensare per questo ratio, o l'economics non torna.

Il pricing: i tre errori sistematici dei primi due anni

Il pricing è probabilmente l'area dove ho sbagliato di più, e dove vedo sbagliare costantemente colleghi che fanno il passaggio freelance. Tre errori specifici.

Errore 1 - applicare la logica "stipendio di mercato / 160 ore". Molti neo-freelance partono dal proprio stipendio precedente (es: 2.200 euro netti al mese = ~35.000 euro lordi aziendali) e dividono per le ore lavorative standard (160 al mese) per ottenere una tariffa oraria "equivalente" (~220 euro/ora lordi → ~150 netti). Questo calcolo è sbagliato perché ignora i costi strutturali che il datore di lavoro copriva: contributi INPS/INAIL, TFR, ferie pagate, malattie, formazione, postazione di lavoro, strumenti, assicurazione. In Italia, il costo aziendale vero di un dipendente è circa 1.8-2.0x lo stipendio netto. Quindi una tariffa di 150 euro lordi orari non è equivalente a 2.200 netti al mese - è equivalente a circa 1.000-1.100 netti al mese, dopo aver coperto i costi strutturali del fare il consulente.

Errore 2 - non includere il tempo non-fatturabile. Se la tua tariffa è 80 euro/ora e lavori 160 ore al mese, il tuo lordo sarebbe 12.800 euro. Ma delle 160 ore, realisticamente fatturabili sono 90-100 (il resto è marketing, commerciale, amministrazione, formazione). Quindi il lordo effettivo è 7.200-8.000 euro/mese. Dopo le tasse italiane (regime forfettario ~20% se sotto soglia, regime ordinario 30-40%), netto intorno ai 4.000-5.500 euro/mese. Non terribile, ma molto meno del 12.800 euro del calcolo ingenuo.

Errore 3 - non differenziare per tipo di cliente. Un progetto per una startup senza fondi richiede la stessa tariffa oraria di un progetto per una multinazionale? No. Un cliente che richiede disponibilità 24/7 deve pagare premium, un cliente che accetta tempi di risposta 48h paga base. Nel mio secondo anno ho iniziato a introdurre differenziazione: tariffa "standard" per PMI italiane medie, tariffa "premium" per clienti enterprise con requisiti di SLA stretti, tariffa "partnership" per progetti strategici di lunga durata dove accetto pay ridotto in cambio di revenue share o quota di consulenza stabile. Questa differenziazione aumenta il fatturato medio del 25-40% a parità di ore lavorate, semplicemente capturando il surplus di valore sui clienti che possono pagarlo.

Oggi la mia struttura pricing, raffinata in 10 anni, ha cinque scaglioni calibrati sul valore specifico del cliente: tariffa oraria 120-150 euro per consulenze brevi/spot, tariffa mensile retainer 3.500-5.500 euro per clienti con presidio continuo garantito, forfait progetto con premio rischio 20-30% sopra la stima lineare, tariffa emergenza (weekend/notti) 2-3x la standard, bonus outcome-based 10-20% sul valore che il cliente ottiene (tipicamente accettato solo dai clienti più maturi).

I contratti: cosa pretendere per iscritto sempre, senza eccezioni

Il secondo grande apprendimento è stato sui contratti. Nei primi 18 mesi ho accettato clienti con accordi orali o con contratti vaghi scritti sotto forma di email. Il risultato prevedibile: scope che cresceva senza rinegoziazione, fatture contestate, pagamenti in ritardo o mai arrivati. Ho perso circa 15.000 euro di fatture non riscosse in quei 18 mesi - una frazione significativa del fatturato dell'epoca.

La regola che mi sono imposto dal 2016 in poi è: nessun lavoro per nessun cliente senza contratto scritto firmato prima dell'inizio. Il contratto minimo copre cinque clausole fondamentali. Prima: scope definito - cosa esattamente è nel perimetro del lavoro, cosa esplicitamente è escluso (perché il "escluso esplicito" è spesso più importante del "incluso"). Seconda: tariffa e modalità di fatturazione - hourly con rapportino settimanale, forfait con milestone payment, retainer mensile anticipato. Terza: termini di pagamento - 30 giorni data fattura è il massimo che accetto, 60-90 giorni (tipico della PA italiana) si applicano solo con anticipo del 30-50%. Quarta: clausola di rescissione - chi può interrompere il rapporto, con che preavviso, con quali obblighi residui. Quinta: proprietà intellettuale - chi possiede il codice sviluppato (il cliente), quali diritti mantengo io (portfolio, riutilizzo patterns generici, non riutilizzo di business logic specifica), quali dati tratto e come.

Il pattern di contratti che riflette anche la tutela del cliente, con clausole specifiche di escrow, documentazione obbligatoria, SLA e transizione di consegne, è esattamente quello che descrivo nel mio articolo sui contratti di manutenzione software e cosa devono contenere per proteggere la PMI italiana - le clausole che il cliente dovrebbe pretendere dal fornitore sono le clausole speculari che io mi impegno a fornire al cliente. La simmetria contrattuale costruisce fiducia operativa.

Il pipeline commerciale: il lavoro invisibile che mangia metà del tempo

Il terzo grande apprendimento, e quello meno compreso dai developer che pensano al freelance, è che il lavoro commerciale è lavoro continuo. Come dipendente, il commerciale non esiste - ogni lunedì mattina il lavoro ti aspetta. Come freelance, il lunedì mattina devi decidere se hai abbastanza lavoro per le prossime 8 settimane, e se non hai, devi dedicare tempo al commerciale invece che alla produzione.

Il pattern che mi sono imposto dopo il primo grosso "buco" di fatturato (tre settimane senza progetti attivi a maggio 2016, quasi 10.000 euro di mancato fatturato) è di dedicare il 15-20% del tempo fissamente al commerciale, indipendentemente da quanto pieno sia il pipeline del momento. Nella pratica: un giorno alla settimana dedicato a newsletter, scrittura di articoli per il mio blog, risposta a richieste prospect, networking con colleghi e partner, manutenzione della presenza online (Linkedin, ora anche altri canali). Non "quando posso" ma sempre, anche quando il business è al massimo carico.

Questa disciplina è il singolo cambiamento più importante per la sostenibilità economica. I colleghi che vedo fallire il freelance tipicamente hanno questo pattern: producono tanto quando hanno lavoro, si fermano totalmente quando hanno buchi. Il pipeline si svuota, il commerciale ricomincia da zero, servono 4-6 settimane per riempirlo. Nel frattempo il fatturato è zero o minimale. Il pattern di produzione costante di valore editoriale mi ha permesso di avere un pipeline tipicamente 3-6 mesi avanti - non aspetto mai di "aver bisogno di lavoro" per cercarlo, perché il flusso inbound è costante grazie al lavoro fatto mesi prima.

Stai pensando al passaggio da sviluppatore dipendente a consulente freelance/autonomo e vuoi un confronto pragmatico su come strutturare pricing, contratti, pipeline commerciale e rapporto con i clienti italiani? Nel mio profilo professionale trovi i dettagli della mia attività di consulenza e puoi vedere come ho strutturato l'offerta dopo 11 anni di iterazioni - il pattern che funziona per me non è l'unico possibile, ma può essere un punto di riferimento concreto per tarare le tue scelte.

La fiscalità: il capitolo che uccide i freelance inesperti

Il quarto grande errore dei miei primi due anni è stato sottovalutare massicciamente l'impatto fiscale e contributivo. L'Italia ha un sistema che si può articolare su due principali regimi per professionisti IT: il regime forfettario (flat tax 15% sotto certe soglie di fatturato) e il regime ordinario (IRPEF progressiva 23-43% + IRAP). Le implicazioni sono molto diverse.

Regime forfettario. Soglia attuale: 85.000 euro di fatturato annuo. Tassazione flat 15% (5% per i primi 5 anni di attività). Nessuna IVA. Contributi INPS gestione separata ~25-26%. Calcolo netto: per 60.000 euro fatturati, netto disponibile intorno ai 40.000 euro. Semplicità amministrativa molto elevata - contabilità ordinaria quasi nulla, nessuna gestione IVA, limitate scritture contabili obbligatorie.

Regime ordinario. Nessuna soglia di fatturato. Tassazione IRPEF progressiva. Gestione IVA (22% sulle prestazioni IT standard). Contributi INPS gestione separata ~25-26%. Deduzione dei costi (hardware, software, formazione, spese professionali) che riduce la base imponibile. Calcolo netto: per 120.000 euro fatturati, netto disponibile intorno ai 55-65.000 euro (dipende significativamente dai costi deducibili). Complessità amministrativa significativa - commercialista necessario, contabilità ordinaria o semplificata, dichiarazioni IVA trimestrali.

La scelta del regime non è banale. Il forfettario è ottimo fino a che il fatturato non supera 70-75.000 euro - sopra quella soglia, i costi deducibili del regime ordinario iniziano a compensare l'aliquota più alta. La pianificazione del passaggio fra regimi è complessa e va fatta con commercialista specializzato. I miei primi due anni sono stato in forfettario (fatturato sotto soglia), dal terzo anno al sesto in ordinario (per distacco rapido sopra soglia), dal settimo mi sono ristrutturato come SRL semplificata con stipendio da amministratore + dividendi (ottimizzazione fiscale più sofisticata per fatturati stabili sopra i 120-150k).

Il singolo suggerimento più importante su questo: trovare un commercialista che capisca il settore IT. Un commercialista generalista fa fatica a capire patterns specifici di servizi IT (progetti che attraversano anni fiscali, SaaS con revenue recurring, vendor estero con IVA inversa). Ho cambiato due commercialisti nei primi tre anni prima di trovarne uno che conoscesse il mercato. Il costo del commercialista giusto è 2.500-4.000 euro/anno, il risparmio fiscale che abilita è tipicamente 3-5x il suo costo.

Il cambio del rapporto con la tecnologia: da "dev puro" a "tecnico che parla business"

Un cambiamento che molti sottovalutano è la trasformazione del rapporto con la tecnologia stessa. Come dev dipendente, potevo permettermi di essere profondamente tecnico - conoscere le sfumature di un'API, padroneggiare i pattern di design avanzati, dedicare ore a capire un bug oscuro. Come consulente, la "profondità tecnica pura" è un asset ma non è il driver principale - il driver è la capacità di tradurre quella profondità in valore di business comprensibile dal cliente non tecnico.

Questo richiede sviluppare una seconda competenza: articolare la tecnologia in linguaggio business. Quando un cliente mi chiede "conviene passare a Laravel 11 o restare su 10?", la risposta dev-pura sarebbe una discussione di feature e breaking change. La risposta consulenziale include: rischio di essere su un framework fuori supporto entro 18 mesi, costo di migrazione stimato in giornate-uomo, impatto su pipeline CI/CD esistente, opportunità collegate (es: certi moduli nuovi disponibili solo su 11), trade-off con altre priorità che il budget deve servire. Stesso contenuto tecnico, ma strutturato per decisioni di investimento, non per curiosità tecnica.

Questo cambiamento ha due sotto-dimensioni. Prima: imparare la lingua del cliente. Un direttore operativo di una PMI manifatturiera non parla "controller, middleware, policy". Parla di "ordini, magazzino, fatture, clienti". La tua capacità di tradurre da una all'altra è la differenza fra essere il "tecnico che fa fatica a farsi capire" e il "consulente che aiuta a prendere decisioni". Seconda: imparare a NON parlare di tecnologia quando non serve. Il cliente che ti assume per aiutarlo a scegliere un gestionale non ha bisogno di sentire 10 minuti sulla differenza fra monolite e microservizi - ha bisogno di una raccomandazione attuabile con motivazione calibrata sul suo contesto.

Il rischio di isolamento tecnico: come mantenere aggiornamento senza il gruppo di colleghi

Un aspetto negativo del freelance che nessuno ti dice esplicitamente è l'isolamento tecnico. Da dipendente avevi colleghi con cui discutere, code review che ti esponevano a pattern diversi dai tuoi, sessioni di pair programming che forzavano apprendimento. Da freelance, spesso lavori da solo sul progetto del cliente - il cliente ha il suo team interno, ma tu sei "l'esterno" che interagisce ma raramente si integra davvero. Il rischio concreto è di smettere di imparare con la velocità che il mercato richiede, e di accorgersi dopo 3-4 anni di essere leggermente indietro rispetto allo stato dell'arte.

Le strategie che applico per contrastare questo. Prima: mantenere relazioni attive con colleghi. Gruppi Slack/Discord di community tecnica (es: italian-developers, PHP Italia, Laravel Italia), call periodiche con ex-colleghi, partecipazione a meetup e conferenze. Non come networking commerciale primario, ma come scambio tecnico genuino. Seconda: contribuire a progetti open source anche minoritariamente. Un paio d'ore al mese su qualcosa che uso quotidianamente (Laravel, Symfony, tool devops) mi tiene esposto a patterns di alta qualità e a review rigorose. Terza: scrivere regolarmente. Articoli, guide, approfondimenti - il processo di scrittura forza chiarezza mentale che amplifica l'apprendimento. Questo blog è effettivamente parte della mia pipeline di commerciale, ma è anche il mio principale strumento di sviluppo professionale continuo. Il pattern si integra con quello che descrivo nel mio articolo sulle sei abitudini di un senior developer che ne definiscono il valore oltre gli anni di esperienza puri - molte di quelle abitudini sono amplificate nel contesto freelance.

I tipi di cliente da evitare (e come riconoscerli al primo contatto)

Dopo 11 anni e qualche centinaio di clienti, ho sviluppato un "radar" per riconoscere i clienti che si trasformeranno in perdite di tempo ed eventualmente di denaro. Cinque red flag tipici.

Red flag 1 - "quanto costa?" come prima domanda. Un prospect che apre il primo contatto con "quanto costa farmi un gestionale?" senza prima spiegare il proprio business, le proprie esigenze, il proprio contesto, tipicamente cerca il fornitore più economico. Questa categoria di clienti non è mai soddisfatta (pagano poco ma pretendono molto), cambia fornitore spesso, e tende a contestare le fatture per giustificare ribassi.

Red flag 2 - riferimenti negativi ai fornitori precedenti. "Il fornitore precedente era incompetente/ladro/incapace" detto al primo incontro è quasi sempre un segnale che presto tu sarai l'incompetente/ladro/incapace. I clienti emotivamente instabili nei rapporti con fornitori mantengono quel pattern nel tempo.

Red flag 3 - urgenza non motivata. "Devo avere questo pronto per domani/la prossima settimana" per progetti che non hanno avuto pressione del cliente per mesi, di solito significa cattiva pianificazione che verrà scaricata sul fornitore come richiesta di straordinari non retribuiti.

Red flag 4 - richiesta di lavoro senza contratto "perché ci fidiamo". Come descritto sopra, nessun lavoro senza contratto. La pressione a saltare questo passo è quasi sempre segnale di un cliente che non vuole essere legato a obblighi reciproci.

Red flag 5 - pagamento a risultato completo senza acconto. "Ti pago quando funziona tutto" su progetti complessi è una trappola classica. L'interpretazione di "funziona tutto" diventa oggetto di disputa infinita, e il fornitore si trova a lavorare senza essere pagato per mesi aspettando approvazione del cliente.

Il mio pattern attuale è di rifiutare rispettosamente clienti che manifestano 2 o più di questi red flag al primo contatto. Dire no è un atto di protezione del business, non di arroganza. L'energia e il tempo che avrei speso su un cliente problematico sono meglio spesi cercando clienti con profilo positivo.

I tipi di cliente che producono valore reciproco

Dall'altra parte, i clienti che nei miei 11 anni hanno prodotto i risultati più positivi hanno cinque caratteristiche ricorrenti.

Prima - chiarezza sul problema che vogliono risolvere. Il cliente sa cosa vuole ottenere (anche se non sa come), e riesce ad articolarlo in termini di business outcome. "Vogliamo ridurre del 30% il tempo di chiusura commessa dal preventivo alla fatturazione" è un obiettivo misurabile che inquadra tutto il progetto.

Seconda - rispetto per il tempo del consulente. I clienti buoni non ti chiamano alle 23 per cose non urgenti, non ti scrivono 15 email al giorno con micro-domande, rispettano il tuo calendario quando chiedi finestre di disponibilità. Questo pattern si riconosce nei primi contatti e si conferma nel tempo.

Terza - trasparenza sui vincoli. Un buon cliente ti dice "ho 30.000 euro di budget per questo progetto e 3 mesi di tempo", non "quanto costa?". Vincoli espliciti permettono di strutturare una soluzione ottimale per quei vincoli, invece di iniziare guess game infiniti sui margini di spesa reali.

Quarta - accettazione dei trade-off. Nel software non esiste "tutto al massimo" - ogni scelta ha costi. Un cliente maturo accetta che aumentare la velocità riduce la qualità, che aumentare lo scope riduce la copertura test, che scegliere economicità riduce la flessibilità futura. Clienti che rifiutano i trade-off sono clienti destinati a frustrare il consulente e se stessi.

Quinta - disposizione a pagare il valore quando lo ricevono. Quando il lavoro produce valore concreto e misurabile (performance migliorata, incidenti evitati, contratti vinti grazie alla nostra compliance), i clienti buoni riconoscono quel valore anche se l'investimento iniziale sembrava alto. I clienti cattivi, anche di fronte a valore evidente, contestano l'inveterato "ma forse costava meno da qualcun altro".

Con i clienti che hanno queste caratteristiche, i rapporti tendono a durare anni - alcuni miei clienti lo sono da 6-8 anni con retainer mensile continuativo. Questi rapporti lunghi sono l'equivalente economico di un contratto di lavoro dipendente con ancora più sicurezza (se un cliente se ne va, ho 5-8 altri attivi), con più autonomia operativa, con evoluzione professionale più ricca.

Le metriche di salute economica del freelance

Sul lato finanziario, dopo 11 anni posso condividere le metriche che monitoro per capire se l'attività è in salute. Sei metriche principali, revisionate mensilmente.

Metrica 1 - fatturato rolling 12 mesi. Non il singolo mese (troppo volatile), il totale su 12 mesi sliding. Il trend deve essere stabile o in crescita; discese prolungate indicano necessità di intervento commerciale.

Metrica 2 - concentrazione clienti. Il top cliente rappresenta che percentuale del fatturato annuo? Se >40%, rischio eccessivo di dipendenza - un singolo cliente che se ne va può distruggere il business. Target personale: top cliente <25%.

Metrica 3 - tasso di utilizzazione. Delle ore lavorate in un mese, quante sono fatturabili? Il mio target è 55-65%. Sopra 70% rischio burnout (nessun tempo per commerciale, formazione, pianificazione strategica). Sotto 45% rischio di spreco (troppo tempo su attività non fatturabili).

Metrica 4 - margine operativo. Fatturato - costi diretti (commercialista, software, hardware, formazione) - contributi previdenziali = margine operativo. Questo è il "vero" compenso disponibile. Se il margine scende come percentuale del fatturato, i costi stanno crescendo più del giro d'affari.

Metrica 5 - days sales outstanding. Giorni medi fra fattura emessa e pagamento ricevuto. Target: <45 giorni. Oltre 60 indica un problema di cliente o di gestione del credito.

Metrica 6 - pipeline commerciale. Quante opportunità attive ho in pipeline, con valore stimato? Questa metrica guarda al futuro invece che al passato. Un pipeline che si riduce è early warning di crisi futura.

Senza monitorare queste metriche sistematicamente, è facile ingannarsi - un singolo mese straordinario copre problemi strutturali, un singolo mese deludente genera panico ingiustificato. La disciplina di guardare le medie rolling e i trend è la stessa disciplina che applico ai miei clienti quando parliamo di allocazione strategica del budget IT per PMI nel 2025 - la mia attività è una PMI come loro, e si gestisce con gli stessi principi.

Il pattern di evoluzione: come l'attività cambia nel tempo

Un'osservazione che ho fatto guardando indietro: l'attività di consulente evolve significativamente nel tempo, in modo non sempre prevedibile. Nei primi anni sono stato prevalentemente developer-for-hire - codice contro pagamento, progetti brevi, molti clienti diversi. Negli anni intermedi mi sono specializzato in modernizzazione di codebase legacy - meno clienti, progetti più lunghi, relazioni più profonde. Negli ultimi anni la specializzazione si è ampliata verso infrastructure, security, AI automation - tre mondi che si integrano nel "tecnico senior che aiuta PMI a modernizzarsi".

Questa evoluzione non è stata pianificata anno per anno - è emersa dall'osservazione di cosa i clienti chiedevano, quali progetti producevano più valore (per loro e per me), quali aree mi davano energia invece di drenarla. L'analogia è con un prodotto che si adatta al mercato - il "product-market fit" applicato alla propria offerta consulenziale. Un freelance che mantiene la stessa offerta identica per 10 anni o è fortunato ad aver azzeccato il sweet spot di mercato dall'inizio, o sta perdendo opportunità di evoluzione.

Il pattern pratico che raccomando è una revisione strategica annuale - tipicamente a gennaio mi fermo per un weekend, guardo indietro l'anno appena chiuso, rifletto su quali progetti sono stati più redditizi (non solo in euro, ma in valore complessivo), identifico tendenze emergenti nelle richieste dei clienti, e pianifico evoluzioni dell'offerta per l'anno successivo. Questa disciplina prevenie la stagnazione che vedo in colleghi che arrivano a anno 7 o 8 di freelance e scoprono di essere "fermi" a competenze che il mercato non paga più al loro prezzo.

Il bilancio dopo 11 anni: quello che vale, quello che costa

Onesta valutazione dopo 11 anni: il freelance è stata la scelta giusta per me, ma non posso dire in assoluto che sia la scelta giusta per tutti i developer senior. Il cosa vale: autonomia operativa completa (decido quali progetti fare, con chi, come), diversità di esperienza molto maggiore rispetto al dipendente (vedo 15-20 aziende diverse all'anno, non una sola), crescita economica meno capped (stipendio dipendente ha tetto strutturale, fatturato freelance non lo ha), capacità di costruire un corpus professionale (blog, articoli, reputazione) che cumula valore nel tempo.

Il cosa costa: tempo commerciale continuo (anche quando sono pieno di lavoro), stress del buco di fatturato possibile, assenza di benefit strutturali (malattia, maternità/paternità, assicurazione infortuni - tutte a tuo carico), isolamento professionale che va combattuto attivamente, carico cognitivo amministrativo significativo anche con commercialista, rischio di burnout perché non c'è un datore di lavoro che ti ferma. Il bilancio è netto positivo per me, ma richiede onestà nel considerarlo prima del salto.

Per chi sta valutando il passaggio, il consiglio che do è pragmatico: non fare il salto nel bel mezzo di un periodo di stabilità professionale. Il momento giusto è quando hai una motivazione strutturale (insoddisfazione per il tipo di lavoro, plateau di crescita stipendiale, opportunità specifica di cliente iniziale già in vista), un cuscinetto finanziario di 6-9 mesi di costi personali, una rete di contatti professionali che può generare primi clienti, e disposizione a dedicare 2-3 anni a costruire le competenze non-tecniche (commerciale, amministrazione, relazione clienti) che nessuno ti insegna come dev dipendente.

Se stai pensando al passaggio da dev dipendente a freelance consulente IT e vuoi un confronto pragmatico sulle scelte specifiche (pricing sul tuo livello di competenza, tipologia di clienti target, strutturazione commerciale), contattami per una chiacchierata informale. Non è il mio business principale fare career coaching ma occasionalmente faccio sessioni 1:1 con colleghi che stanno pensando al salto - 2 ore di conversazione strutturata dove condivido pattern concreti e rispondo a domande specifiche sul tuo caso. Non posso dirti se fare il salto è la scelta giusta per te (dipende da troppi fattori personali), ma posso darti una mappa più accurata del territorio prima che tu decida.