El teu equip de ML acaba de passar cinc mesos-enginyer posant en marxa un feature store de codi obert. El teu controller mira l'execució de nòmines i fa una pregunta que ningú de l'equip esperava: aquests $180.000 de temps d'enginyeria són una despesa que impacta aquest trimestre, o un actiu que se situa al balanç? La resposta mou el teu burn multiple, els teus càlculs de runway i — si estàs aixecant finançament — la història que expliquen els teus estats financers. I canvia completament segons si has construït sobre Feast o has comprat Tecton.
Un feature store és la capa d'infraestructura que gestiona, emmagatzema i serveix les característiques (features) d'aprenentatge automàtic tant per a l'entrenament com per a la inferència en temps real. La seva funció principal és evitar el biaix entre entrenament i servei: assegurar que el model vegi exactament les mateixes característiques en producció que les que va veure durant l'entrenament. L'arquitectura té cinc components mòbils — un magatzem offline per a les dades d'entrenament, un magatzem online per a un servei de baixa latència, canals (pipelines) de característiques que calculen valors, un registre central de característiques i APIs de servei. Quan els equips trien entre Feast i Tecton, estan triant entre dos models de propietat molt diferents, i cada model produeix un tractament comptable molt diferent.
Feast vs. Tecton: el compromís entre construir i comprar
Feast és el feature store de codi obert líder: gratuït d'usar, autoallotjat i flexible. Tu mateix executes el magatzem online (normalment Redis o DynamoDB), tu mateix el magatzem offline (S3, BigQuery o Snowflake), i assumeixes cada actualització, cada alerta d'incidència i cada decisió d'escalat. Tecton és l'alternativa comercial totalment gestionada, creada per membres de l'equip darrere de la plataforma Michelangelo d'Uber. Gestiona el servei online i offline, el càlcul de característiques en streaming i la monitorització de característiques integrada, dins d'un contracte SaaS empresarial.
La comparació estàndard és així:
| Factor | Feast | Tecton |
|---|---|---|
| Cost de llicència | Gratuït (només costos d'infraestructura) | Preu SaaS empresarial |
| Servei online | Redis, DynamoDB — tu l'operes | Totalment gestionat |
| Magatzem offline | Parquet, BigQuery, Snowflake — tu el connectes | Gestionat |
| Característiques en streaming | Basat en push, tu construeixes els canals | Càlcul en temps real natiu |
| Monitorització de característiques | Eines externes que has de muntar | Integrada |
| Càrrega operativa | Alta — el teu equip ho executa tot | Baixa — SLAs del proveïdor |
La versió comptablement rellevant d'aquesta taula té una fila més: on apareix els diners. Amb Tecton, gairebé tot el cost arriba com una factura del proveïdor — una despesa de subscripció. Amb Feast, la línia de llicència és zero i el cost real s'amaga en la nòmina d'enginyeria: les setmanes que els teus enginyers de dades passen desplegant el registre, escrivint canals de característiques, ajustant el magatzem online i construint la monitorització que Feast no inclou. La infraestructura de codi obert amb "cost de llicència zero" encara necessita una línia al compte de resultats per hores d'enginyeria, i aquesta línia és exactament el que regula l'ASC 350-40.
La qüestió comptable: què diu realment l'ASC 350-40
Sota els US GAAP, els costos de programari d'ús intern es regeixen per l'ASC 350-40, que classifica cada dòlar d'un projecte de programari en una de tres etapes (consulta la nostra guia pràctica sobre la decisió de capitalitzar vs. despesar per al marc general):
- Etapa de projecte preliminar — despesa quan es produeix. Avaluar proveïdors, fer proves de concepte, comparar Feast amb Tecton, estudis de viabilitat i el mateix anàlisi de construir vs. comprar. Tot això impacta immediatament al compte de resultats.
- Etapa de desenvolupament d'aplicació — capitalitzar els costos elegibles. Un cop la direcció ha autoritzat i s'ha compromès amb el projecte, els costos de dissenyar, programar, configurar, provar i integrar el programari es capitalitzen com un actiu i s'amortitzen al llarg de la seva vida útil. Aquesta és l'única etapa que genera un actiu.
- Etapa de post-implementació i operació — despesa quan es produeix. Formació, manteniment, correcció d'errors i operacions contínues després de la posada en marxa. La funcionalitat nova afegida més endavant pot reiniciar la capitalització, però mantenir el sistema en funcionament mai no ho fa.
Per entrar a l'etapa de desenvolupament d'aplicació, s'han de complir dues condicions: la direcció amb l'autoritat pertinent ha autoritzat el projecte (implícitament o explícitament), i és probable que el projecte es completi i que el programari s'utilitzi per a la seva funció prevista. Fins que ambdues siguin certes, cada dòlar és encara despesa de l'etapa preliminar — incloent-hi un "prototip" que després es converteix en producció.
La capitalització també té una definició estreta de costos elegibles. La nòmina directa dels desenvolupadors que treballen en la construcció, els costos relacionats amb la nòmina com els beneficis, i les tarifes de tercers pagades a desenvolupadors externs que treballen en el projecte generalment qualifiquen. La conversió de dades d'un sistema antic, la formació, el manteniment, les despeses generals i els costos administratius no hi qualifiquen — fins i tot quan es produeixen durant la finestra de desenvolupament d'aplicació.
Mapatge de la feina del feature store a les tres etapes
Així és com un projecte típic de Feast es mapa sobre l'ASC 350-40:
Despesa: l'avaluació. El teu equip passa tres setmanes comparant Feast amb Tecton, prova un canal d'exemple i llegeix la documentació del proveïdor. Etapa preliminar — despesa. Això és cert fins i tot si el codi de la prova es reutilitza després en producció; l'etapa es jutja per la finalitat de l'activitat en aquell moment, no pel que arriba a ser el codi.
Capitalitzar: la construcció. La direcció aprova la decisió de Feast i finança el projecte. Els enginyers ara despleguen el registre, escriuen definicions de característiques de producció, construeixen canals per lots i en streaming, integren el magatzem online amb el teu servei d'inferència i executen proves d'integració i de càrrega. La nòmina directa d'enginyeria durant aquesta finestra, més qualsevol tarifa de contractistes per a la implementació, es capitalitza — sempre que puguis documentar qui va treballar en què i quan.
Despesa: tot el que ve després de la posada en marxa. El teu torn de guàrdia ajusta la latència de Redis, fa un backfill d'una característica després d'un error al canal, incorpora nous models als canals existents, actualitza versions de Feast i manté els quadres de monitorització. Post-implementació — despesa. Si sis mesos després afegeixes una capacitat genuïnament nova, com ara un canal en streaming per a una nova línia de producte, aquesta millora discreta pot qualificar per a la seva pròpia finestra de capitalització.
El mode de fallada més comú és el rastre documental inexistent. La capitalització sense un seguiment del temps contemporani per etapa del projecte poques vegades sobreviu a una auditoria. Si el temps dels teus enginyers no es registra contra la construcció del feature store davant del treball habitual del negoci, el teu auditor ho despesarà tot — cosa que potser és la resposta correcta de totes maneres, però hauria de ser una decisió, no un valor per defecte.
Què canvia quan compres Tecton en lloc de construir-lo
Comprar un feature store gestionat capgira el panorama comptable. Tecton és un contracte de servei, no programari que posseeixes, així que les quotes de subscripció són despeses operatives reconegudes al llarg del termini del contracte — simple, previsible i a prova d'auditoria.
La part subtil és la implementació. Configurar una plataforma SaaS per al teu ús — integrar Tecton amb el teu magatzem de dades, connectar les APIs de servei amb la inferència, migrar les definicions de característiques — segueix la mateixa lògica de l'ASC 350-40 sota la guia de computació al núvol: els costos d'implementació en l'etapa de desenvolupament d'aplicació poden qualificar per a la capitalització tot i que el programari subjacent estigui allotjat pel proveïdor. A la pràctica, les implementacions de Tecton són prou curtes perquè moltes empreses petites les despesin per raons de materialitat. Però si la teva integració arriba a sis xifres de temps d'enginyeria, s'aplica la mateixa anàlisi d'etapes, i es manté el mateix estàndard de documentació.
Hi ha una nota estratègica aquí per als fundadors que aixequen finançament. Capitalitzar una construcció de Feast millora l'EBITDA del període actual i l'aparença del marge brut a costa d'una càrrega d'amortització creixent i d'un actiu que l'equip de diligència d'un adquirent escrutarà. Despesar una subscripció de Tecton manté el compte de resultats honest quant al burn recurrent, però fa que els números d'aquest any semblin més pesats. Cap dels dos tractaments és "millor" — però els inversors preguntaran quin has triat i per què, així que tria deliberadament i documenta el raonament.
ASU 2025-06: el model d'etapes desapareixerà
El marc de tres etapes data de 1998, quan el programari es construïa en fases seqüencials en cascada amb límits clars. Encaixa malament amb la feina àgil i iterativa d'un feature store — quin sprint és "preliminar" quan cada sprint s'envia a producció? El FASB hi va estar d'acord. Al setembre de 2025 va emetre l'ASU 2025-06, que elimina les regles basades en etapes i les substitueix per un marc basat en principis centrat en si queda una incertesa de desenvolupament significativa.
Sota el nou model, la capitalització comença quan la direcció ha autoritzat el projecte, la finalització i l'ús previst són probables, i el concepte ha superat una incertesa significativa sobre els requisits de rendiment, l'enfocament de desenvolupament o la viabilitat. És efectiu per als exercicis fiscals que comencen després del 15 de desembre de 2027, amb adopció anticipada permesa. Per a una construcció de feature store que comença avui, el consell pràctic no canvia: aconsegueix la memòria d'autorització, registra el temps contra la construcció i separa l'avaluació de la construcció. Aquests hàbits satisfan les etapes antigues i els nous principis per igual.
Un manual pràctic per a la teva construcció de feature store
Tant si tries Feast, Tecton o una tercera opció, cinc pràctiques mantenen la comptabilitat neta:
Aconsegueix l'autorització per escrit abans que comenci la construcció. Un correu del CTO aprovant la construcció de Feast, el pressupost i l'ús previst en producció satisfà el llindar d'autorització. Posa-li data. Els auditors demanen aquest document primer.
Registra el temps d'enginyeria per etapa des del primer dia. Les proves d'avaluació van en una caixa, la feina de construcció de producció en una altra, el manteniment posterior al llançament en una tercera. El seguiment del temps per etiquetes o l'etiquetatge de sprints funcionen tots dos; reconstruir la divisió de memòria sis mesos després no.
Capitalitza només costos directes. La nòmina dels desenvolupadors i els beneficis per les hores dedicades a la construcció, més les factures de contractistes vinculades a la implementació. Exclou la formació, la migració de dades de canals heretats, les assignacions de despeses generals i la factura d'infraestructura al núvol per executar el magatzem online — l'allotjament és un cost operatiu del sistema acabat, no un cost de construir-lo.
Tria una vida d'amortització que puguis defensar. El programari d'ús intern normalment s'amortitza linealment al llarg de tres a cinc anys. Un feature store construït sobre codi obert de ràpida evolució, on una versió important de Feast podria forçar una reconstrucció, argumenta a favor de l'extrem curt. Documenta el raonament a la memòria de capitalització.
Prova el deteriorament quan els fets canvien. Si abandonis la construcció de Feast a mig camí i signes amb Tecton, l'actiu capitalitzat està deteriorat — amortitza'l a la baixa. El mateix s'aplica si un pivot mata la línia de producte que servia el feature store. El programari capitalitzat que ja no té ús no és un actiu.
Errors comuns que provoquen ajustaments d'auditoria
Els errors que els auditors troben en la capitalització d'infraestructura són deprimentment consistents. Capitalitzar la fase d'avaluació — la comparació de proveïdors, la prova de concepte, el prototip — és el més freqüent; la feina de l'etapa preliminar mai no és capitalitzable per molt útil que resulti després. Capitalitzar manteniment disfressat de desenvolupament va segon: ajustar la latència del servei i fer backfills de característiques és operació, no construcció. El tercer és la memòria que falta: un saldo capitalitzat sense document d'autorització, sense anàlisi d'etapes i sense raonament d'amortització s'acaba despesant per principis generals. El quart és amortitzar sobre vides fantàstiques — deu anys per a una infraestructura enganxada a un projecte de codi obert que publica canvis incompatibles anualment. I el cinquè és oblidar-se completament de la factura del núvol: els equips que capitalitzen acuradament la nòmina mentre ignoren un cost recurrent anual de sis xifres en DynamoDB i computació distorsionen la comparació construir-vs-comprar que va justificar el projecte en primer lloc.
Segueix la construcció com l'actiu que pot arribar a ser
La decisió Feast-vs-Tecton normalment es planteja com orgull d'enginyeria davant comoditat del proveïdor. Replanteja-la com una qüestió financera i el compromís s'aguditza: Feast converteix la compensació en efectiu en un actiu de capital amb una cua d'amortització, mentre que Tecton converteix la mateixa capacitat en una despesa operativa neta amb una data de renovació. El teu model de runway, el teu marge brut i la teva història de diligència canvien tots amb l'elecció — que és exactament per què la comptabilitat mereix un seient a la revisió d'arquitectura, no una nota a peu de pàgina posterior.
Això comença amb disciplina comptable ordinària: temps etiquetat per projecte, autorització datada, factures de contractistes vinculades a la construcció i una memòria de capitalització que el teu auditor pugui seguir. Si els teus costos de feature store actualment viuen com a nòmina d'enginyeria indiferenciada en un sol compte del llibre major, ja has perdut l'opció de capitalitzar — els registres no es poden reconstruir a posteriori.
Simplifica la teva gestió financera
A mesura que escales la teva infraestructura de ML, mantenir registres financers clars per a les decisions de construir-vs-comprar, el programari capitalitzat i els calendaris d'amortització és essencial. Beancount.io ofereix comptabilitat en text pla que et dona transparència completa i control sobre les teves dades financeres — sense caixes negres, sense dependència del proveïdor. Comença gratis i descobreix per què desenvolupadors i professionals de les finances s'estan passant a la comptabilitat en text pla.
