Je ML-team heeft net vijf engineer-maanden besteed aan het opzetten van een open-source feature store. Je controller kijkt naar de loonrun en stelt een vraag die niemand in het team had verwacht: is die $180.000 aan engineeringtijd een kostenpost die dit kwartaal drukt, of een actief dat op de balans staat? Het antwoord beïnvloedt je burn multiple, je runway-berekening en — als je aan het ophalen bent — het verhaal dat je financiële cijfers vertellen. En het verandert volledig afhankelijk van of je op Feast hebt gebouwd of Tecton hebt gekocht.
Een feature store is de infrastructuurlaag die machine-learningfeatures beheert, opslaat en serveert voor zowel training als real-time inferentie. De kernopdracht is het voorkomen van training-serving skew: ervoor zorgen dat het model in productie precies dezelfde features ziet als waarmee het is getraind. De architectuur heeft vijf bewegende delen — een offline store voor trainingsdata, een online store voor low-latency serving, feature pipelines die waarden berekenen, een centraal feature register en serving-API's. Wanneer teams kiezen tussen Feast en Tecton, kiezen ze tussen twee heel verschillende eigendomsmodellen, en elk model levert een heel andere boekhoudkundige behandeling op.
Feast vs. Tecton: de build-vs-buy-afweging
Feast is de toonaangevende open-source feature store: gratis te gebruiken, self-hosted en flexibel. Je draait de online store zelf (doorgaans Redis of DynamoDB), de offline store zelf (S3, BigQuery of Snowflake), en je bent eigenaar van elke upgrade, elke outage-pagina en elke schalingsbeslissing. Tecton is het volledig managed commerciële alternatief, gebouwd door leden van het team achter Uber's Michelangelo-platform. Het verzorgt online en offline serving, streaming feature-berekening en ingebouwde feature-monitoring achter een enterprise SaaS-contract.
De standaardvergelijking ziet er zo uit:
| Factor | Feast | Tecton |
|---|---|---|
| Licentiekosten | Gratis (alleen infrastructuurkosten) | Enterprise SaaS-prijzen |
| Online serving | Redis, DynamoDB — jij beheert het | Volledig managed |
| Offline store | Parquet, BigQuery, Snowflake — jij knoopt het aan elkaar | Managed |
| Streaming features | Push-based, jij bouwt de pipelines | Native real-time berekening |
| Feature-monitoring | Externe tooling die je zelf samenstelt | Ingebouwd |
| Operationele last | Hoog — je team draait alles | Laag — vendor SLA's |
De boekhoudkundig relevante versie van deze tabel heeft nog één rij: waar het geld terechtkomt. Bij Tecton komt vrijwel alle kosten binnen als een leveranciersfactuur — een abonnementskostenpost. Bij Feast is de licentierij nul en verstopt de werkelijke kost zich in engineeringloon: de weken die je data-engineers besteden aan het uitrollen van het register, het schrijven van feature pipelines, het tunen van de online store en het bouwen van de monitoring die Feast niet meelevert. "Nul licentiekosten" open-source infrastructuur heeft alsnog een P&L-regel voor engineeringuren nodig, en die regel is precies wat ASC 350-40 beheerst.
De boekhoudkundige vraag: wat ASC 350-40 werkelijk zegt
Onder U.S. GAAP vallen kosten voor internal-use software onder ASC 350-40, dat elke dollar van een softwareproject indeelt in een van drie fasen (zie onze praktische gids voor de capitalize-vs-expense-beslissing voor het algemene kader):
- Preliminary project stage — direct als kosten nemen. Het evalueren van leveranciers, het uitvoeren van proof-of-concept-spikes, het vergelijken van Feast met Tecton, haalbaarheidsstudies en de build-vs-buy-analyse zelf. Alles drukt onmiddellijk op de P&L.
- Application development stage — in aanmerking komende kosten activeren. Zodra het management het project heeft geautoriseerd en zich eraan heeft gecommitteerd, worden de kosten van ontwerpen, coderen, configureren, testen en integreren van de software geactiveerd als een actief en afgeschreven over de gebruiksduur. Dit is de enige fase die een actief opbouwt.
- Post-implementation and operation stage — direct als kosten nemen. Training, onderhoud, bugfixes en doorlopende operatie na go-live. Nieuw toegevoegde functionaliteit kan later de activering heropstarten, maar het draaiende houden van de boel doet dat nooit.
Om de application development stage te betreden, moeten twee voorwaarden gelden: het bevoegde management heeft het project geautoriseerd (impliciet of expliciet), en het is waarschijnlijk dat het project wordt afgerond en de software voor de beoogde functie wordt gebruikt. Totdat beide waar zijn, is elke dollar nog preliminary-stage-kost — inclusief een "prototype" dat later productie wordt.
Activering kent ook een nauwe definitie van in aanmerking komende kosten. Direct loon voor ontwikkelaars die aan de build werken, loongerelateerde kosten zoals benefits, en aan derden betaalde vergoedingen voor externe ontwikkelaars die aan het project werken, komen doorgaans in aanmerking. Dataconversie van een oud systeem, training, onderhoud, algemene overhead en administratieve kosten niet — zelfs niet wanneer ze zijn gemaakt binnen het application development-venster.
Feature-store-werk mappen op de drie fasen
Zo mapt een typische Feast-build op ASC 350-40:
Kosten: de evaluatie. Je team besteedt drie weken aan het benchmarken van Feast tegen Tecton, spiket een voorbeeldpipeline en leest leveranciersdocumentatie. Preliminary stage — kosten. Dit geldt zelfs als de spike-code later in productie wordt hergebruikt; de fase wordt beoordeeld op het doel van de activiteit op dat moment, niet op wat de code wordt.
Activeren: de build. Het management keurt de Feast-beslissing goed en financiert het project. Engineers rollen nu het register uit, schrijven productie-featuredefinities, bouwen batch- en streaming-pipelines, integreren de online store met je inferentieservice en draaien integratie- en loadtests. Direct engineeringloon in dit venster, plus eventuele contractor-fees voor de implementatie, wordt geactiveerd — ervan uitgaande dat je kunt documenteren wie aan wat werkte en wanneer.
Kosten: alles na go-live. Je on-call-rotatie tunet Redis-latency, backfillt een feature na een pipeline-bug, onboardt nieuwe modellen op bestaande pipelines, upgradet Feast-versies en onderhoudt de monitoring-dashboards. Post-implementation — kosten. Als je zes maanden later een werkelijk nieuwe capaciteit toevoegt, zoals een streaming-pipeline voor een nieuwe productlijn, kan die discrete verbetering in aanmerking komen voor een eigen activeringsvenster.
De meest voorkomende faalmodus is het ontbrekende papieren spoor. Activering zonder gelijktijdige tijdregistratie per projectfase overleeft zelden een audit. Als de tijd van je engineers niet wordt gevolgd tegen de feature-store-build versus business-as-usual-werk, zal je auditor alles als kosten behandelen — wat misschien toch het juiste antwoord is, maar het moet een beslissing zijn, niet een default.
Wat verandert wanneer je in plaats daarvan Tecton koopt
Het kopen van een managed feature store kantelt het boekhoudkundige beeld. Tecton is een servicecontract, geen software die je bezit, dus de abonnementskosten zijn operationele kosten die over de contractduur worden verantwoord — eenvoudig, voorspelbaar en audit-proof.
Het subtiele deel is de implementatie. Het configureren van een SaaS-platform voor jouw gebruik — Tecton integreren met je datawarehouse, serving-API's aansluiten op inferentie, featuredefinities migreren — volgt dezelfde ASC 350-40-logica onder de cloud-computing-richtlijnen: implementatiekosten in de application development stage kunnen in aanmerking komen voor activering, ook al wordt de onderliggende software door de leverancier gehost. In de praktijk zijn Tecton-implementaties kort genoeg dat veel kleine bedrijven ze op materialiteitsoverwegingen als kosten behandelen. Maar als je integratie uitkomt op zes cijfers aan engineeringtijd, geldt dezelfde faseanalyse en dezelfde documentatiestandaard.
Er zit hier een strategische voetnoot voor founders die aan het ophalen zijn. Het activeren van een Feast-build verbetert de EBITDA en de gross-margin-optiek van de huidige periode, ten koste van een groeiende afschrijvingslast en een actief dat het due-diligence-team van een overnemer zal wantrouwen. Het als kosten nemen van een Tecton-abonnement houdt de P&L eerlijk over run-rate burn, maar laat de cijfers van dit jaar zwaarder lijken. Geen van beide behandelingen is "beter" — maar investeerders zullen vragen welke je hebt gekozen en waarom, dus kies bewust en documenteer de redenering.
ASU 2025-06: het fasemodel verdwijnt
Het driefasige kader dateert uit 1998, toen software werd gebouwd in sequentiële watervalfasen met heldere grenzen. Het past slecht bij agile, iteratief feature-store-werk — welke sprint is "preliminary" als elke sprint naar productie gaat? FASB was het daarmee eens. In september 2025 vaardigde het ASU 2025-06 uit, dat de op fasen gebaseerde regels elimineert en vervangt door een op principes gebaseerd kader dat draait om de vraag of er nog significante ontwikkelingsonzekerheid bestaat.
Onder het nieuwe model begint activering wanneer het management het project heeft geautoriseerd, afronding en beoogd gebruik waarschijnlijk zijn, en het concept voorbij significante onzekerheid is over prestatie-eisen, ontwikkelaanpak of haalbaarheid. Het is effectief voor boekjaren die beginnen na 15 december 2027, met eerdere toepassing toegestaan. Voor een feature-store-build die vandaag start, is het praktische advies onveranderd: zorg voor de autorisatiememo, registreer tijd tegen de build en scheid evaluatie van constructie. Die gewoonten voldoen zowel aan de oude fasen als aan de nieuwe principes.
Een praktisch draaiboek voor je feature-store-build
Of je nu kiest voor Feast, Tecton of een derde optie, vijf praktijken houden de boekhouding schoon:
Zorg voor schriftelijke autorisatie voordat de build begint. Een e-mail van de CTO waarin de Feast-build, het budget en het beoogde productiegebruik worden goedgekeurd, voldoet aan de autorisatiedrempel. Dateer hem. Auditors vragen eerst naar dit document.
Registreer engineeringtijd vanaf dag één per fase. Evaluatiespikes gaan in het ene bakje, productie-build-werk in een ander, onderhoud na launch in een derde. Tag-based tijdregistratie of sprint-labeling werken beide; het zes maanden later reconstrueren van de splitsing uit het geheugen niet.
Activeer alleen directe kosten. Ontwikkelaarsloon en benefits voor uren aan de build, plus contractor-facturen die aan de implementatie zijn gekoppeld. Sluit training, datamigratie van legacy-pipelines, overheadtoewijzingen en de cloud-infrastructuurfactuur voor het draaien van de online store uit — hosting is een operationele kost van het voltooide systeem, niet een kost om het te bouwen.
Kies een afschrijvingstermijn die je kunt verdedigen. Internal-use software wordt doorgaans lineair afgeschreven over drie tot vijf jaar. Een feature store gebouwd op snel bewegende open source, waar een grote Feast-versie een rebuild kan forceren, pleit voor het korte eind. Documenteer de redenering in de activeringsmemo.
Test op impairment wanneer de feiten veranderen. Als je de Feast-build halverwege laat vallen en met Tecton tekent, is het geactiveerde actief impaired — schrijf het af. Hetzelfde geldt als een pivot de productlijn doodt die de feature store bediende. Geactiveerde software die geen nut meer heeft, is geen actief.
Veelvoorkomende fouten die auditcorrecties uitlokken
De fouten die auditors bij infrastructuuractivering vinden, zijn deprimerend consistent. Het activeren van de evaluatiefase — de leveranciersvergelijking, het proof of concept, de spike — komt het vaakst voor; preliminary-stage-werk is nooit activeerbaar, hoe nuttig het later ook blijkt te zijn. Het activeren van onderhoud vermomd als ontwikkeling staat tweede: het tunen van serving-latency en het backfillen van features is operatie, geen constructie. Derde is de ontbrekende memo: een geactiveerd saldo zonder autorisatiedocument, zonder faseanalyse en zonder afschrijvingsrationale wordt volgens algemene principes als kosten behandeld. Vierde is afschrijven over fantasietermijnen — tien jaar voor infrastructuur die vastzit aan een open-sourceproject dat jaarlijks breaking changes uitbrengt. En vijfde is de cloud-factuur volledig vergeten: teams die zorgvuldig loon activeren terwijl ze een jaarlijkse DynamoDB-en-compute-run-rate van zes cijfers negeren, geven de build-vs-buy-vergelijking die het project in de eerste plaats rechtvaardigde verkeerd weer.
Volg de build als het actief dat het mogelijk wordt
De Feast-vs-Tecton-beslissing wordt meestal geframed als engineeringtrots versus leveranciersgemak. Herformuleer het als een financiële vraag en de afweging wordt scherper: Feast zet contante beloning om in een kapitaalgoed met een afschrijvingsstaart, terwijl Tecton dezelfde capaciteit omzet in een schone operationele kost met een verlengingsdatum. Je runway-model, je gross margin en je due-diligence-verhaal veranderen allemaal met de keuze — wat precies is waarom de boekhouding een stoel verdient bij de architectuurreview, niet een voetnoot erna.
Dat begint met gewone boekhouddiscipline: project-getagde tijd, gedateerde autorisatie, contractor-facturen gekoppeld aan de build en een activeringsmemo die je auditor kan volgen. Als je feature-store-kosten momenteel als ongedifferentieerd engineeringloon op één grootboekrekening staan, heb je de optie om te activeren al verloren — de administratie kan achteraf niet worden gereconstrueerd.
Vereenvoudig je financieel beheer
Naarmate je ML-infrastructuur schaalt, is het essentieel om heldere financiële administratie bij te houden voor build-vs-buy-beslissingen, geactiveerde software en afschrijvingsschema's. Beancount.io biedt plain-text accounting die je volledige transparantie en controle over je financiële data geeft — geen black boxes, geen vendor lock-in. Begin gratis en zie waarom ontwikkelaars en finance-professionals overstappen op plain-text accounting.
