Insect Protein Farming Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does crate tracking quietly become a whole plant platform?

The scope that gets approved is almost always narrow and sensible: track crates through the rearing floor so we know where every cohort is. Within a few weeks it has absorbed intake, substrate mixing, the nursery, the dryer and the press, because each of those turns out to be a prerequisite for the one before it. You cannot report cohort performance without knowing what substrate the cohort ate. You cannot record substrate without recording the feedstock lots it consumed. You cannot trust the intake quantity without moisture adjustment. The scope did not creep, it was always this size and the brief was drawn too small.

This is specific to insect protein because the unit of production is a physical container moving through space on a biological clock, and the input is a variable waste stream. There is no clean boundary between the rearing module and everything upstream of it, in the way there is between, say, a warehouse module and a payroll module.

The fix is to draw the genealogy spine before you scope anything. Feedstock intake lot, substrate mix lot, neonate batch, crate cohort, harvest lot, then processed lots for dried larvae, meal, oil and frass. Agree that spine on a whiteboard, then decide which parts of it get a screen in release one and which get a paper form feeding the same data model. Every operation should be a consumption and production event against the spine from day one, even where the interface is crude. Retrofitting an intermediate into a live genealogy is far more expensive than building a plain screen for it now.

What goes wrong when you move pilot spreadsheets into a real genealogy?

Pilot data almost never survives the transition, and the reason is not sloppiness. A pilot records what it needs to run the pilot: crate numbers, seeding dates, harvest weights. It does not usually record which specific intake lots went into which mix, at what actual weight, because at pilot scale the person doing the mixing knows.

So the migration hits a wall. You have historic cohort performance but no defensible input variable to explain it, and you have finished product records with no path back to a truck. Teams then do one of two damaging things. They invent the link, mapping cohorts to the intakes that were open that week, which produces a genealogy that looks complete and is not evidence. Or they load the history flat with no genealogy, which is honest but means the first year of your new system contains a silent boundary where traces stop working.

The honest fix is the second option done deliberately. Load history as reference data with an explicit provenance flag saying this record predates full genealogy, so a trace query returns a clear stop rather than a false answer. Then set the go live date as the start of your defensible chain and tell your customers and auditors that plainly. The related fix costs nothing and should start today, whatever your software timeline: record intake decisions and actual substrate composition on paper now. That data cannot be recreated, and it is what your first customer audit and your first scale up decision will both need.

Why do climate control and weighbridge integrations break after launch?

These two integrations appear in every insect plant build and both are consistently underestimated. Climate systems frequently expose data through file exports or a local historian database rather than a modern interface, and they were commissioned by a controls contractor whose priority was the control loop, not the data contract. Weighbridge and platform scale integration involves hardware protocols that vary by manufacturer and sometimes by installation.

They break after launch in predictable ways. A controls contractor services the climate system and the export path changes or stops. A scale is replaced and the new head speaks a different protocol. A zone is renamed during a plant change and the environmental data starts attaching to the wrong cohorts, which is the dangerous one because nothing fails, it just quietly ruins your ability to explain performance variation.

The fix has three parts. First, monitor freshness on every feed and alert when data stops arriving, because a silent gap in environmental history is discovered months later when somebody asks why a cohort underperformed. Second, treat zone and asset identity as reference data with history, so a renamed zone maps to its old identity rather than orphaning a month of readings. Third, put the controls contractor in the room during design and get the export contract in writing, including what happens at their next service visit. This is a relationship problem as much as an engineering one.

What happens when feedstock approval evidence is not covered?

This is the gap that turns a software problem into a commercial one. Your product has value because it is an approved feed ingredient, and that approval is conditional on what the insects were fed. Permitted substrate lists differ by jurisdiction and they change, so the specifics belong with your regulatory adviser, but the operational consequence never changes: intake is the compliance boundary of the entire plant.

