Insect Protein Farming Software: Tracking Crates, Feedstock Approval, and Lot Genealogy at Industrial Scale

A crate is a batch, and you have two hundred thousand of them

Walk a black soldier fly plant and the scale of the tracking problem is immediately obvious. Neonates are seeded into crates at a target density, the crates take a substrate loading, and then they move through climate zones on a strict day count until harvest, at which point larvae are separated from frass, killed, dried, and pressed into meal and oil. Every crate is a batch. A plant of any real size is running hundreds of thousands of these batches through the building at once, each one a few days apart from its neighbour, each one carrying a feedstock composition that came from whatever waste stream arrived that week.

That is not a farm and it is not a normal factory. A farm has fields and seasons. A factory has work orders that consume inventory and produce output on a bill of materials. Here the unit of production is a physical container moving through space on a biological clock, and the input is a variable waste stream whose composition changes with the season, the supplier, and the truck.

Almost every operation at this stage runs on a mix of spreadsheets, a warehouse label printer, whatever the climate control system provides, and a lot of institutional memory in the heads of the two people who commissioned the line. That works until the day someone asks which feedstock intakes went into a specific tonne of meal shipped to an aquafeed customer, and the honest answer is a week of work and an approximation.

Why the feed ingredient status is the entire business

The product only has value because it is an approved feed ingredient. In the European Union the permitted substrate list for farmed insects is narrow, excluding manure and catering waste, and processed animal protein from insects has been authorised progressively by species and by target animal. In the United States, AAFCO ingredient definitions cover black soldier fly larvae for defined species and defined feed uses. The detail differs by jurisdiction and it moves, and you should be taking that from your regulatory adviser rather than from a blog.

What does not change is the operational consequence. Approval is conditional on what you fed the insects. That makes feedstock control the compliance boundary of the whole plant. A single intake of an unapproved or undocumented substrate does not spoil one batch, it contaminates the genealogy of every finished lot that touched it, and if you cannot draw that boundary precisely you have to write off far more than you needed to.

So the requirement is blunt: every kilogram of finished meal must be traceable back to the specific intakes that fed it, with the supplier declaration and the acceptance decision attached. Not the week. Not the line. The intakes. This is the single hardest thing to retrofit later, and the single most common thing skipped at pilot scale.

Problem one: intake is a decision, not a receipt

Feedstock arrives as a truck of former foodstuffs, bakery waste, brewers spent grain, produce seconds, or whatever your supply agreements cover. Composition varies load to load. Moisture varies enormously, which changes both the substrate recipe and the effective dry matter you are actually buying. Somebody at the weighbridge has to decide whether this load is acceptable, at what moisture, against what specification, and that decision has to be recorded with evidence.

Generic ERP (Enterprise Resource Planning) receiving treats this as goods in against a purchase order. It has no concept of a conditional acceptance with a moisture adjusted quantity, a supplier declaration document that must be present and current, and an approval rule set that varies by material type. So plants bolt a spreadsheet onto the ERP, and the spreadsheet becomes the real record while the ERP holds a number that is wrong.

A build makes intake a first class workflow: weighbridge or platform scale reading, sampling with moisture and any quality checks recorded, the supplier declaration validated against expiry, an accept, conditionally accept, or reject decision with a reason, and a resulting feedstock lot with corrected dry matter quantity. That lot is what the substrate recipe consumes, and it is the anchor of the genealogy.

Problem two: substrate recipes change every week and nobody records the actual

The substrate blend is formulated from whatever is available, targeting a dry matter and nutrient profile the larvae perform on. Production staff adjust it constantly because the inputs move. The formulation sheet on the wall says one thing. What went into the mixer on Tuesday afternoon was something else, decided by a shift lead reading a moisture meter.

If the actual blend is not captured per mix, three things break at once. You cannot explain performance variation between crate cohorts, because the input variable you would test against is unrecorded. You cannot defend the feed safety position for a specific lot, because the theoretical recipe is not evidence. And you cannot cost the batch honestly, because feedstock costs differ per source and some sources pay you rather than the other way round.

The fix is unglamorous: every mix is a record consuming specific feedstock lots at actual weights, producing a substrate lot with a computed profile. Crates then consume substrate lots. Now the chain from truck to crate exists.

Problem three: crates move on a day count through zones, and there are too many to manage by hand

The rearing schedule is a conveyor of cohorts. Seed on day zero, feed on a schedule, move between climate zones on specific days, harvest at a target day or a target size. Every zone has a finite crate capacity and its own environmental setpoints. The operational question at any moment is which crates move today, which zones will be full tomorrow, and whether a delayed harvest cascades into a seeding backlog because the nursery has nowhere to put the next cohort.

