Aquaculture Software: Fixing the Biomass, Feed and Harvest Problems Off-the-Shelf Tools Leave Behind

Why aquaculture software makes or breaks a multi-site farm

Every number that matters on a fish farm is an estimate stacked on another estimate. You stocked 92,000 smolts into Pen 7 based on a counter reading you have never fully trusted. You have fed that pen for 14 months. Your mortality log is a mix of the diver's daily count, the mort pump tally and what the site manager remembers. Your biomass number, the one your bank covenant, your harvest schedule and your feed order all depend on, is that stack of estimates multiplied by a growth table someone copied out of a supplier's manual in 2019 and has adjusted by feel ever since.

The tools in the room are usually Mercatus Ocean Farmer or AquaManager or Fishtalk on the bigger salmon and seabass sites, an Excel workbook per site on everyone else, plus whatever came bundled with the feed barge: AKVA's Fishtalk Control, Steinsvik, Innovasea's Aquaculture Intelligence. Those systems are real and some are good. The problem is that they each own a slice, and no single one owns the pen. Feed volume lives in the barge software. Mortality lives in a paper sheet the diver photographs and WhatsApps to the office. Treatments live in a vet's PDF. Harvest weights come back from the processor three days later as a settlement file with different lot codes than your own. Somebody, usually your production manager, spends 10 to 14 hours a week rekeying all of it into a workbook so the Monday production call has a number. That is what we find when we audit these operations before a build.

Here is the scene that funds the build. A site manager reports Pen 12 at 4.1 kg average, 340 tonnes standing biomass. Harvest is planned around it: wellboat booked, processor slot confirmed, buyer contracted at a size grade. The fish come out at 3.6 kg. You are 45 tonnes short on a contracted grade, you pay for a wellboat day you did not need, and your buyer downgrades the lot. That single miss is worth more than the software. It happened because the feed conversion assumption in the spreadsheet was 1.15 and the pen had actually been running near 1.35 since a sea lice treatment in month nine knocked appetite down for three weeks, and nothing in the stack connected the treatment event to the growth model.

Problem: your biomass number is a guess dressed as a fact

The standard flow is stocking count, minus cumulative mortality, times an average weight from a monthly sample of 60 to 100 fish, cross-checked against a growth table. Every one of those inputs carries error, and the errors compound over a 14 to 22 month cycle. In the farms we have audited, a 3 percent stocking count error plus sampling bias toward the fish that swim into the net plus an FCR assumption that never updates gets you 8 to 12 percent off by harvest. On a 340 tonne pen that is 30 tonnes you either cannot sell or did not plan to have.

Ocean Farmer and AquaManager will hold all these inputs and give you a biomass figure. What they will not do is treat your farm's own history as the model. They ship a generic growth curve and let you override parameters by hand. They cannot tell you that at your site, at 9 to 11 degrees, after a hydrogen peroxide treatment, your fish lose roughly 11 days of growth and your effective FCR runs 0.18 higher for the following three weeks, because that pattern only exists in your data and their model has no place to learn it.

A custom build inverts this. The pen is the primary object, and every event that touched it is written to one immutable timeline: stocking with counter reading and source hatchery, every feed event with product, batch and mass, every mortality with cause code, every treatment, every grade, every sample with individual fish weights rather than just the average, every environmental reading from your loggers. Then you fit the growth model to your own harvest outcomes. The machine learning that pays for itself here is unglamorous: a regression trained on your last 40 to 60 harvested pens, taking temperature, feed history, treatment events, stocking origin and sample data as inputs, predicting harvest weight and standing biomass with a confidence band. The band matters more than the point estimate. A model that says "342 tonnes, 90 percent confidence 318 to 361" changes how you book a wellboat. We have seen this narrow the harvest weight miss from the 8 to 12 percent range down toward 3 to 5 percent within two cycles, purely because the model is fed the farm's own reality instead of a supplier's brochure curve.

Problem: feed is your biggest cost line and you cannot attribute it to a pen

The barge system knows it blew 1,840 kg out of a hose today. It does not reliably know how much of that reached Pen 7 rather than the seabed, and it definitely does not know that the feeder overshot for 40 minutes because a camera operator was covering two screens. The office knows what you bought from Skretting or BioMar per delivery. Between those two facts is a gap that quietly costs money: on a 5,000 tonne producer, a 0.1 swing in FCR is roughly 500 extra tonnes of feed, which at whatever your delivered cost per tonne is lands as a six-figure line you never budgeted.