What goes wrong is that intake is built as receiving. Generic receiving records a delivery against a purchase order. It has no concept of a conditional acceptance at a moisture adjusted quantity, a supplier declaration that must be present and in date, or an approval rule set that differs by material type. So the plant bolts a spreadsheet onto the system, the spreadsheet becomes the real record, and the system holds a number that is wrong.

The second failure is documents nobody reads. Supplier declarations and analysis certificates arrive as PDFs, they expire, suppliers change them, and no human reads every one. That is precisely where an approval boundary breaks without anyone noticing.

The fix is to make intake a first class decision. A scale reading, sampling with moisture and quality checks recorded, the supplier declaration validated against its expiry, and an explicit accept, conditionally accept or reject outcome with a documented reason, producing a feedstock lot at corrected dry matter. Hold the approval rules as configuration so a rule change is a data update rather than a development project. Then add document extraction on the incoming declarations to flag material type changes and lapsed dates, which is the one place automation earns its keep here without any judgement being delegated to it.

Should you build custom or configure what you already own?

Some readers should not build, and this is the section where that gets said plainly. At pilot scale, a few hundred crates, one substrate supplier and a team of six, do not build software. Printed crate labels, a scanner app and a disciplined spreadsheet 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 decisions and substrate actuals at all.

If you already run a manufacturing system such as Odoo or Microsoft Dynamics 365 Business Central, configure what it does well and stop there for as long as you can. Purchasing, supplier records, finished goods inventory, sales orders and financials are genuinely covered, and replacing them buys you nothing. The reason these systems do not carry the whole plant is structural rather than a shortcoming: they model a work order consuming inventory against a bill of materials, and a crate on a biological day count consuming a substrate blend that changes weekly is not that shape. Check it yourself before deciding, by trying to record one conditional intake at a moisture adjusted quantity with an attached declaration.

Build when you are commissioning continuous production, when feedstock comes from more than a handful of suppliers on variable specifications, when you sell 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. If you cannot draw the boundary, you are already paying for the system in risk.

How do hidden costs get into the quote?

• Automation and controls. A plant with automated crate handling needs the software to talk to a control layer rather than to people. That is a different class of work and it is frequently quoted as if it were a screen.
• Crate identity in the real environment. Warm, humid and dusty conditions destroy ordinary labels and confuse cheap scanners. Durable labels or fixed tray identifiers plus the right readers is a hardware line, and it is often left out of both sides.
• Multi jurisdiction evidence. The European and North American documentation packs are not the same document with a different logo. If you sell into both, say so during scoping.
• Frass as a product. Modelled as waste in release one and then retrofitted as a saleable coproduct with its own lots and customer documentation, which is far more work than including it from the start.
• Historic data. Loading pilot records with honest provenance flags is quick. Trying to reconstruct a genealogy that was never recorded is not, and it should not be attempted.

The fix is a short paid discovery on real material. Give the developer one week of real intake paperwork, one mixing sheet, and a walk of the rearing floor, and ask for a scope written against what they saw. The questions they ask on the floor are the signal.

What separates a build that works from one that fails here?

Successful plant builds have one thing in common: they model the intermediates. Substrate mix and neonate batch are both intermediates, and a system that jumps straight from raw material to finished lot has been designed as a warehouse system and will discover the hard part on your budget. Ask any developer to draw the genealogy on a whiteboard before you sign, and watch whether those two objects appear unprompted.

The second habit is capturing actuals rather than theoreticals. The formulation sheet on the wall says one thing, the mixer got something else, decided by a shift lead reading a moisture meter. If the actual blend is not recorded per mix at real weights, you cannot explain cohort variation, cannot defend a lot, and cannot cost a batch honestly, since some feedstock sources pay you rather than the reverse.

The third is designing for the operator standing there with a trolley. Ask what happens when a crate is scanned into a zone that is full at the end of a shift. If the answer is an error message, the floor will route around the system within a fortnight and your genealogy will develop holes.

Finally, settle 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. In a plant where the software defines your feedstock approval boundary and produces the evidence a customer audits, being unable to modify your own system is a compliance exposure rather than a commercial inconvenience.