Perché abbiamo smesso di fatturare a ore per lo sviluppo software

Risposta rapida

• Generare è diventato più economico. La proprietà no.
• La fatturazione oraria ora calcola il prezzo della parte più veloce del lavoro.
• Il costo è soggetto a revisione, test e agli anni successivi.
• Una promessa di sostegno non finanziata non è una promessa.
• Ora valutiamo la responsabilità, non il tempo impiegato.

Il 3 settembre OpenAI ha rilasciato GPT-6 Astra. Il lancio è ancora in fase graduale, quindi la maggior parte delle persone non l'ha ancora utilizzato. Questo è più o meno il ritmo attuale. Ogni pochi mesi il livello di difficoltà si alza, e ciò che a marzo era difficile, a settembre diventa normale.

Ho smesso di trovarlo sorprendente. Ciò a cui non ho smesso di pensare è una questione più piccola, che si faceva più difficile ogni volta che il soffitto si muoveva.

Se la macchina può svolgere una parte maggiore del lavoro di costruzione, per cosa esattamente sto addebitando il costo?

Perché l'ora ha smesso di misurare qualsiasi cosa?

Qualche mese fa mi sono dedicato a un compito che ha richiesto circa un'ora per essere completato, decidendo cosa inserire nella fattura.

Un'ora era un tempo preciso. Ma anche pressoché insignificante. Quell'ora copriva la parte più veloce, economica e meno rischiosa di ciò che avevamo concordato di fare. Tutto ciò che contava si trovava dall'altra parte: leggere correttamente l'output, testare i percorsi che nessuno aveva richiesto, implementarlo in sicurezza ed essere reperibili per i successivi tre anni nel caso in cui qualcosa al suo interno si fosse spostato.

Fatturare a ore significava addebitare di più per la parte che era diventata quasi gratuita e di meno per la parte che comportava tutto il rischio. Significava anche che venivamo premiati per la lentezza. Non potevo giustificarlo a un cliente, né a me stesso.

Perché la responsabilità è ciò che viene prezzato?

Abbiamo già scritto a lungo su cosa succede dopo che un'applicazione con codice Vibe raggiunge utenti reali , inclusi casi documentati in cui il problema non era lo strumento, ma la persona responsabile del prodotto rilasciato. Non ripeterò qui questa argomentazione.

Ciò a cui quell'articolo non ha risposto è la questione commerciale che si cela dietro. Se la trasparenza è ciò che scarseggia, deve pur comparire da qualche parte in fattura. Altrimenti è una promessa che nessuno ha finanziato, e le promesse non finanziate tendono a indebolirsi silenziosamente proprio nel momento in cui sarebbero più necessarie.

Una tariffa oraria non può offrire questa garanzia. Registra per quanto tempo qualcuno ha dedicato tempo a risolvere un problema, il che nel 2026 dice ben poco su quanto rischio si è assunto per vostro conto.

Cosa stanno acquistando concretamente i clienti adesso?

Le competenze si sono diffuse. Ormai tutte le aziende di Bangalore, Calicut e Chicago utilizzano più o meno gli stessi strumenti. Nel 2026 nessuno vincerà una gara d'appalto affermando di essere un ingegnere più veloce.

Ciò che non è stato diffuso è la promessa. Qualcuno deve dire: questo è nostro, lo manterremo attivo, ed ecco chi se ne occuperà. Non si tratta di un'affermazione tecnica. È un impegno, e gli impegni costano, a differenza di quanto accade oggi con le semplici digitazioni.

Noto anche io questa spaccatura nelle conversazioni. Alcune persone con cui parlo sono entusiaste di quanto tutto sia diventato più veloce. Altre, di solito quelle che utilizzano software da qualche anno, pongono domande più pacate. Chi ha revisionato questo? Cosa succede quando si rompe? Chi rimane quando la persona che lo ha progettato se ne va?

Entrambe le reazioni sono plausibili. La differenza sta solo nell'orizzonte temporale.

Che cosa abbiamo cambiato concretamente?