Off-the-shelf farm management tools import the barge's daily feed totals and stop there. They accept the barge's number as truth and post it to the pen. They cannot reconcile it against silo levels, delivery weights and physical stock counts, because they were never given the warehouse side of the problem. So your biological FCR and your economic FCR drift apart over a cycle and nobody notices until the annual feed reconciliation shows 190 tonnes unaccounted for.

What a custom build does: ingest the barge telemetry directly, via the AKVA or Steinsvik API where one exists, or a nightly file drop or OPC UA tap where it does not, at the feeding-event level rather than the daily-summary level. Every event carries pen, silo, product batch, start and stop time, mass. Separately, ingest the delivery side: feed purchase orders, weighbridge tickets, silo level sensors. Then run a continuous three-way reconciliation of purchased versus stored versus fed, per silo, per product batch, with a variance alert when the daily gap exceeds a threshold you set, say 2 percent. Now your feed manager sees the discrepancy the week it starts, not at year end. Layer on pellet-loss detection from the underwater camera feed if you already have cameras, and the same event stream tells you which pens are being overfed at which tide states. This is the single highest-return integration in the category and it is the one buyers most often postpone.

Problem: mortality and health data lives on paper until it is too late to act

The diver counts morts, writes them on a wet sheet, photographs it, sends it to the site office. Somebody types it in that evening or the next morning or Friday. Cause codes are freeform text: "mort", "loss", "runt", "unknown", "lice?". By the time the pattern is visible in a spreadsheet, three days of elevated mortality have passed and the vet is now dealing with a treatment rather than a prevention.

The generic tools have mortality fields. They do not have your cause taxonomy, they do not enforce it, and they will not run detection on it. AquaManager will let a diver type "unknown" 400 times, and it will happily average across pens so a spike in one unit disappears into a site-level number that looks fine.

A custom build starts with an offline-first mobile app the diver actually uses at the pen edge with wet hands and no signal: big tap targets, a fixed cause taxonomy you defined with your vet, photo capture, queued sync when the boat gets back in range. Then anomaly detection on the stream: a per-pen baseline mortality rate, an alert when today's count exceeds the rolling baseline by a defined multiple, routed to the site manager and the vet within the hour rather than the week. AI does two useful things here. First, image classification on mort photos to suggest a cause code, which does not replace the vet but does stop the "unknown" pile from growing. Second, document extraction on vet reports, lice count sheets and lab results: those PDFs arrive as unstructured text, and a language model pulling structured fields out of them and attaching them to the correct pen timeline saves your health coordinator most of a day each week and, more importantly, makes those events available to the growth model.

Problem: harvest reconciliation is a fight you lose three days late

You harvest Pen 12 on Tuesday. The wellboat takes it. The processor grades and settles on Friday and sends a file: kilos by grade, downgrades, condemnations. Their lot codes are not your pen numbers. Your production manager builds a mapping in Excel, discovers a 4 percent yield gap, and by then nobody remembers whether the fish were held 18 hours or 30, whether the grader was recalibrated, or which pen the last 12 tonnes actually came from because two pens were merged in the wellboat.

No off-the-shelf farm tool solves this, because it requires speaking to your specific processor's settlement format and your specific wellboat's manifest, and no vendor will build that for one customer. This is the clearest build-only problem in the category.

A custom build maintains lot identity end to end: pen to cage-side crowd to wellboat compartment to processor batch, with your codes carried through and the processor's codes mapped on ingest. It parses the settlement file automatically, whether that is EDI, a CSV drop or a PDF that needs extraction, and posts actual yield against predicted biomass per pen, same day. It flags variance over your threshold and holds the full event context alongside it: transport duration, water temperature during transit, days since last treatment, feed cessation timing. After 20 harvests you stop arguing about individual gaps and start seeing which conditions cause them. One producer we worked with found their downgrade rate correlated with wellboat hold time over 22 hours far more than with anything happening on the farm, which is not a conclusion any spreadsheet was ever going to surface.

Problem: compliance reporting eats a week a month and is duplicated everywhere

Depending on your waters you are filing biomass declarations to the regulator, sea lice counts on a fixed schedule, medicine and treatment records, escape reporting, and whatever your certification body wants: ASC, BAP, GlobalG.A.P., Global Seafood Alliance. Each wants a different cut of the same underlying events, in a different format, on a different cadence. Most farms have somebody rebuilding those exports by hand from the same workbook, every single month.

