Il tuo team ML ha appena speso cinque mesi-uomo di ingegneria per mettere in piedi un feature store open source. Il tuo controller guarda il costo del personale e pone una domanda che nessuno nel team si aspettava: quei $180.000 di tempo ingegneristico sono un costo che impatta questo trimestre, o un'attività che resta in bilancio? La risposta modifica il tuo burn multiple, i calcoli sulla runway e — se stai raccogliendo capitali — la storia che i tuoi bilanci raccontano. E cambia completamente a seconda che tu abbia costruito su Feast o acquistato Tecton.
Un feature store è lo strato infrastrutturale che gestisce, archivia e serve le feature di machine learning sia per l'addestramento sia per l'inferenza in tempo reale. Il suo compito principale è prevenire il training-serving skew: assicurarsi che il modello veda in produzione esattamente le stesse feature su cui è stato addestrato. L'architettura ha cinque componenti mobili — un offline store per i dati di addestramento, un online store per il serving a bassa latenza, pipeline di feature che calcolano i valori, un registro centrale delle feature e API di serving. Quando i team scelgono tra Feast e Tecton, stanno scegliendo tra due modelli di proprietà molto diversi, e ciascun modello produce un trattamento contabile molto diverso.
Feast vs. Tecton: il compromesso build-vs-buy
Feast è il principale feature store open source: gratuito da usare, self-hosted e flessibile. Gestisci tu stesso l'online store (tipicamente Redis o DynamoDB), l'offline store (S3, BigQuery o Snowflake), e possiedi ogni upgrade, ogni pagina di allarme e ogni decisione di scalabilità. Tecton è l'alternativa commerciale completamente gestita, costruita da membri del team dietro la piattaforma Michelangelo di Uber. Gestisce il serving online e offline, il calcolo delle feature in streaming e il monitoraggio delle feature integrato, dietro un contratto SaaS enterprise.
Il confronto standard è questo:
| Fattore | Feast | Tecton |
|---|---|---|
| Costo di licenza | Gratuito (solo costi infrastrutturali) | Prezzo SaaS enterprise |
| Serving online | Redis, DynamoDB — li gestisci tu | Completamente gestito |
| Offline store | Parquet, BigQuery, Snowflake — lo configuri tu | Gestito |
| Feature in streaming | Basate su push, costruisci tu le pipeline | Calcolo nativo in tempo reale |
| Monitoraggio delle feature | Tooling esterno che assembli tu | Integrato |
| Carico operativo | Alto — il tuo team gestisce tutto | Basso — SLA del fornitore |
La versione contabile di questa tabella ha una riga in più: dove compaiono i soldi. Con Tecton, quasi tutto il costo arriva come fattura del fornitore — una spesa per abbonamento. Con Feast, la voce di licenza è zero e il costo reale si nasconde nel costo del personale ingegneristico: le settimane che i tuoi data engineer passano a distribuire il registro, scrivere pipeline di feature, ottimizzare l'online store e costruire il monitoraggio che Feast non fornisce. L'infrastruttura open source a "costo di licenza zero" richiede comunque una voce di conto economico per le ore di ingegneria, e quella voce è esattamente ciò che disciplina l'ASC 350-40.
La questione contabile: cosa dice davvero l'ASC 350-40
Secondo i principi contabili statunitensi (U.S. GAAP), i costi del software a uso interno ricadono nell'ASC 350-40, che classifica ogni dollaro di un progetto software in una delle tre fasi (vedi la nostra guida pratica alla decisione capitalizzare-vs-spesare per il quadro generale):
- Fase preliminare del progetto — spesare quando sostenuto. Valutare i fornitori, eseguire spike di proof-of-concept, confrontare Feast con Tecton, studi di fattibilità e l'analisi build-vs-buy stessa. Tutto impatta immediatamente il conto economico.
- Fase di sviluppo dell'applicazione — capitalizzare i costi ammissibili. Una volta che il management ha autorizzato e si è impegnato sul progetto, i costi di progettazione, codifica, configurazione, test e integrazione del software vengono capitalizzati come attività e ammortizzati lungo la loro vita utile. Questa è l'unica fase che costruisce un'attività.
- Fase post-implementazione e operativa — spesare quando sostenuto. Formazione, manutenzione, correzione di bug e operazioni continuative dopo il go-live. Nuove funzionalità aggiunte in seguito possono far ripartire la capitalizzazione, ma mantenere in funzione il sistema mai.
Per entrare nella fase di sviluppo dell'applicazione, devono sussistere due condizioni: il management con l'autorità pertinente ha autorizzato il progetto (implicitamente o esplicitamente), ed è probabile che il progetto venga completato e che il software venga utilizzato per la funzione prevista. Finché entrambe non sono vere, ogni dollaro è ancora una spesa di fase preliminare — incluso un "prototipo" che in seguito diventa produzione.
La capitalizzazione ha anche una definizione ristretta di costi ammissibili. Il costo del personale diretto per gli sviluppatori che lavorano alla costruzione, i costi correlati al personale come i benefit, e le spese di terzi pagate a sviluppatori esterni che lavorano al progetto generalmente si qualificano. La conversione dei dati da un vecchio sistema, la formazione, la manutenzione, le spese generali e i costi amministrativi no — anche quando sono sostenuti durante la finestra di sviluppo dell'applicazione.
Mappare il lavoro sul feature store alle tre fasi
Ecco come una tipica costruzione di Feast si mappa sull'ASC 350-40:
Spesare: la valutazione. Il tuo team spende tre settimane a confrontare Feast con Tecton, prova una pipeline campione e legge la documentazione del fornitore. Fase preliminare — spesare. Questo vale anche se il codice dello spike viene poi riutilizzato in produzione; la fase si giudica in base allo scopo dell'attività al momento, non in base a ciò che il codice diventa.
Capitalizzare: la costruzione. Il management approva la decisione Feast e finanzia il progetto. Gli ingegneri ora distribuiscono il registro, scrivono definizioni di feature di produzione, costruiscono pipeline batch e in streaming, integrano l'online store con il tuo servizio di inferenza ed eseguono test di integrazione e di carico. Il costo del personale ingegneristico diretto durante questa finestra, più eventuali compensi per appaltatori per l'implementazione, viene capitalizzato — presupponendo che tu possa documentare chi ha lavorato a cosa e quando.
Spesare: tutto ciò che viene dopo il go-live. Il tuo turno di reperibilità ottimizza la latenza di Redis, esegue il backfill di una feature dopo un bug della pipeline, integra nuovi modelli nelle pipeline esistenti, aggiorna le versioni di Feast e mantiene le dashboard di monitoraggio. Post-implementazione — spesare. Se sei mesi dopo aggiungi una capacità genuinamente nuova, come una pipeline in streaming per una nuova linea di prodotto, quel potenziamento discreto può qualificarsi per la propria finestra di capitalizzazione.
Il singolo modo di fallire più comune è la mancanza di documentazione. Una capitalizzazione senza tracciamento orario contestuale per fase di progetto raramente sopravvive a un audit. Se il tempo dei tuoi ingegneri non è tracciato distinguendo la costruzione del feature store dal lavoro ordinario, il tuo revisore spesa l'intero importo — il che potrebbe comunque essere la risposta giusta, ma dovrebbe essere una decisione, non un'impostazione predefinita.
Cosa cambia quando invece acquisti Tecton
Acquistare un feature store gestito ribalta il quadro contabile. Tecton è un contratto di servizio, non software che possiedi, quindi i canoni di abbonamento sono costi operativi riconosciuti lungo la durata del contratto — semplice, prevedibile e a prova di audit.
La parte sottile è l'implementazione. Configurare una piattaforma SaaS per il tuo uso — integrare Tecton con il tuo data warehouse, collegare le API di serving all'inferenza, migrare le definizioni delle feature — segue la stessa logica dell'ASC 350-40 secondo la guida sul cloud computing: i costi di implementazione nella fase di sviluppo dell'applicazione possono qualificarsi per la capitalizzazione anche se il software sottostante è ospitato dal fornitore. In pratica, le implementazioni di Tecton sono abbastanza brevi che molte piccole aziende le spesano per motivi di materialità. Ma se la tua integrazione arriva a cifre a sei zeri di tempo ingegneristico, si applica la stessa analisi per fasi, e vale lo stesso standard di documentazione.
C'è una nota strategica qui per i fondatori che raccolgono capitali. Capitalizzare una costruzione su Feast migliora l'EBITDA del periodo corrente e l'aspetto del margine lordo al costo di un onere di ammortamento crescente e di un'attività che il team di due diligence di un acquirente esaminerà nel dettaglio. Spesare un abbonamento Tecton mantiene il conto economico onesto sul burn di regime ma fa sembrare più pesanti i numeri di quest'anno. Nessuno dei due trattamenti è "migliore" — ma gli investitori ti chiederanno quale hai scelto e perché, quindi scegli deliberatamente e documenta il ragionamento.
ASU 2025-06: il modello a fasi sta scomparendo
Il quadro a tre fasi risale al 1998, quando il software veniva costruito in fasi sequenziali a cascata con confini netti. Si adatta male al lavoro agile e iterativo sul feature store — quale sprint è "preliminare" quando ogni sprint va in produzione? Il FASB è d'accordo. A settembre 2025 ha emesso l'ASU 2025-06, che elimina le regole basate sulle fasi e le sostituisce con un quadro basato su principi incentrato sulla persistenza di incertezza significativa sullo sviluppo.
Secondo il nuovo modello, la capitalizzazione inizia quando il management ha autorizzato il progetto, il completamento e l'uso previsto sono probabili, e il concept ha superato l'incertezza significativa sui requisiti di performance, sull'approccio di sviluppo o sulla fattibilità. È efficace per gli esercizi fiscali che iniziano dopo il 15 dicembre 2027, con adozione anticipata consentita. Per una costruzione di feature store che inizia oggi, il consiglio pratico è invariato: ottieni il memo di autorizzazione, traccia il tempo rispetto alla costruzione e separa la valutazione dalla costruzione. Queste abitudini soddisfano sia le vecchie fasi sia i nuovi principi.
Un playbook pratico per la tua costruzione del feature store
Che tu scelga Feast, Tecton o una terza opzione, cinque pratiche mantengono la contabilità pulita:
Ottieni l'autorizzazione per iscritto prima che inizi la costruzione. Un'email del CTO che approva la costruzione di Feast, il budget e l'uso previsto in produzione soddisfa la soglia di autorizzazione. Datela. I revisori chiedono questo documento per primo.
Traccia il tempo di ingegneria per fase dal primo giorno. Gli spike di valutazione vanno in un bucket, il lavoro di costruzione di produzione in un altro, la manutenzione post-lancio in un terzo. Il tracciamento orario basato su tag o l'etichettatura degli sprint funzionano entrambi; ricostruire la suddivisione a memoria sei mesi dopo no.
Capitalizza solo i costi diretti. Il costo del personale sviluppatore e i benefit per le ore dedicate alla costruzione, più le fatture degli appaltatori legate all'implementazione. Escludi formazione, migrazione dei dati dalle pipeline legacy, allocazioni di spese generali e la bolletta dell'infrastruttura cloud per gestire l'online store — l'hosting è un costo operativo del sistema finito, non un costo per costruirlo.
Scegli una vita di ammortamento che puoi difendere. Il software a uso interno è tipicamente ammortizzato a quote costanti su tre-cinque anni. Un feature store costruito su open source in rapida evoluzione, dove una versione principale di Feast potrebbe imporre una ricostruzione, argomenta per il limite inferiore. Documenta il ragionamento nel memo di capitalizzazione.
Verifica l'impairment quando cambiano i fatti. Se abbandoni la costruzione di Feast a metà e firmi con Tecton, l'attività capitalizzata è soggetta a impairment — svalutala. Lo stesso vale se un pivot uccide la linea di prodotto servita dal feature store. Il software capitalizzato che non ha più un uso non è un'attività.
Errori comuni che attirano rettifiche in sede di audit
Gli errori che i revisori trovano nella capitalizzazione dell'infrastruttura sono deprimentemente coerenti. Capitalizzare la fase di valutazione — il confronto tra fornitori, la proof of concept, lo spike — è il più frequente; il lavoro di fase preliminare non è mai capitalizzabile, non importa quanto si riveli utile. Capitalizzare la manutenzione mascherata da sviluppo è al secondo posto: ottimizzare la latenza di serving ed eseguire il backfill delle feature è operatività, non costruzione. Terzo è il memo mancante: un saldo capitalizzato senza documento di autorizzazione, senza analisi per fasi e senza motivazione dell'ammortamento viene spesato su principi generali. Quarto è ammortizzare su vite di fantasia — dieci anni per un'infrastruttura incollata a un progetto open source che rilascia modifiche incompatibili ogni anno. E quinto è dimenticare del tutto la bolletta cloud: i team che capitalizzano con cura il costo del personale ignorando un costo di regime annuo a sei zeri per DynamoDB e calcolo rappresentano in modo errato il confronto build-vs-buy che aveva giustificato il progetto fin dall'inizio.
Traccia la costruzione come l'attività che potrebbe diventare
La decisione Feast-vs-Tecton è di solito inquadrata come orgoglio ingegneristico contro comodità del fornitore. Riformulala come una questione finanziaria e il compromesso si affila: Feast converte la retribuzione in denaro in un'attività capitalizzata con una coda di ammortamento, mentre Tecton converte la stessa capacità in un costo operativo pulito con una data di rinnovo. Il tuo modello di runway, il tuo margine lordo e la tua storia di due diligence cambiano tutti con la scelta — che è esattamente il motivo per cui la contabilità merita un posto nella revisione dell'architettura, non una nota a piè di pagina dopo.
Tutto questo inizia con una banale disciplina di contabilità: tempo etichettato per progetto, autorizzazione datata, fatture degli appaltatori legate alla costruzione e un memo di capitalizzazione che il tuo revisore possa seguire. Se i costi del tuo feature store attualmente vivono come costo del personale ingegneristico indifferenziato in un unico conto di libro mastro, hai già perso l'opzione di capitalizzare — i registri non possono essere ricostruiti a posteriori.
Semplifica la tua gestione finanziaria
Man mano che scali la tua infrastruttura ML, mantenere registri finanziari chiari per le decisioni build-vs-buy, il software capitalizzato e i piani di ammortamento è essenziale. Beancount.io offre una contabilità in testo semplice che ti dà completa trasparenza e controllo sui tuoi dati finanziari — nessuna scatola nera, nessun lock-in del fornitore. Inizia gratuitamente e scopri perché sviluppatori e professionisti della finanza stanno passando alla contabilità in testo semplice.