Siamo passati dalla fatturazione oraria alla determinazione del prezzo in base al compito svolto e alla responsabilità ad esso connessa.

Quel cambiamento non è stato facile. Spiegare che un'attività di un'ora ha un prezzo non legato all'ora stessa richiede una conversazione più lunga rispetto all'invio di una fattura. Alcune di queste conversazioni sono andate male prima di migliorare. Alcuni clienti preferivano il vecchio modello e capivo il perché.

Ciò che ha reso la proposta difendibile è stata la specificità di cosa copre il prezzo. Non l'impegno profuso, ma la copertura. Chi revisiona il codice prima dell'integrazione, chi è coinvolto nel progetto, cosa succede il sabato sera, per quanto tempo restiamo responsabili dopo la consegna.

Non sai quanto ti costerà il software dopo il primo anno?

Inviami il repository e la data di messa online. Ti dirò cosa penso che serva e se siamo le persone giuste per occuparcene. In caso contrario, te lo dirò.

Come si fa a stabilire il prezzo di qualcosa che non si può programmare?

Questa è la difficoltà pratica, ed è il motivo per cui la tariffazione oraria non funziona nemmeno sul fronte dell'assistenza.

Il lavoro necessario per mantenere in vita un software non è programmato. Arriva quando lo decide una piattaforma, quando lo decide un ente regolatore, o quando qualcuno scopre una vulnerabilità in una libreria che hai adottato due anni fa. Non puoi prevederlo in anticipo perché non dipende da te programmarlo.

Un breve elenco di cose che nessuno pianifica:

• Deriva delle dipendenze e dell'SDK, comprese le deprecazioni che nessuno ha scelto
• Modifiche ai requisiti di piattaforma da Google Play Console e App Store
• Movimento normativo, che in India significa le regole di tokenizzazione della RBI e l'arrivo del DPDP Act con scadenze allegate
• Revisione della sicurezza del codice generato in particolare, poiché i modelli sono ottimizzati per funzionare piuttosto che per convalidare l'input
• Ragionamento scritto, in modo che il prossimo ingegnere erediti il ​​contesto invece dell'archeologia
• Una persona nominata che raccoglie

Non è possibile quantificare il numero di ore in base a quell'elenco. Ciò che si può quantificare è la copertura: la garanzia che, quando si verifica un sinistro, qualcuno sia già responsabile e già pagato per occuparsene.

Quale modello di prezzo è effettivamente adatto al momento?

Questa domanda mi viene posta da fondatori che non cercano tanto di risparmiare quanto di capire cosa stanno acquistando. Merita una risposta diretta, che includa anche i casi in cui il nostro modello non è adatto.

Modello	Dove funziona ancora	Dove si romperà nel 2026
Orario	Scoperta, attività di consulenza, ambito ancora da definire	Qualsiasi cosa assistita dall'intelligenza artificiale. La velocità riduce il costo della fattura mentre il rischio rimane costante.
Prezzo fisso per progetto	Ambito ristretto, consegna unica, nessuna modifica prevista	La proprietà termina al momento del passaggio di consegne, quindi nessuno ha finanziato il quattordicesimo mese.
Compito più periodo di proprietà stabilito	Risultati definiti per i quali qualcuno rimane responsabile in seguito	Richiede una conversazione onesta sull'ambito del progetto, che il cliente potrebbe non volere fin dal primo giorno.
Compenso continuativo	Sistemi in funzione, settori regolamentati, qualsiasi cosa integrata con altri software	Sembra costoso fino alla settimana in cui non lo è

Utilizziamo la terza e la quarta opzione. Non perché siano particolarmente intelligenti, ma perché sono le uniche due in cui il nostro incentivo e quello del cliente coincidono. Con la tariffa oraria, guadagniamo di più andando più piano. Con il prezzo fisso, guadagniamo di più sparindo al momento della consegna. Nessuno dei due è un tipo di rapporto che vorrei mantenere per tre anni.