The generic platforms cover one or two of the common regimes for their home market and leave the rest to you. If you farm in more than one jurisdiction, which most multi-site operators eventually do, you are back in Excel for at least half of it.

A custom build treats the pen event timeline as the single source and compliance exports as views over it. Once mortality, treatment, feed and lice data are captured properly and once, every report is a query plus a formatter. Add an audit trail so every record shows who entered it, when, from which device, and whether it was later amended and by whom, because that is what an ASC auditor asks for and what a spreadsheet can never produce. Budget real time for this: the formats are fussy, the regulators change them, and getting it wrong is a finding on your certificate. But it is a one-time build against a data model you already needed, not a separate system.

What this costs and how long it takes

These numbers come from our own delivery history, not from a market survey. A focused first release, the pen and lot data model, feed event ingestion from one barge system, mortality mobile capture, the biomass model fitted to your history, and a production dashboard, typically runs $60,000 to $130,000 and ships in 12 to 16 weeks. A full platform, adding multi-site rollups, treatment and health records, compliance exports for two or more regimes, processor settlement integration, environmental sensor ingestion and a proper permissions model, runs $150,000 to $400,000 phased over 6 to 12 months.

What pushes you up the band in aquaculture specifically. First, the number of distinct equipment vendors you need to talk to: one barge system is a known quantity, three different generations of AKVA plus a Steinsvik site plus a legacy system with no API is where integration cost triples, because the last one means file scraping and reverse engineering. Second, offline requirements: an app that must work with zero connectivity for eight hours and sync cleanly, including conflict resolution when two people edited the same pen, is roughly 40 percent more work than an online-only one, and you cannot skip it. Third, the biomass model itself: if you have five years of clean harvest outcomes it is weeks of work, and if your history is 40 inconsistent spreadsheets it is a data archaeology project before any modeling starts, easily $20,000 to $40,000 on its own. Fourth, multi-jurisdiction compliance: each additional regulatory regime is real weeks, not a config toggle. Fifth, land-based RAS: if you are running recirculating systems, the sensor density and the control system integration are a different scale of problem than net pens, and we would not quote the same band.

Build versus buy: where the line actually sits

Buy, and mean it. If you run one site with under 10 to 15 pens or ponds, Ocean Farmer or AquaManager or their equivalent will do the job for a fraction of a build, and your site manager's head is still a better model than any software you could commission. If you are a single-species producer in one jurisdiction with one feed vendor and one processor you have used for a decade, the off-the-shelf tool fits because your operation looks like the operation it was designed for. Buy it, use it properly, and revisit in three years.

Build when three or more of these are true. You run multiple sites and your Monday number is assembled by a human from more than two systems. Your harvest weight misses your prediction by more than 5 percent with any regularity and you cannot explain why. Your feed reconciliation gap is above 2 percent annually 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 the decisive one: your commercial team is making forward sales commitments against a biomass number that your own production manager privately does not believe.

Our position, having built these: most operators wait about 18 months too long. They wait because the spreadsheet works, right up until a $200,000 harvest miss makes it obvious it did not. The threshold is not size, it is whether the number that drives your money decisions can be traced to its inputs. If it cannot, you are already paying for the software you have not built.

How to choose a developer for aquaculture software

Ask them to model a pen on a whiteboard before you sign anything. If they draw a table with a biomass column, walk. The correct answer is an event-sourced timeline where biomass is a derived value with a timestamp and a confidence, because a pen's history is a sequence of events and any system that stores the answer rather than the inputs cannot recompute when your model improves, which it will. This single question separates people who have done it from people who read about it.

Ask what happens when the barge API goes down for six days. The right answer involves a local buffer, idempotent replay and a reconciliation pass, not "we'll get an alert." Marine integrations fail constantly: salt, power, weather, boats hitting things. Anyone who has shipped in this category will have a specific war story about a feed data gap and how they closed it. Anyone who has not will describe a happy path.

Ask them to name the compliance regimes and certification schemes you are subject to, unprompted. If they cannot distinguish ASC from BAP, or do not know what a biomass declaration is in your jurisdiction, you will be paying them to learn on your budget and you will still get the export format wrong on the first two attempts.

Get code ownership and data portability in writing, in the contract, before the first sprint. You own the repository, you own the database, you can export the full pen history to a documented format at any time, and there is no per-pen or per-tonne licence sitting on top of software you paid to build. Farms get trapped here more than any other industry we work in, usually because the vendor who wrote it is also the vendor who sells the feed barge.