Your ML team just spent five engineer-months standing up an open-source feature store. Your controller looks at the payroll run and asks a question nobody on the team expected: is that $180,000 of engineering time an expense that hits this quarter, or an asset that sits on the balance sheet? The answer moves your burn multiple, your runway math, and — if you are raising — the story your financials tell. And it changes completely depending on whether you built on Feast or bought Tecton.
A feature store is the infrastructure layer that manages, stores, and serves machine-learning features for both training and real-time inference. Its core job is preventing training-serving skew: making sure the model sees exactly the same features in production that it trained on. The architecture has five moving parts — an offline store for training data, an online store for low-latency serving, feature pipelines that compute values, a central feature registry, and serving APIs. When teams choose between Feast and Tecton, they are choosing between two very different ownership models, and each model produces a very different accounting treatment.
Feast vs. Tecton: the Build-vs-Buy Tradeoff
Feast is the leading open-source feature store: free to use, self-hosted, and flexible. You run the online store yourself (typically Redis or DynamoDB), the offline store yourself (S3, BigQuery, or Snowflake), and you own every upgrade, outage page, and scaling decision. Tecton is the fully managed commercial alternative, built by members of the team behind Uber's Michelangelo platform. It handles online and offline serving, streaming feature computation, and built-in feature monitoring behind an enterprise SaaS contract.
The standard comparison looks like this:
| Factor | Feast | Tecton |
|---|---|---|
| License cost | Free (infrastructure costs only) | Enterprise SaaS pricing |
| Online serving | Redis, DynamoDB — you operate it | Fully managed |
| Offline store | Parquet, BigQuery, Snowflake — you wire it up | Managed |
| Streaming features | Push-based, you build the pipelines | Native real-time computation |
| Feature monitoring | External tooling you assemble | Built in |
| Operations burden | High — your team runs everything | Low — vendor SLAs |
The accounting-relevant version of this table has one more row: where the money shows up. With Tecton, nearly all of the cost arrives as a vendor invoice — a subscription expense. With Feast, the license line is zero and the real cost hides in engineering payroll: the weeks your data engineers spend deploying the registry, writing feature pipelines, tuning the online store, and building the monitoring Feast does not ship with. "Zero license cost" open-source infrastructure still needs an engineering-hours P&L line, and that line is exactly what ASC 350-40 governs.
The Accounting Question: What ASC 350-40 Actually Says
Under U.S. GAAP, internal-use software costs fall under ASC 350-40, which sorts every dollar of a software project into one of three stages (see our practical guide to the capitalize-vs-expense decision for the general framework):
- Preliminary project stage — expense as incurred. Evaluating vendors, running proof-of-concept spikes, comparing Feast against Tecton, feasibility studies, and the build-vs-buy analysis itself. All of it hits the P&L immediately.
- Application development stage — capitalize eligible costs. Once management has authorized and committed to the project, the costs of designing, coding, configuring, testing, and integrating the software are capitalized as an asset and amortized over its useful life. This is the only stage that builds an asset.
- Post-implementation and operation stage — expense as incurred. Training, maintenance, bug fixes, and ongoing operations after go-live. New functionality added later can restart capitalization, but keeping the lights on never does.
To enter the application development stage, two conditions must hold: management with the relevant authority has authorized the project (implicitly or explicitly), and it is probable the project will be completed and the software used for its intended function. Until both are true, every dollar is still preliminary-stage expense — including a "prototype" that later becomes production.
Capitalization also has a narrow definition of eligible costs. Direct payroll for developers working on the build, payroll-related costs like benefits, and third-party fees paid to outside developers working on the project generally qualify. Data conversion from an old system, training, maintenance, general overhead, and administrative costs do not — even when incurred during the application development window.
Mapping Feature-Store Work to the Three Stages
Here is how a typical Feast build maps onto ASC 350-40:
Expense: the evaluation. Your team spends three weeks benchmarking Feast against Tecton, spikes a sample pipeline, and reads vendor documentation. Preliminary stage — expense. This is true even if the spike code later gets reused in production; the stage is judged by the activity's purpose at the time, not by what the code becomes.
Capitalize: the build. Management approves the Feast decision and funds the project. Engineers now deploy the registry, write production feature definitions, build batch and streaming pipelines, integrate the online store with your inference service, and run integration and load testing. Direct engineering payroll during this window, plus any contractor fees for the implementation, is capitalized — assuming you can document who worked on what and when.
Expense: everything after go-live. Your on-call rotation tunes Redis latency, backfills a feature after a pipeline bug, onboards new models to existing pipelines, upgrades Feast versions, and maintains the monitoring dashboards. Post-implementation — expense. If six months later you add a genuinely new capability, such as a streaming pipeline for a new product line, that discrete enhancement can qualify for its own capitalization window.
The single most common failure mode is the missing paper trail. Capitalization without contemporaneous time tracking by project stage rarely survives an audit. If your engineers' time is not tracked against the feature-store build versus business-as-usual work, your auditor will expense the whole thing — which may be the right answer anyway, but it should be a decision, not a default.
What Changes When You Buy Tecton Instead
Buying a managed feature store flips the accounting picture. Tecton is a service contract, not software you own, so the subscription fees are operating expenses recognized over the contract term — simple, predictable, and audit-proof.
The subtle part is implementation. Configuring a SaaS platform for your use — integrating Tecton with your data warehouse, wiring serving APIs into inference, migrating feature definitions — follows the same ASC 350-40 logic under the cloud-computing guidance: implementation costs in the application development stage can qualify for capitalization even though the underlying software is hosted by the vendor. In practice, Tecton implementations are short enough that many small companies expense them on materiality grounds. But if your integration runs into six figures of engineering time, the same stage analysis applies, and the same documentation standard holds.
There is a strategic footnote here for fundraising founders. Capitalizing a Feast build improves current-period EBITDA and gross margin optics at the cost of a growing amortization burden and an asset an acquirer's diligence team will scrutinize. Expensing a Tecton subscription keeps the P&L honest about run-rate burn but makes this year's numbers look heavier. Neither treatment is "better" — but investors will ask which one you chose and why, so choose deliberately and document the reasoning.
ASU 2025-06: the Stage Model Is Going Away
The three-stage framework dates to 1998, when software was built in sequential waterfall phases with clean boundaries. It fits agile, iterative feature-store work poorly — which sprint is "preliminary" when every sprint ships to production? FASB agreed. In September 2025 it issued ASU 2025-06, which eliminates the stage-based rules and replaces them with a principles-based framework centered on whether significant development uncertainty remains.
Under the new model, capitalization begins when management has authorized the project, completion and intended use are probable, and the concept has moved past significant uncertainty about performance requirements, development approach, or feasibility. It is effective for fiscal years beginning after December 15, 2027, with early adoption permitted. For a feature-store build starting today, the practical advice is unchanged: get the authorization memo, track time against the build, and separate evaluation from construction. Those habits satisfy the old stages and the new principles alike.
A Practical Playbook for Your Feature-Store Build
Whether you choose Feast, Tecton, or a third option, five practices keep the accounting clean:
Get authorization in writing before the build starts. An email from the CTO approving the Feast build, the budget, and the intended production use satisfies the authorization threshold. Date it. Auditors ask for this document first.
Track engineering time by stage from day one. Evaluation spikes go in one bucket, production build work in another, post-launch maintenance in a third. Tag-based time tracking or sprint labeling both work; reconstructing the split from memory six months later does not.
Capitalize only direct costs. Developer payroll and benefits for hours on the build, plus contractor invoices tied to the implementation. Exclude training, data migration from legacy pipelines, overhead allocations, and the cloud infrastructure bill for running the online store — hosting is an operating cost of the finished system, not a cost of building it.
Pick an amortization life you can defend. Internal-use software is typically amortized straight-line over three to five years. A feature store built on fast-moving open source, where a major Feast version could force a rebuild, argues for the short end. Document the reasoning in the capitalization memo.
Test for impairment when the facts change. If you abandon the Feast build halfway and sign with Tecton, the capitalized asset is impaired — write it down. The same applies if a pivot kills the product line the feature store served. Capitalized software that no longer has a use is not an asset.
Common Mistakes That Draw Audit Adjustments
The errors auditors find in infrastructure capitalization are depressingly consistent. Capitalizing the evaluation phase — the vendor comparison, the proof of concept, the spike — is the most frequent; preliminary-stage work is never capitalizable no matter how useful it proves. Capitalizing maintenance disguised as development runs second: tuning serving latency and backfilling features is operations, not construction. Third is the missing memo: a capitalized balance with no authorization document, no stage analysis, and no amortization rationale gets expensed on general principles. Fourth is amortizing over fantasy lives — ten years for infrastructure glued to an open-source project that ships breaking changes annually. And fifth is forgetting the cloud bill entirely: teams that carefully capitalize payroll while ignoring a six-figure annual DynamoDB-and-compute run rate misstate the build-vs-buy comparison that justified the project in the first place.
Track the Build Like the Asset It May Become
The Feast-vs-Tecton decision is usually framed as engineering pride versus vendor convenience. Reframe it as a financial question and the tradeoff sharpens: Feast converts cash compensation into a capital asset with an amortization tail, while Tecton converts the same capability into a clean operating expense with a renewal date. Your runway model, your gross margin, and your diligence story all change with the choice — which is exactly why the accounting deserves a seat at the architecture review, not a footnote after it.
That starts with ordinary bookkeeping discipline: project-tagged time, dated authorization, contractor invoices tied to the build, and a capitalization memo your auditor can follow. If your feature-store costs currently live as undifferentiated engineering payroll in one ledger account, you have already lost the option to capitalize — the records cannot be reconstructed after the fact.
Simplify Your Financial Management
As you scale your ML infrastructure, maintaining clear financial records for build-vs-buy decisions, capitalized software, and amortization schedules is essential. Beancount.io provides plain-text accounting that gives you complete transparency and control over your financial data — no black boxes, no vendor lock-in. Get started for free and see why developers and finance professionals are switching to plain-text accounting.