This is a capacity constrained scheduling problem with a biological clock, and it is exactly the shape of thing a spreadsheet handles badly and a purpose built planner handles well. The system should know every cohort's position, project zone occupancy forward two weeks, and warn on the collision before it happens rather than after. Scanning matters here: crate identity has to be readable in a warm, humid, dusty environment, which usually means durable labels or trays with fixed identifiers and handheld or fixed readers at zone transitions rather than someone typing numbers.

The gain is not just tidiness. When a cohort underperforms, you can compare it against the environmental profile it actually experienced in each zone, at the crate level, instead of against a plant average that hides everything.

Problem four: the breeding colony is a separate business with its own genealogy

The nursery and breeding side runs on different logic to the rearing side. Adult cages, egg collection, hatch rates, neonate quality, and the genetic line all determine what the rearing floor gets to work with, and a bad week in breeding shows up in output three weeks later when nobody connects the two events.

Colony records need their own model: cage populations, egg lay by day, hatch performance, neonate batches with their parent cage lineage, and quality metrics. Then rearing cohorts reference the neonate batch they came from, and a yield anomaly can be traced upstream to the colony rather than blamed on substrate forever. Very few operations do this properly, and the ones that do learn faster than the ones that do not.

What a build must include

The genealogy spine: feedstock intake lot, substrate mix lot, neonate batch, crate cohort, harvest lot, processed lot for dried larvae, meal, oil, and frass. Every step is a consumption and production event, so the trace runs both directions in seconds. Frass matters commercially since it is a saleable fertiliser product with its own compliance path, and treating it as waste in the data model is a mistake you pay for later.

Around that: the intake workflow with supplier declarations and expiry chasing, substrate formulation with actual capture, a zone scheduler with capacity projection, environmental data ingested from the climate systems and stored against cohorts, scanning at every transition, quality results, and yield and conversion reporting per cohort with dry matter honesty rather than wet weight flattery. Then customer lot documentation, because your aquafeed and pet food buyers will ask for a specification and a lot history per delivery and you want that generated rather than assembled.

One narrow place automation earns its keep: reading supplier declarations and analysis certificates arriving as PDFs, extracting the material type, batch, and any composition statement, and flagging when a supplier's declaration changes or lapses. Nobody reads every one of those documents by hand, and that is precisely where an approval boundary quietly breaks.

Cost, timeline, and the things that move the number

A first release covering intake with approval rules, substrate mixing with actual capture, crate cohort tracking with zone scheduling, and end to end lot genealogy runs $70,000 to $150,000 over 12 to 18 weeks. A full platform adding colony management, environmental integration, quality management, frass and coproduct handling, customer lot documentation, and yield economics runs $180,000 to $450,000 phased across 6 to 12 months.

What increases the cost: automation integration, since a plant with automated crate handling and robotics needs the software to talk to a control layer rather than to people, and that is a different class of work. Multiple sites. Multi jurisdiction compliance documentation, because the European and North American evidence packs are not the same document with a different logo. What reduces it: one species, one site, and manual scanning in release one even if the plant is destined for automation later.

When not to build

At pilot scale with a few hundred crates, one substrate supplier, and a team of six, do not build. A disciplined spreadsheet with printed crate labels and a scanner app will hold the genealogy well enough, and the money belongs in the process. The mistake pilot operations make is not building too late, it is failing to record intake and substrate actuals at all, because that data cannot be recreated and it is what your first real audit and your first scale up decision both depend on.

Build when you are commissioning continuous production, when feedstock comes from more than a handful of suppliers on variable specifications, when you are selling into feed customers who audit, or when a single unapproved intake would force you to write off product because you cannot bound the contamination. That last test is the sharpest one. If you cannot draw the boundary, you are already paying for the system in risk.

How to choose a developer

Ask them to draw the genealogy on a whiteboard before you sign. The tell is whether they model intermediates properly. Substrate mix and neonate batch are both intermediates, and a developer who jumps straight from raw material to finished lot has built a warehouse system and will discover the hard part on your budget.

Ask how crate identity survives the environment. Warm, humid, and dusty destroys ordinary labels and confuses cheap scanners, and this is a physical design decision as much as a software one. Ask what happens when a crate is scanned into a zone that is full, because the answer reveals whether they have thought about the operator standing there with a trolley.

Ask what they have integrated on a plant floor, specifically, by system and protocol. Climate control and weighbridge integration are the two that always appear and both are more work than they look. Finally, agree code ownership in writing before kickoff: repository, cloud accounts, and the right to bring in anyone else. At Digital Heroes the client owns the code from the first commit, and in a plant where the software defines your compliance boundary that is not negotiable.