Tu equipo de ML acaba de invertir cinco meses-ingeniero levantando un feature store de código abierto. Tu controller mira la corrida de nómina y hace una pregunta que nadie en el equipo esperaba: ¿esos $180,000 de tiempo de ingeniería son un gasto que impacta este trimestre, o un activo que se sienta en el balance? La respuesta mueve tu burn multiple, tu cálculo de runway y — si estás levantando capital — la historia que cuentan tus estados financieros. Y cambia por completo según si construiste sobre Feast o compraste Tecton.
Un feature store es la capa de infraestructura que gestiona, almacena y sirve features de machine learning tanto para entrenamiento como para inferencia en tiempo real. Su función central es prevenir el training-serving skew: asegurar que el modelo vea exactamente las mismas features en producción que aquellas con las que fue entrenado. La arquitectura tiene cinco componentes móviles — un store offline para datos de entrenamiento, un store online para serving de baja latencia, pipelines de features que calculan valores, un registro central de features y APIs de serving. Cuando los equipos eligen entre Feast y Tecton, están eligiendo entre dos modelos de propiedad muy distintos, y cada modelo produce un tratamiento contable muy diferente.
Feast vs. Tecton: el tradeoff entre construir y comprar
Feast es el feature store de código abierto líder: gratuito de usar, autoalojado y flexible. Tú operas el store online (típicamente Redis o DynamoDB), tú operas el store offline (S3, BigQuery o Snowflake), y asumes cada actualización, cada página de guardia por caídas y cada decisión de escalado. Tecton es la alternativa comercial totalmente gestionada, construida por miembros del equipo detrás de la plataforma Michelangelo de Uber. Maneja el serving online y offline, el cómputo de features en streaming y el monitoreo de features integrado, todo detrás de un contrato SaaS empresarial.
La comparación estándar se ve así:
| Factor | Feast | Tecton |
|---|---|---|
| Costo de licencia | Gratis (solo costos de infraestructura) | Precio SaaS empresarial |
| Serving online | Redis, DynamoDB — tú lo operas | Totalmente gestionado |
| Store offline | Parquet, BigQuery, Snowflake — tú lo conectas | Gestionado |
| Features en streaming | Basado en push, tú construyes los pipelines | Cómputo en tiempo real nativo |
| Monitoreo de features | Herramientas externas que tú ensamblas | Integrado |
| Carga operativa | Alta — tu equipo lo ejecuta todo | Baja — SLAs del proveedor |
La versión contablemente relevante de esta tabla tiene una fila más: dónde aparece el dinero. Con Tecton, casi todo el costo llega como una factura del proveedor — un gasto por suscripción. Con Feast, la línea de licencia es cero y el costo real se esconde en la nómina de ingeniería: las semanas que tus data engineers pasan desplegando el registro, escribiendo pipelines de features, ajustando el store online y construyendo el monitoreo que Feast no trae de fábrica. La infraestructura de código abierto de "costo de licencia cero" igual necesita una línea de horas-ingeniero en el P&L, y esa línea es exactamente lo que gobierna el ASC 350-40.
La pregunta contable: qué dice realmente el ASC 350-40
Bajo los U.S. GAAP, los costos de software de uso interno caen bajo el ASC 350-40, que clasifica cada dólar de un proyecto de software en una de tres etapas (consulta nuestra guía práctica sobre la decisión de capitalizar vs. gastar para el marco general):
- Etapa de proyecto preliminar — gasto según se incurre. Evaluar proveedores, ejecutar pruebas de concepto, comparar Feast contra Tecton, estudios de viabilidad y el propio análisis de construir-vs-comprar. Todo impacta el P&L de inmediato.
- Etapa de desarrollo de la aplicación — capitalizar costos elegibles. Una vez que la dirección ha autorizado y se ha comprometido con el proyecto, los costos de diseñar, programar, configurar, probar e integrar el software se capitalizan como activo y se amortizan a lo largo de su vida útil. Esta es la única etapa que construye un activo.
- Etapa posterior a la implementación y de operación — gasto según se incurre. Capacitación, mantenimiento, corrección de errores y operaciones continuas después del go-live. La funcionalidad nueva añadida después puede reiniciar la capitalización, pero mantener las luces encendidas nunca lo hace.
Para entrar en la etapa de desarrollo de la aplicación, deben cumplirse dos condiciones: la dirección con la autoridad correspondiente ha autorizado el proyecto (implícita o explícitamente), y es probable que el proyecto se complete y que el software se use para su función prevista. Hasta que ambas sean verdaderas, cada dólar sigue siendo gasto de etapa preliminar — incluido un "prototipo" que después se convierte en producción.
La capitalización también tiene una definición estrecha de costos elegibles. La nómina directa de los desarrolladores que trabajan en la construcción, los costos relacionados con la nómina como beneficios, y los honorarios de terceros pagados a desarrolladores externos que trabajan en el proyecto generalmente califican. La conversión de datos desde un sistema antiguo, la capacitación, el mantenimiento, los gastos generales y los costos administrativos no — incluso cuando se incurren dentro de la ventana de desarrollo de la aplicación.
Mapear el trabajo del feature store a las tres etapas
Así se mapea una construcción típica sobre Feast al ASC 350-40:
Gasto: la evaluación. Tu equipo pasa tres semanas comparando Feast contra Tecton, prueba un pipeline de muestra y lee la documentación del proveedor. Etapa preliminar — gasto. Esto es cierto incluso si el código de prueba después se reutiliza en producción; la etapa se juzga por el propósito de la actividad en ese momento, no por en qué se convierte el código.
Capitalizar: la construcción. La dirección aprueba la decisión de Feast y financia el proyecto. Los ingenieros ahora despliegan el registro, escriben definiciones de features de producción, construyen pipelines batch y de streaming, integran el store online con tu servicio de inferencia, y ejecutan pruebas de integración y de carga. La nómina directa de ingeniería durante esta ventana, más cualquier honorario de contratistas por la implementación, se capitaliza — asumiendo que puedes documentar quién trabajó en qué y cuándo.
Gasto: todo lo posterior al go-live. Tu rotación de guardia ajusta la latencia de Redis, rellena una feature tras un bug de pipeline, incorpora nuevos modelos a pipelines existentes, actualiza versiones de Feast y mantiene los dashboards de monitoreo. Post-implementación — gasto. Si seis meses después añades una capacidad genuinamente nueva, como un pipeline de streaming para una nueva línea de producto, esa mejora discreta puede calificar para su propia ventana de capitalización.
El modo de fallo más común es el rastro documental ausente. La capitalización sin registro de tiempo contemporáneo por etapa del proyecto rara vez sobrevive una auditoría. Si el tiempo de tus ingenieros no se registra contra la construcción del feature store versus el trabajo business-as-usual, tu auditor lo gastará todo — lo cual puede ser de todas formas la respuesta correcta, pero debería ser una decisión, no un valor por defecto.
Qué cambia cuando compras Tecton en su lugar
Comprar un feature store gestionado da vuelta el panorama contable. Tecton es un contrato de servicio, no software que posees, así que las cuotas de suscripción son gastos operativos reconocidos a lo largo del plazo del contrato — simple, predecible y a prueba de auditoría.
La parte sutil es la implementación. Configurar una plataforma SaaS para tu uso — integrar Tecton con tu data warehouse, conectar las APIs de serving a la inferencia, migrar definiciones de features — sigue la misma lógica del ASC 350-40 bajo la guía de cloud computing: los costos de implementación en la etapa de desarrollo de la aplicación pueden calificar para capitalización aunque el software subyacente esté alojado por el proveedor. En la práctica, las implementaciones de Tecton son lo bastante cortas como para que muchas empresas pequeñas las gasten por razones de materialidad. Pero si tu integración llega a seis cifras de tiempo de ingeniería, aplica el mismo análisis de etapas y se mantiene el mismo estándar de documentación.
Hay una nota al pie estratégica aquí para los fundadores que levantan capital. Capitalizar una construcción sobre Feast mejora el EBITDA del período actual y la óptica del margen bruto a costa de una carga creciente de amortización y un activo que el equipo de diligencia de un adquirente escudriñará. Gastar una suscripción de Tecton mantiene el P&L honesto sobre el burn de run-rate pero hace que los números de este año se vean más pesados. Ningún tratamiento es "mejor" — pero los inversionistas preguntarán cuál elegiste y por qué, así que elige deliberadamente y documenta el razonamiento.
ASU 2025-06: el modelo de etapas va a desaparecer
El marco de tres etapas data de 1998, cuando el software se construía en fases secuenciales en cascada con límites claros. Encaja mal con el trabajo ágil e iterativo de un feature store — ¿qué sprint es "preliminar" cuando cada sprint llega a producción? El FASB estuvo de acuerdo. En septiembre de 2025 emitió el ASU 2025-06, que elimina las reglas basadas en etapas y las reemplaza con un marco basado en principios centrado en si permanece una incertidumbre significativa de desarrollo.
Bajo el nuevo modelo, la capitalización comienza cuando la dirección ha autorizado el proyecto, la finalización y el uso previsto son probables, y el concepto ha superado la incertidumbre significativa sobre requisitos de rendimiento, enfoque de desarrollo o viabilidad. Es efectivo para ejercicios fiscales que comienzan después del 15 de diciembre de 2027, con adopción anticipada permitida. Para una construcción de feature store que comienza hoy, el consejo práctico no cambia: consigue el memo de autorización, registra el tiempo contra la construcción y separa la evaluación de la construcción. Esos hábitos satisfacen tanto las viejas etapas como los nuevos principios.
Un manual práctico para tu construcción de feature store
Ya sea que elijas Feast, Tecton o una tercera opción, cinco prácticas mantienen la contabilidad limpia:
Consigue la autorización por escrito antes de que empiece la construcción. Un correo del CTO aprobando la construcción de Feast, el presupuesto y el uso previsto en producción satisface el umbral de autorización. Ponle fecha. Los auditores piden este documento primero.
Registra el tiempo de ingeniería por etapa desde el día uno. Las pruebas de evaluación van en un bucket, el trabajo de construcción de producción en otro, el mantenimiento posterior al lanzamiento en un tercero. El registro de tiempo por etiquetas o el etiquetado de sprints funcionan; reconstruir la división de memoria seis meses después no.
Capitaliza solo costos directos. La nómina y beneficios de los desarrolladores por horas en la construcción, más las facturas de contratistas vinculadas a la implementación. Excluye capacitación, migración de datos desde pipelines heredados, asignaciones de gastos generales y la factura de infraestructura cloud por operar el store online — el hosting es un costo operativo del sistema terminado, no un costo de construirlo.
Elige una vida de amortización que puedas defender. El software de uso interno típicamente se amortiza en línea recta a lo largo de tres a cinco años. Un feature store construido sobre código abierto de rápido movimiento, donde una versión mayor de Feast podría forzar una reconstrucción, aboga por el extremo corto. Documenta el razonamiento en el memo de capitalización.
Prueba el deterioro cuando cambien los hechos. Si abandonas la construcción de Feast a mitad de camino y firmas con Tecton, el activo capitalizado está deteriorado — castígalo. Lo mismo aplica si un pivote mata la línea de producto a la que servía el feature store. El software capitalizado que ya no tiene uso no es un activo.
Errores comunes que provocan ajustes de auditoría
Los errores que los auditores encuentran en la capitalización de infraestructura son deprimentemente consistentes. Capitalizar la fase de evaluación — la comparación de proveedores, la prueba de concepto, el spike — es el más frecuente; el trabajo de etapa preliminar nunca es capitalizable sin importar lo útil que resulte. Capitalizar mantenimiento disfrazado de desarrollo va segundo: ajustar la latencia de serving y rellenar features es operación, no construcción. Tercero es el memo ausente: un saldo capitalizado sin documento de autorización, sin análisis de etapas y sin justificación de amortización se gasta por principios generales. Cuarto es amortizar sobre vidas fantásticas — diez años para infraestructura pegada a un proyecto de código abierto que publica cambios disruptivos anualmente. Y quinto es olvidar por completo la factura cloud: los equipos que capitalizan cuidadosamente la nómina mientras ignoran un run rate anual de seis cifras en DynamoDB y cómputo distorsionan la comparación construir-vs-comprar que justificó el proyecto en primer lugar.
Rastrea la construcción como el activo que puede llegar a ser
La decisión Feast-vs-Tecton normalmente se enmarca como orgullo de ingeniería versus conveniencia del proveedor. Reencuádrala como una pregunta financiera y el tradeoff se agudiza: Feast convierte la compensación en efectivo en un activo capitalizable con una cola de amortización, mientras que Tecton convierte la misma capacidad en un gasto operativo limpio con una fecha de renovación. Tu modelo de runway, tu margen bruto y tu historia de diligencia cambian todos con la elección — que es exactamente por qué la contabilidad merece un asiento en la revisión de arquitectura, no una nota al pie después.
Eso empieza con disciplina contable ordinaria: tiempo etiquetado por proyecto, autorización con fecha, facturas de contratistas vinculadas a la construcción y un memo de capitalización que tu auditor pueda seguir. Si tus costos de feature store actualmente viven como nómina de ingeniería indiferenciada en una sola cuenta contable, ya perdiste la opción de capitalizar — los registros no se pueden reconstruir después de los hechos.
Simplifica tu gestión financiera
A medida que escalas tu infraestructura de ML, mantener registros financieros claros para las decisiones de construir-vs-comprar, el software capitalizado y los calendarios de amortización es esencial. Beancount.io ofrece contabilidad en texto plano que te da transparencia y control totales sobre tus datos financieros — sin cajas negras, sin vendor lock-in. Comienza gratis y descubre por qué desarrolladores y profesionales de finanzas se están cambiando a la contabilidad en texto plano.
