Sua equipe de ML acabou de gastar cinco meses-engenheiro implantando um feature store de código aberto. Seu controller olha para a folha de pagamento e faz uma pergunta que ninguém na equipe esperava: esses $180.000 de tempo de engenharia são uma despesa que impacta este trimestre, ou um ativo que fica no balanço patrimonial? A resposta altera seu burn multiple, suas contas de runway e — se você está captando recursos — a história que seus demonstrativos financeiros contam. E ela muda completamente dependendo de você ter construído sobre o Feast ou comprado o Tecton.
Um feature store é a camada de infraestrutura que gerencia, armazena e serve features de machine learning tanto para treinamento quanto para inferência em tempo real. Seu papel central é evitar o training-serving skew: garantir que o modelo veja exatamente as mesmas features em produção que usou no treinamento. A arquitetura tem cinco partes móveis — um offline store para dados de treinamento, um online store para servir com baixa latência, pipelines de features que calculam valores, um registro central de features e APIs de serving. Quando as equipes escolhem entre Feast e Tecton, elas estão escolhendo entre dois modelos de propriedade muito diferentes, e cada modelo produz um tratamento contábil muito diferente.
Feast vs. Tecton: o tradeoff entre construir e comprar
O Feast é o principal feature store de código aberto: gratuito para usar, auto-hospedado e flexível. Você mesmo opera o online store (tipicamente Redis ou DynamoDB), o offline store (S3, BigQuery ou Snowflake) por conta própria, e você assume cada upgrade, cada chamado de indisponibilidade e cada decisão de escala. O Tecton é a alternativa comercial totalmente gerenciada, criada por membros da equipe por trás da plataforma Michelangelo do Uber. Ele cuida do serving online e offline, do cálculo de features em streaming e do monitoramento de features integrado, por trás de um contrato SaaS empresarial.
A comparação padrão é mais ou menos assim:
| Fator | Feast | Tecton |
|---|---|---|
| Custo de licença | Gratuito (apenas custos de infraestrutura) | Preço SaaS empresarial |
| Serving online | Redis, DynamoDB — você opera | Totalmente gerenciado |
| Offline store | Parquet, BigQuery, Snowflake — você conecta | Gerenciado |
| Features em streaming | Baseado em push, você constrói os pipelines | Cálculo nativo em tempo real |
| Monitoramento de features | Ferramentas externas que você monta | Integrado |
| Carga operacional | Alta — sua equipe opera tudo | Baixa — SLAs do fornecedor |
A versão contabilmente relevante dessa tabela tem uma linha a mais: onde o dinheiro aparece. Com o Tecton, quase todo o custo chega como fatura do fornecedor — uma despesa de assinatura. Com o Feast, a linha de licença é zero e o custo real se esconde na folha de pagamento de engenharia: as semanas que seus engenheiros de dados gastam implantando o registro, escrevendo pipelines de features, ajustando o online store e construindo o monitoramento que o Feast não entrega. Infraestrutura de código aberto com "custo de licença zero" ainda precisa de uma linha de P&L de horas de engenharia, e essa linha é exatamente o que o ASC 350-40 rege.
A questão contábil: o que o ASC 350-40 realmente diz
Sob os US GAAP, os custos de software de uso interno recaem sob o ASC 350-40, que classifica cada dólar de um projeto de software em uma de três etapas (veja nosso guia prático sobre a decisão de capitalizar vs. despesar para o arcabouço geral):
- Etapa preliminar do projeto — despesa conforme incorrida. Avaliar fornecedores, rodar provas de conceito, comparar Feast com Tecton, estudos de viabilidade e a própria análise de construir vs. comprar. Tudo isso impacta o P&L imediatamente.
- Etapa de desenvolvimento da aplicação — capitalize os custos elegíveis. Assim que a administração autoriza e se compromete com o projeto, os custos de projetar, codificar, configurar, testar e integrar o software são capitalizados como ativo e amortizados ao longo de sua vida útil. Esta é a única etapa que constrói um ativo.
- Etapa pós-implementação e operação — despesa conforme incorrida. Treinamento, manutenção, correção de bugs e operações contínuas após o go-live. Novas funcionalidades adicionadas depois podem reiniciar a capitalização, mas manter as luzes acesas nunca reinicia.
Para entrar na etapa de desenvolvimento da aplicação, duas condições precisam ser atendidas: a administração com a autoridade competente autorizou o projeto (implícita ou explicitamente), e é provável que o projeto seja concluído e o software usado para sua função pretendida. Até que ambas sejam verdadeiras, cada dólar ainda é despesa da etapa preliminar — incluindo um "protótipo" que depois se torna produção.
A capitalização também tem uma definição restrita de custos elegíveis. A folha de pagamento direta dos desenvolvedores que trabalham na construção, custos relacionados à folha como benefícios, e honorários de terceiros pagos a desenvolvedores externos que trabalham no projeto geralmente se qualificam. Conversão de dados de um sistema antigo, treinamento, manutenção, overhead geral e custos administrativos não se qualificam — mesmo quando incorridos durante a janela de desenvolvimento da aplicação.
Mapeando o trabalho do feature store para as três etapas
Veja como uma construção típica do Feast se mapeia ao ASC 350-40:
Despesa: a avaliação. Sua equipe gasta três semanas comparando Feast com Tecton, faz um spike de um pipeline de exemplo e lê a documentação do fornecedor. Etapa preliminar — despesa. Isso é verdade mesmo que o código do spike seja reutilizado depois em produção; a etapa é julgada pelo propósito da atividade na época, não pelo que o código se torna.
Capitalize: a construção. A administração aprova a decisão pelo Feast e financia o projeto. Os engenheiros agora implantam o registro, escrevem definições de features de produção, constroem pipelines em batch e streaming, integram o online store com seu serviço de inferência e rodam testes de integração e de carga. A folha de pagamento direta de engenharia durante essa janela, mais quaisquer honorários de contratados para a implementação, é capitalizada — assumindo que você consiga documentar quem trabalhou no quê e quando.
Despesa: tudo após o go-live. Seu plantão de on-call ajusta a latência do Redis, faz backfill de uma feature após um bug no pipeline, integra novos modelos aos pipelines existentes, atualiza versões do Feast e mantém os dashboards de monitoramento. Pós-implementação — despesa. Se seis meses depois você adicionar uma capacidade genuinamente nova, como um pipeline em streaming para uma nova linha de produto, esse aprimoramento discreto pode se qualificar para sua própria janela de capitalização.
O modo de falha mais comum é a falta de rastro documental. Capitalização sem registro de horas contemporâneo por etapa do projeto raramente sobrevive a uma auditoria. Se o tempo dos seus engenheiros não é rastreado contra a construção do feature store versus o trabalho do dia a dia, seu auditor vai despesar tudo — o que pode até ser a resposta certa, mas deveria ser uma decisão, não um padrão.
O que muda quando você compra o Tecton
Comprar um feature store gerenciado inverte o quadro contábil. O Tecton é um contrato de serviço, não um software que você possui, então as taxas de assinatura são despesas operacionais reconhecidas ao longo do prazo do contrato — simples, previsíveis e à prova de auditoria.
A parte sutil é a implementação. Configurar uma plataforma SaaS para seu uso — integrar o Tecton com seu data warehouse, conectar APIs de serving à inferência, migrar definições de features — segue a mesma lógica do ASC 350-40 sob a orientação de computação em nuvem: custos de implementação na etapa de desenvolvimento da aplicação podem se qualificar para capitalização mesmo que o software subjacente seja hospedado pelo fornecedor. Na prática, implementações do Tecton são curtas o suficiente para que muitas empresas pequenas as despesem por questões de materialidade. Mas se sua integração chegar a seis dígitos de tempo de engenharia, a mesma análise de etapas se aplica, e o mesmo padrão de documentação vale.
Há uma nota de rodapé estratégica aqui para fundadores captando recursos. Capitalizar uma construção com Feast melhora o EBITDA do período atual e a ótica de margem bruta ao custo de um fardo de amortização crescente e de um ativo que a equipe de diligência de um adquirente vai escrutinar. Despesar uma assinatura do Tecton mantém o P&L honesto quanto ao burn recorrente, mas faz os números deste ano parecerem mais pesados. Nenhum tratamento é "melhor" — mas investidores vão perguntar qual você escolheu e por quê, então escolha deliberadamente e documente o raciocínio.
ASU 2025-06: o modelo de etapas vai acabar
O arcabouço de três etapas data de 1998, quando o software era construído em fases sequenciais em cascata, com fronteiras bem definidas. Ele se ajusta mal ao trabalho ágil e iterativo de um feature store — qual sprint é "preliminar" quando todo sprint já vai para produção? O FASB concordou. Em setembro de 2025, emitiu o ASU 2025-06, que elimina as regras baseadas em etapas e as substitui por um arcabouço baseado em princípios, centrado em saber se ainda resta incerteza significativa de desenvolvimento.
Sob o novo modelo, a capitalização começa quando a administração autorizou o projeto, a conclusão e o uso pretendido são prováveis, e o conceito ultrapassou incerteza significativa quanto a requisitos de desempenho, abordagem de desenvolvimento ou viabilidade. É eficaz para exercícios fiscais iniciados após 15 de dezembro de 2027, com adoção antecipada permitida. Para uma construção de feature store começando hoje, o conselho prático é o mesmo: consiga o memorando de autorização, rastreie horas contra a construção e separe avaliação de construção. Esses hábitos satisfazem tanto as etapas antigas quanto os novos princípios.
Um roteiro prático para sua construção de feature store
Se você escolher o Feast, o Tecton ou uma terceira opção, cinco práticas mantêm a contabilidade limpa:
Consiga autorização por escrito antes de a construção começar. Um e-mail do CTO aprovando a construção do Feast, o orçamento e o uso pretendido em produção satisfaz o limiar de autorização. Date-o. Auditores pedem esse documento primeiro.
Rastreie o tempo de engenharia por etapa desde o primeiro dia. Spikes de avaliação vão em um balde, o trabalho de construção de produção em outro, a manutenção pós-lançamento em um terceiro. Rastreamento de tempo por tags ou rotulagem por sprint funcionam; reconstruir a divisão de memória seis meses depois, não.
Capitalize apenas custos diretos. Folha de pagamento e benefícios dos desenvolvedores pelas horas na construção, mais faturas de contratados vinculadas à implementação. Exclua treinamento, migração de dados de pipelines legados, alocações de overhead e a conta de infraestrutura em nuvem para operar o online store — hospedagem é um custo operacional do sistema pronto, não um custo de construí-lo.
Escolha uma vida de amortização que você consiga defender. Software de uso interno é tipicamente amortizado linearmente ao longo de três a cinco anos. Um feature store construído sobre código aberto em rápida evolução, onde uma grande versão do Feast pode forçar uma reconstrução, argumenta pelo extremo mais curto. Documente o raciocínio no memorando de capitalização.
Teste para impairment quando os fatos mudarem. Se você abandonar a construção do Feast no meio do caminho e assinar com o Tecton, o ativo capitalizado sofre impairment — faça o write-down. O mesmo se aplica se um pivô matar a linha de produto que o feature store atendia. Software capitalizado que não tem mais uso não é um ativo.
Erros comuns que geram ajustes de auditoria
Os erros que os auditores encontram na capitalização de infraestrutura são deprimentemente consistentes. Capitalizar a fase de avaliação — a comparação de fornecedores, a prova de conceito, o spike — é o mais frequente; trabalho de etapa preliminar nunca é capitalizável, não importa quão útil se prove. Capitalizar manutenção disfarçada de desenvolvimento vem em segundo: ajustar latência de serving e fazer backfill de features é operação, não construção. O terceiro é o memorando ausente: um saldo capitalizado sem documento de autorização, sem análise de etapas e sem justificativa de amortização acaba despesado por princípios gerais. O quarto é amortizar sobre vidas fantasiosas — dez anos para infraestrutura colada a um projeto de código aberto que lança mudanças disruptivas anualmente. E o quinto é esquecer completamente a conta de nuvem: equipes que capitalizam cuidadosamente a folha de pagamento enquanto ignoram um run rate anual de seis dígitos em DynamoDB e computação distorcem a comparação de construir vs. comprar que justificou o projeto em primeiro lugar.
Rastreie a construção como o ativo que ela pode se tornar
A decisão Feast-vs-Tecton geralmente é enquadrada como orgulho de engenharia versus conveniência do fornecedor. Reenquadre como uma questão financeira e o tradeoff se aguça: o Feast converte compensação em dinheiro em um ativo de capital com uma cauda de amortização, enquanto o Tecton converte a mesma capacidade em uma despesa operacional limpa com uma data de renovação. Seu modelo de runway, sua margem bruta e sua história de diligência mudam todos com a escolha — que é exatamente por que a contabilidade merece um assento na revisão de arquitetura, não uma nota de rodapé depois dela.
Isso começa com disciplina contábil comum: tempo marcado por projeto, autorização datada, faturas de contratados vinculadas à construção e um memorando de capitalização que seu auditor consiga acompanhar. Se seus custos de feature store hoje vivem como folha de pagamento de engenharia indiferenciada em uma única conta contábil, você já perdeu a opção de capitalizar — os registros não podem ser reconstruídos depois do fato.
Simplifique sua gestão financeira
À medida que você escala sua infraestrutura de ML, manter registros financeiros claros para decisões de construir vs. comprar, software capitalizado e cronogramas de amortização é essencial. O Beancount.io oferece contabilidade em texto simples que lhe dá transparência e controle completos sobre seus dados financeiros — sem caixas-pretas, sem vendor lock-in. Comece gratuitamente e veja por que desenvolvedores e profissionais de finanças estão migrando para a contabilidade em texto simples.