La trappola del prezzo fisso merita un nome, perché è quella in cui gli acquirenti cadono più spesso. Un preventivo fisso dà un senso di sicurezza. Fissa un limite massimo alla cifra indicata sulla pagina. Ciò che di solito non specifica è cosa succederà all'ottavo mese, il che significa che la risposta arriverà in seguito, in una trattativa separata, in un momento in cui non si ha più alcun potere contrattuale e il sistema è inefficiente.

Cosa abbiamo sbagliato nel primo anno

Preferisco metterlo per iscritto piuttosto che far sì che qualcuno lo scopra durante una riunione.

La prima versione del nostro listino prezzi era troppo vaga. Abbiamo indicato il costo del servizio e specificato che l'assistenza era inclusa, senza però indicare per quanto tempo o cosa fosse effettivamente coperto. Questo non è un modello di business. È una speranza, e si è infranta la prima volta che io e un cliente non siamo stati d'accordo sul fatto che qualcosa dovesse essere considerato una correzione o una nuova funzionalità. Avevamo entrambi ragione, perché nulla era stato messo per iscritto.

Il secondo errore è stato spiegare male il cambiamento. Ho presentato le nostre motivazioni anziché ciò che il cliente riceverà effettivamente. Nessuno si fida della logica interna. Ciò che interessa è un impegno di risposta definito, un tecnico dedicato e una chiara definizione di ciò che è incluso.

Il terzo errore è stato sottovalutare quanto sarebbe stata imbarazzante la conversazione. Alcuni clienti hanno capito "stiamo addebitando di più per meno lavoro", che è un'interpretazione plausibile di una fattura spiegata male. Quella è stata colpa mia, non loro.

La soluzione è stata mettere per iscritto i confini. Quali opere sono coperte, quali sono citate separatamente, per quanto tempo ne siamo responsabili e chi contattare. Una volta che questi confini sono stati messi nero su bianco, le obiezioni sono in gran parte cessate, perché la discussione non aveva mai riguardato realmente il prezzo.

Perché abbiamo smesso di inseguire le build delle app

Ecco a cosa mi ha portato il ragionamento, anche se ci ho messo più tempo ad arrivarci che a scriverlo.

Se chiunque può creare un'applicazione, allora lo sviluppo di applicazioni non è un'attività che vale la pena difendere. Ciò che vale la pena difendere è il software su cui un'azienda si basa effettivamente. Sistemi che si connettono tra loro, trasferiscono dati tra i reparti, superano i controlli e continuano a funzionare negli anni anche quando nessuno li controlla.

Questo ha cambiato il nostro modo di pensare al nostro lavoro. Non ci siamo più concentrati solo sulla pubblicazione di un'altra app, ma abbiamo iniziato a considerare il software come parte integrante del funzionamento di un'azienda : flussi di lavoro, integrazioni, dashboard, l'infrastruttura operativa, spesso poco appariscente ma fondamentale per il buon andamento del sistema.

Internamente, definiamo questa direzione come ecosistemi di software operativo basati sull'intelligenza artificiale per i mercati emergenti. Questa espressione è nata dopo la decisione, non prima. La cosa che è venuta prima è stata la constatazione che il nostro lavoro più prezioso non era mai il codice che scrivevamo più velocemente.

Che domande dovresti porre a un partner di sviluppo?

Che lavoriate o meno con noi, queste domande meritano di essere poste a chiunque quest'anno.

1. Quanta parte di questo sarà generata dall'IA e chi la esaminerà prima dell'integrazione?
2. Il vostro team è in grado di spiegare il risultato senza aprire lo strumento?
3. Chi è il responsabile tecnico designato del mio progetto?
4. Chi interviene in caso di guasto al di fuori dell'orario di lavoro e con quale rapidità?
5. Dove si trova il repository se smettiamo di collaborare?
6. Come gestite i segreti e chi ha accesso ad essi?
7. Qual è la vostra cadenza di applicazione delle patch per le dipendenze?
8. Hai già superato una verifica di sicurezza da parte di un cliente?

