Aquaculture Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the pen get scoped as a table with a biomass column so often?

Because that is what the spreadsheet looks like, and the spreadsheet is what everyone hands the developer. One row per pen, columns for stocking count, cumulative mortality, average weight and standing biomass. It is legible, it matches how the Monday call runs, and it is the wrong shape.

Biomass is not an attribute of a pen. It is a conclusion drawn from a sequence: a stocking event with a counter reading and a source hatchery, every feed event with product, batch and mass, every mortality with a cause code, every treatment, every grade, every sample with individual fish weights rather than only the average, and every environmental reading. Store the conclusion and you have thrown away the working. When your growth model improves, and it will, you cannot apply it backwards. When a harvest misses, you cannot decompose the miss. When an auditor asks how a figure was reached, you have a number and a story.

The model that works is an immutable event timeline per pen, with biomass computed on demand and stamped with the model version and a confidence band. That last part changes behaviour more than anything else in the build. A single figure invites a commitment. A figure with a range invites a question about how much of the load you should sell forward. Ask any developer to draw the pen on a whiteboard before you sign. If they draw a table with a biomass column, they will build you a faster spreadsheet.

What goes wrong when you migrate five years of spreadsheets?

Your history is the most valuable input you own, because it is what makes a growth model yours rather than a supplier's brochure curve. It is also inconsistent in ways nobody has documented.

Pen naming drifts. Cause codes were invented by whoever was on site that year, so mortality reasons include the same condition spelled four ways plus a large pile of unknown. Units change between sites and sometimes between tabs. Sampling method changed when a new site manager arrived. Merged pens appear as a single row with no record of the merge. Each of these is individually trivial and collectively they mean the data cannot be loaded as it stands.

Treat normalisation as its own scoped piece of work with its own budget, not as a task inside week one of the build. In our experience this is genuine effort where spreadsheets span several years and sites, and pretending otherwise is how projects lose their first month. Data already sitting in a proper farm management system migrates far faster, which is worth knowing if you are choosing between extending what you have and starting fresh.

Why do barge and sensor integrations break after launch?

Marine integrations fail constantly and for physical reasons: salt, power, weather, and boats hitting things. Any design assuming a reliable feed will produce a system with holes in it inside the first month.

The specific failure is not the outage, it is what happens afterwards. A feed barge is offline for six days, comes back, and pushes six days of history at once. A system that appends whatever arrives will double count what it already had. A system that ignores late data will carry a hole through every downstream calculation forever. What you need is idempotent ingestion, meaning the same feeding event can arrive five times and be recorded once, plus a reconciliation pass that recomputes derived values for the affected period rather than leaving them stale. Ask any prospective developer what happens when the barge is down for six days. If the answer is that you will get an alert, they have described monitoring rather than recovery.

The third is vendor variety. One barge system is a known quantity. Three generations across sites, including one with no interface at all, is where integration cost multiplies, because the last one means file handling and reverse engineering rather than an interface. That system should be priced separately and honestly, and if nobody will look at it before quoting, the quote is a guess.

What happens when compliance records and audit trails are not covered?

Compliance is usually scoped as exports, and exports are the easy half. The hard half is that the underlying record has to be capable of supporting a certification audit, and that is a property of how data was captured rather than how it is formatted on the way out.

Depending on your waters you are filing biomass declarations, sea lice counts on a fixed schedule, medicine and treatment records and escape reporting, and your certification body wants its own cut of the same events. What an auditor asks is not for a report. It is who entered this record, when, from which device, and whether it was later amended and by whom. A system that lets a site manager correct last month's mortality figure without leaving a trace cannot answer that, and the finding lands on your certificate rather than on your software.

Build the audit trail into capture from the start: every record carries its author, device, timestamp and amendment history, and amendments are new entries rather than overwrites. Treatment records deserve particular care because they connect to withdrawal periods and therefore to harvest eligibility, and a treatment recorded against the wrong pen is a food safety issue rather than a data quality issue. The second uncovered gap is jurisdiction. Each regulatory regime is real development weeks rather than a configuration toggle, and the formats change. Scope them by name, because a single compliance line item means a single regime.

Should you build custom or configure what you already own?

Buy, and mean it, if your operation looks like the operation these products were designed for. One site with fewer than about fifteen pens or ponds, one species, one feed vendor, one processor and one jurisdiction is exactly the shape Mercatus Ocean Farmer or AquaManager fits, and at that scale your site manager's head is still a better model than anything you could commission. Use the tool properly and revisit in three years.

Build when three or more of these are true. You run multiple sites and the Monday number is assembled by a human from more than two systems. Your harvest weight misses your prediction by more than about five percent with any regularity and you cannot explain why. Your annual feed reconciliation gap is above a couple of percent and nobody can point at the cause. You farm in more than one regulatory jurisdiction. You have equipment from more than one vendor generation and the newer software will not read the older barge. Or your commercial team is committing forward sales against a biomass number your own production manager privately does not believe.

How do hidden costs get into an aquaculture software quote?

Data archaeology is the first and most consistently missing. If your history is inconsistent spreadsheets across sites and years, normalising it is a real piece of work with its own price, and a quote that folds it into discovery is a quote that will move. Ask for it as a separate line with a separate estimate, and ask what happens if the data turns out worse than the sample suggested.

Offline capability is the second. An app that must work with no connectivity for a full shift and then sync cleanly, including resolving the case where two people edited the same pen, is meaningfully more work than an online one. It is also not optional, so any quote that appears cheap on the mobile side is either assuming connectivity you do not have or has not thought about conflict resolution.

The third is the legacy barge with no interface, which should be priced after somebody has looked at it. Fourth, each additional regulatory regime. Fifth, land based recirculating systems, where sensor density and control system integration are a different scale of problem from net pens and should not be quoted against the same band. Sixth, your own staff time, because agreeing a cause taxonomy with your vet, deciding sampling protocol and validating the normalised history are your people's hours, they are on the critical path, and they appear in nobody's proposal.

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

The successful projects start with capture and reconciliation, and add modelling once the inputs are trustworthy. The failed ones start with the model, because the model is the exciting part, and produce confident predictions from mortality data that a diver still writes on a wet sheet.

Third, close the feed loop early. Three way reconciliation of purchased against stored against fed, per silo and per product batch, with a variance alert at a threshold you set, is the highest return piece in the category and the one most often postponed. Feed is your largest cost line and a swing of a tenth in feed conversion on a five thousand tonne producer is five hundred tonnes of feed, which is worth seeing in the week it starts rather than at year end.

Fourth, keep the harvest loop honest. Carry your lot identity from pen through wellboat compartment to processor batch, ingest the settlement file automatically, and post actual yield against predicted biomass the same day with the surrounding context attached, meaning transport duration, temperature and days since treatment. After twenty harvests you stop arguing about individual gaps and start seeing which conditions cause them.

Finally, get code ownership and data portability in the contract before the first sprint: the repository, the database, and a documented export of your full pen history at any time, with no per pen or per tonne licence sitting on software you paid to build. Farms get trapped here more than most industries, usually because the developer is connected to the equipment vendor. At Digital Heroes the client owns it from the first commit.