Hatchery software: four tests to run in a demo

Hatchery software is usually evaluated with the same checklist as grow-out software, and that is why the wrong product gets bought. A grow-out cycle is one population sitting in one pond for months. A hatchery week is the opposite: populations that outgrow their unit constantly, get split, get graded, get merged, and change size class faster than any record built for grow-out can follow.

The features that matter in a hatchery are not the ones at the top of most feature lists. For what a platform shaped around a hatchery covers end to end, see aquaculture hatchery management software; the rest of this post is the tests. A shrimp larval lab runs the same problem at a faster tempo, with every tank reused many times a year.

Splitting is the workload, not an edge case

The single most frequent operation on a hatchery floor is moving part of a population into another unit because density has climbed. Ask any hatchery manager what they did last week and splitting will be in the answer several times.

Most production software models a batch as belonging to one growing unit. That model is fine for a grow-out pond and structurally wrong for a hatchery. When you split, the system either forces you to close the batch and create two new ones, losing the continuity, or it updates one side and leaves the other stale.

What you need instead is a model that separates the population from the place it sits, so a batch can be in several units at once with its own count and weight in each. That is what production tracking means in a hatchery context, and it is the difference between a stock figure you trust on Friday and one you gave up on by Tuesday.

Test in the demo: ask for a live three-way split with a residual left in the source, then check the count and biomass on all three units. Do not accept a description of the feature. Watch the numbers.

Grading has to reconcile

A grading day pushes tens of thousands of animals through a machine over a few hours, pulls from several units, and places the resulting size classes somewhere different. It is the highest-risk event in the record because everything moves at once and nothing is where it was.

The property that matters is reconciliation: what came out has to be checked against what went in before the session is allowed to close. A system that quietly balances itself is a system that has absorbed the discrepancy into your inventory, and you will find out about it a month later when a pond does not hold what it says it holds.

Sorting and grading as a tracked session, with the fish held by the session while they are in the machine, is the honest representation of what actually happens on a grading day.

Test in the demo: grade from two units into three size classes, then ask what happens if the totals do not match. If the answer is that nothing happens, that is your answer.

Broodstock belongs in the record

If the hatchery produces its own stock, the production record should start at the group that spawned, not at the nursery tank. That means broodstock held as durable named groups, spawning events recorded against them, hatch results that create ordinary batches, and failed spawns kept rather than deleted.

Failures matter more than they look. Reproductive performance for a group is only assessable when the attempts that produced nothing are in the record alongside the ones that worked. A hatchery that deletes failed spawns will end up with a very flattering and completely useless view of which group performs.

Once the hatch creates a batch, everything downstream should treat it identically to purchased stock. See broodstock and spawning for how that chain works when it is unbroken.

Test in the demo: record a failed spawn, then ask to see the performance history for that broodstock group.

Configuration, not assumptions

Hatcheries run several species, several varieties or strains of each, and stage names that are specific to the operation. Software that ships with hardcoded phases, a fixed species list, or one feeding table is going to be fought rather than used.

What to look for:

• Species and varieties defined by you, carried on every batch and broodstock group
• Cultivation phases defined by you, each with its own feeding frequency
• Growing unit types with their own defaults, so a 20-litre incubator is not described with the same assumptions as a hectare pond
• A feed table keyed to your species and weight bands, not a generic curve

Test in the demo: add a species, a variety, and a cultivation phase yourself during the session. If that requires a support ticket, every future change will too.

The report someone outside the hatchery will read

At some point a buyer, an auditor, an insurer, or an owner asks for a document. Not a dashboard, a document: a period, a unit, the stock at both ends, what was fed, what died, what the water was doing, and a timeline of events.

If producing that costs a day of merging files, it will be produced under duress and rarely. If it is a page load, it gets produced weekly and starts informing decisions. See reporting and traceability for what that looks like when it comes off the live record.

Test in the demo: ask for a report on one unit for last quarter, printed as PDF and exported to Excel.

What this rules out

Applying these four tests tends to eliminate two of the three product categories on the market quickly. Sensor platforms have no production model at all, so splitting and grading are not applicable. General farm ERPs handle purchasing and inventory well but were built for crops, where a field does not split into two fields. The remaining candidates are aquaculture production platforms, and among those the differences are exactly the ones above.

The full framework, including the questions that apply to any vendor, is in the buyer guide. For how one platform reads across a whole hatchery cycle rather than one test at a time, see aquaculture hatchery management software. If you want to run these four tests against AquaOS specifically, bring a real scenario from your own operation to a demo.