Un partner che risponde a tutte e otto le domande senza imbarazzo ti sta dicendo qualcosa che nessuna proposta di matrimonio può darti.

Errori comuni commessi dagli acquirenti nel 2026

Cinque modelli e il relativo costo effettivo.

L'errore	Perché ti costa?
Confronto delle tariffe orarie	Oggi, il tasso più basso spesso indica il codice più generato e meno revisionato. Stai ottimizzando il parametro sbagliato.
Presupponendo che generato significhi rivisto	Due attività diverse, svolte da persone diverse. Solo una di esse è veloce.
Accettare una coda di ticket come responsabilità	Una coda distribuisce l'assenza di proprietà anziché fornirla.
Considerare il supporto come la fase successiva al lavoro vero e proprio.	L'assistenza clienti è la fase in cui un software o guadagna denaro o smette silenziosamente di funzionare.
Lasciando il passaggio di consegne alla fine	Informatevi sulla proprietà del repository e sul trasferimento delle credenziali al momento della firma del contratto, non al momento della separazione.

Qual è dunque la risposta sincera?

Se una macchina è in grado di costruire di più, la responsabilità assume maggiore importanza, non minore. La capacità senza responsabilità è solo un modo più rapido per creare qualcosa di cui nessuno può rispondere.

Preferirei essere l'azienda che qualcuno chiama alle undici di sera piuttosto che quella con la flotta di strumenti più imponente. Gli strumenti sono ormai gli stessi ovunque. La persona che risponde al telefono, invece, non lo è, ed è proprio per questo che vale la pena pagare.

FAQ

Chi è legalmente responsabile di un bug nel codice generato dall'IA?

La responsabilità ricade su chi ha stipulato il contratto per la fornitura e la manutenzione del software, non sullo strumento che lo ha prodotto. I fornitori di IA escludono comunemente l'output generato dalla garanzia. Verifica il tuo contratto di sviluppo per stabilire chi è responsabile dei difetti e per quanto tempo dopo la consegna.

Il software dovrebbe ancora essere tariffato a ore?

La tariffazione oraria aveva senso quando tempo e risultati erano strettamente correlati. Con l'ausilio dell'intelligenza artificiale, la generazione è rapida, mentre la revisione, il collaudo e l'assistenza a lungo termine non lo sono. La tariffazione oraria ora fa pagare di più per la parte meno costosa del lavoro e meno per il rischio.

È meglio optare per uno sviluppo a prezzo fisso piuttosto che a tariffa oraria?

Il prezzo fisso risolve il problema sbagliato. Limita la somma da pagare per la consegna, ma lascia la proprietà senza copertura assicurativa fin dal primo giorno. La questione utile non è il prezzo fisso rispetto al prezzo orario, ma se l'accordo stabilisce chi è responsabile dopo la consegna e per quanto tempo.

L'utilizzo dell'intelligenza artificiale rende lo sviluppo più economico per i clienti?

A volte, per la fase di sviluppo. Raramente per il costo totale di proprietà. I ​​risparmi si manifestano in fase di generazione e scompaiono durante le fasi di revisione, sicurezza e manutenzione. Chiedete al fornitore cosa include il prezzo dopo la consegna, non solo cosa include prima.

Come posso valutare un'azienda di sviluppo che utilizza l'intelligenza artificiale?

Chiedi quanta parte del tuo codice sorgente verrà generata, chi la revisiona prima dell'unione e se i loro ingegneri sono in grado di spiegare il risultato senza l'ausilio dello strumento. Chiedi poi chi è coinvolto nel tuo progetto e qual è l'impegno di risposta in caso di problemi.

Perché le app smettono di funzionare anche quando nessuno ha modificato il codice?

L'ambiente sottostante cambia continuamente. Rilasci di sistemi operativi, deprecazione di SDK, certificati scaduti, modifiche ai prezzi delle API e migrazioni dei gateway di pagamento: tutto ciò può compromettere il funzionamento del software. Il codice, invece, rimane immobile mentre tutto il resto si evolve.