Quanto ti fa guadagnare davvero uno sviluppatore: la verità sul margine dell'outstaff
«Ero convinto di fare il 40% su ogni sviluppatore. La prima volta che l'abbiamo scomposto persona per persona è venuto fuori l'11%. La differenza era il tempo di panchina, che semplicemente non avevo mai considerato un costo.»
Sono le parole del titolare di uno studio di outstaff con 14 ingegneri. La storia è familiare a quasi chiunque affitti un team a ore: la tariffa del cliente meno lo stipendio dello sviluppatore sembra profitto. In realtà metà dell'azienda si nasconde tra questi due numeri e, finché non ripartisci i costi persona per persona, gestisci il fatturato, non il margine.
Perché «tariffa meno stipendio» mente
Prendi un tipico ingegnere mid-level. Fatturi al cliente 35 $ l'ora; lo sviluppatore ti costa circa 3.000 $ al mese al netto delle tasse. Nella testa del titolare sono 35 $ contro circa 20 $, un margine vicino al 43%. Sembra ottimo, ed è proprio su questo numero che ci si appoggia quando si decide di assumere di più, concedere uno sconto o alzare uno stipendio.
Il problema è che uno sviluppatore non consegna 160 ore fatturabili al mese. Tra un progetto e l'altro sta in panchina. L'onboarding di un nuovo cliente si mangia una settimana mentre la persona entra nel codice e nei processi altrui. Aggiungi riunioni, code review, formazione, giorni di malattia, festività. L'utilizzo reale (la quota di ore che il cliente paga davvero) anche negli studi sani supera di rado il 75%. E ogni punto percentuale non fatturabile lo finanzi di tasca tua.
La scomposizione per una persona
Contiamo onestamente, con gli stessi numeri.
| Voce | Importo / mese |
|---|---|
| Tariffa cliente | 35 $ / h |
| Ore fatturabili (utilizzo 75%) | 120 h |
| Fatturato dallo sviluppatore | 4.200 $ |
| Stipendio + tasse | −3.000 $ |
| Contributo diretto | 1.200 $ |
| Quota costi generali (ufficio, PM, recruiting, amministrazione) | −700 $ |
| Profitto reale | 500 $ (12%) |
Il 43% sulla carta è diventato 12% nella realtà. Ed è ancora lo scenario buono. Fai scendere l'utilizzo al 60% per un mese vuoto e lo stesso sviluppatore va in negativo, anche se lo stipendio lo paghi comunque.
Contiamo su un anno intero
Il dato mensile è ingannevole perché la panchina è irregolare. Prendi lo stesso ingegnere mid-level su un anno. Per dieci mesi va all'80%, un mese al 40% (un progetto è finito, il successivo non era ancora partito), e in tutto una settimana se ne va tra malattia e formazione. Nell'anno il cliente ha pagato circa 1.250 ore invece delle 1.920 teoriche. Fatturato: circa 43.750 $. Stipendio con tasse: 36.000 $. Costi generali per persona: 8.400 $. Profitto annuo dallo sviluppatore: circa −650 $. Lo stesso ingegnere che «dà il 43% di margine» ha chiuso l'anno leggermente in negativo, tutto per un mese vuoto e qualche settimana non fatturabile spalmata sull'anno.
«La panchina non compare su nessuna fattura, quindi nessuno la vede. E si mangia più di qualunque sconto a un cliente.»
Tre costi che tutti sottovalutano
Primo, la panchina. Il tempo tra un progetto e l'altro lo paghi tu, non il cliente. Una settimana vuota al mese è meno 25% di fatturato per persona a parità di stipendio. In uno studio di 14 persone anche un 10% di panchina media è come tenere una persona e mezza che non porta niente.
Secondo, le ore non fatturabili dentro un progetto. Daily standup, allineamenti col cliente, review, ricerca, rilavorazioni dopo i cambi di requisiti. Il cliente paga 6 ore mentre ne sono occupate 8. Quelle due ore al giorno sono anch'esse un tuo costo, solo invisibile.
Terzo, i costi di gestione. Ogni cinque o sei ingegneri servono un project manager, e reclutare o sostituire una persona costa circa un mese del suo stipendio, più i mesi finché il nuovo arrivato raggiunge la piena velocità. Quei soldi non sono legati a nessuna singola fattura, ed è per questo che è facile perderli di vista, finché non conti il profitto per persona al netto dei costi generali.
Come si presenta nella vita reale
Il problema lo senti nelle frasi tipiche dentro lo studio. «Abbiamo tanti progetti ma poco profitto.» «Siamo cresciuti a 20 persone, ma il titolare guadagna come se fossero 12.» «Un cliente è saltato, ce la caviamo, mettiamo la persona su un progetto interno» (cioè in piena panchina a tue spese). «Diamo il 10% di sconto a questo cliente, è grande», mentre il margine su quell'account era già al 12% e lo sconto lo rende in perdita.
Sono tutti sintomi di una cosa sola: lo studio conta la differenza tariffa-meno-stipendio e non conta mai il profitto per persona al netto di panchina e costi generali. Il fatturato è grande, e il titolare si chiede dove finisca il profitto.
Come vedere il margine su ogni sviluppatore
Per gestire tutto questo devi vedere fatturato e costi per persona o per progetto, non in un unico calderone. In Finmap imposti progetti e direzioni, registri il fatturato del cliente e il costo diretto della persona che svolge il lavoro, e vedi il margine lordo per ingegnere e per lo studio nel complesso. La panchina smette di essere invisibile: un mese vuoto compare subito nel report, non sei mesi dopo come un vago «il profitto è calato chissà perché». Vedi anche quale cliente porta un margine normale e quale si limita a caricare le persone quasi gratis.
Correlati: in cosa si distingue la contabilità gestionale da quella civilistica in un'azienda IT e come misurare l'utilizzo del team.
Cosa fare al riguardo
- Fissa un utilizzo obiettivo e monitoralo ogni settimana, non una volta a trimestre. Una settimana vuota intercettata in tempo si può ancora chiudere con una vendita.
- Metti la panchina nel prezzo: la tariffa deve coprire non solo le ore occupate ma anche quelle inevitabilmente vuote. Se l'utilizzo obiettivo è il 75%, la tariffa si costruisce su quello, non sul 100%.
- Misura il profitto per persona al netto dei costi generali, non la differenza lorda tariffa-meno-stipendio. Solo il primo numero dice la verità.
- Guarda il margine per cliente: un cliente grande con uno sconto spesso porta meno di uno piccolo a tariffa piena.
- Pianifica sostituzioni e assunzioni sulla base del carico, non «per ogni evenienza». Ogni persona «per la crescita» senza un progetto è pura panchina a tue spese.
L'outstaff sembra un business semplice finché non inizi a contare persona per persona. Quando lo fai, diventa chiaro chi guadagna davvero, chi sta in panchina e dove il margine si disperde tra le ore non fatturabili. E allora le decisioni su assunzioni, sconti o un nuovo progetto si prendono sui numeri, non sulla sensazione che «ci sono tante persone, quindi le cose devono andare bene».
I soldi non spariscono. Semplicemente non li vedi.
Prova Finmap gratis per 14 giorni e vedi già questo mese il margine su ogni sviluppatore e progetto, senza incollare fogli di calcolo a mano.
Domande frequenti
Un riferimento sano è il 75–85% di ore fatturabili. Sopra il 90% di solito significa burnout e zero tempo per crescere; sotto il 70% significa che la panchina ti sta mangiando il margine. Il punto è misurarlo con regolarità, non stimarlo a occhio.
Sì. Se la tariffa copre solo le ore occupate, finanzi ogni settimana vuota con il profitto. Inserisci un utilizzo obiettivo nel prezzo, così la tariffa regge i normali vuoti tra un progetto e l'altro.
Il modo più semplice è in proporzione alle ore fatturabili o al fatturato di ciascuno. L'importante è farlo allo stesso modo ogni mese, così il profitto per persona resta confrontabile nel tempo.
I clienti grandi chiedono quasi sempre uno sconto sul volume, e spesso tieni delle persone «in riserva» per far crescere in fretta il team dedicato a loro. Lo sconto più quella panchina dedicata trasformano facilmente un account apparentemente attraente nel più magro per margine.
No, se è una panchina occasionale tra due progetti. L'allarme scatta quando il segno meno resta per due o tre mesi di fila: allora o la tariffa è troppo bassa o la persona non è caricata, e questo è un problema strutturale.
