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

Why does the plant get scoped as products and orders so often?

Because that is what most business software looks like, and because the purchase order and the sales order are the two documents everybody in the building already recognises. A developer arriving from ecommerce or general manufacturing will draw products, orders and inventory, and it will look reasonable on a whiteboard.

It is the wrong spine. A seafood plant runs on lot genealogy. A landing record carries vessel, trip, species, gear, area, grade and the catch documentation as evidence. That landing becomes one or more raw lots. Production orders consume raw lots and emit output lots at each conversion step with actual weighed quantities, so yield is derived rather than typed. Pack, freeze, glaze, case and palletise each create their own lot links, and cold storage is tracked by pallet so a recall produces a location list rather than a guess.

The reliable test is byproduct. Ask a prospective developer how frames, collars, roe and meal stock are handled. If they have done this work they will raise it themselves, because byproduct is where a naive model loses mass and the yield numbers stop balancing. Once yield does not balance nobody trusts any figure, which is how a plant ends up with an expensive system and a supervisor still keeping the real numbers in a notebook.

The second test is the direction of trace. Ask them to walk both ways: from a pallet in the freezer back to a vessel and a trip, and from a trip forward to every pallet that came from it. A model built on products and orders can usually do neither in less than a day.

What goes wrong when you migrate landing records, yield standards and vessel agreements?

The uncomfortable answer is that most plants discover their yield standards were never written down.

They exist as what the fillet line supervisor knows. Ask three people what the expected fillet yield is on a given grade of cod and you will get three numbers, all defended confidently. That is not a data problem you can fix during a migration, it is a decision the plant has to make, and it needs a named person and a couple of weeks. Budget for it, because the system cannot flag a variance until somebody agrees what normal is.

The second migration problem is the landing history itself, which lives on wet clipboards, in a receiving spreadsheet with inconsistent vessel naming, and in the memory of the person who runs the dock. Species names are a specific hazard, because the same fish has several acceptable market names and different people used different ones across years. Loading that as it stands produces a history in which one species appears as three, and every yield comparison built on it is meaningless.

The third is vessel agreements. Grade pricing, trip advances, ice, fuel and other deductions differ per captain, and some of those arrangements exist as a handshake plus a paper document nobody has read since it was signed. Turning them into configurable settlement rules is real work involving the general manager rather than the developer, and it is on the critical path because settlement cannot be tested against rules that do not exist yet.

Scope all three as budgeted work. The honest test is to take the last twelve months of landings, list the distinct vessel and species names, and count how many are duplicates of the same thing.

Why do scale, grader and dock integrations break after launch?

Because the receiving dock is a hostile environment and the software is usually designed somewhere dry.

Docks are wet, full of metal, and badly covered by wireless. A landing does not pause because an access point rebooted, and a supervisor who loses one tote record goes back to the clipboard permanently. Offline capture with queued sync is a hard requirement rather than a nice addition, and it has to survive the device being closed, the tablet restarting and two people recording against the same landing before either syncs. Ask any developer what happens when the dock loses connectivity for six hours. If the answer is that an alert appears, they have described monitoring rather than recovery.

Scales and graders break differently. Each manufacturer has its own protocol and its own quirks, and older equipment on a plant floor rarely has documentation anyone can find. Integration should be quoted per named device and manufacturer, not as a general capability, and somebody should look at the oldest scale before pricing. The failure after launch is usually drift rather than disconnection: a scale is recalibrated, a grader configuration is changed during a maintenance window, or a device is replaced with a different model, and nothing in the software notices that the numbers moved.

The design that survives compares incoming device readings against expectation and flags a change in pattern rather than trusting whatever arrives. It also keeps manual entry available with a clear marker, because a plant that cannot record a landing when a scale fails will use paper and type it in later, which is the situation you were trying to leave.

What happens when species identity and certification separation are not covered?

This is the failure that ends careers, and most of it is not fraud.

It is a lot of pollock and a lot of cod that got mixed during a changeover on a shared line, or a market name typed by someone who used the wrong one of several acceptable names for the same fish. The FDA publishes acceptable market names and NOAA runs the Seafood Import Monitoring Program, which requires catch documentation for a defined list of imported species. Your buyer wants a chain of custody claim they can defend, and if you hold Marine Stewardship Council certification, certified and non certified material must be provably separated at every step.

The software failure is treating certification as a checkbox on the item. A checkbox cannot express a sequencing constraint, and sequencing is the actual control. If certified material is scheduled after uncertified material on the same fillet line, the schedule has to block or force a signed cleandown task, and that record has to be attached to the run. A claim you can only defend by asking the line lead what they remember is not a claim.

The second uncovered gap is document expiry. Catch certificates, health certificates and supplier declarations arrive as scans in dozens of layouts, and the failure is not filing them, it is discovering a missing or expired document after a container has shipped. The vault has to chase what is missing before the shipment rather than record what was collected afterwards. This is also the one place where machine learning genuinely earns its cost in a plant: extracting species, area, vessel and dates from a scan and flagging mismatches against the purchase order is a narrow job with a measurable hit rate.

Should you build custom or configure what you already own?

Do not build if you are a cold pack operation buying already graded frozen blocks and repacking them. Your traceability is a purchase order and a case label, and a well kept spreadsheet plus a decent inventory tool is honestly enough. The money belongs in a plate freezer.

Do not rebuild what Marel Innova already does. It is a serious piece of software and it is very good at grading, batching, portioning and line level capture, particularly tightly coupled to Marel equipment. If your real pain is line performance and you run a Marel floor, it earns its money and duplicating it is expensive vanity. What it does not do is the commercial half of the business: vessel settlement with grade pricing and trip deductions, catch and health certificate management, import monitoring records, or margin on a customer programme after freight and cold storage. Most processors keep Innova on the floor and build the commercial layer around it rather than replacing it.

Aptean Food and Beverage ERP (Enterprise Resource Planning) is a credible spine for general food manufacturing and handles catch weight and lot traceability. The gap is that everything seafood specific sits outside its model, so gear and area coding, catch documentation, measured glaze pickup, species changeover rules and fisherman settlement end up as customisations or as the spreadsheets it was meant to replace.

Build when two or more are true: you buy from more than about eight vessels on a settlement formula, you carry a certification claim your customers audit, you run multiple species on shared lines, you handle glazed frozen product where net weight declarations matter, or you have ever spent more than a day answering a single trace question.

How do hidden costs get into the quote?

Scale, grader and portioner integration is the first and the largest. It is real floor work with real hardware protocols in a wet environment, and quoting it as one integration line means somebody has priced one device. Get a line per named manufacturer and model, and insist the oldest equipment is inspected before the number is fixed.

Multiple plants with inter plant transfers is the second. A transfer lot doubles the traceability model, because material leaving one plant's genealogy and entering another's has to keep its identity across the boundary, and that is a design decision rather than a data entry screen.

Third is every new EDI trading partner, measured in weeks each. One grocery buyer's electronic data interchange requirements do not transfer to the next.

Fourth is multi country regulatory documentation, since an EU health certificate and a United States import filing are different problems with different formats and failure modes. Fifth is offline capability on the dock, which is meaningfully more work than an online application once you include conflict resolution between two people recording the same landing. Sixth is your own staff time, because agreeing yield standards, writing vessel agreements down as rules and validating the first month of parallel running are your people's hours, on the critical path, and in nobody's proposal.

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

The builds that work make glaze a measured event rather than a constant. Most plants type a per SKU glaze percentage into a spreadsheet once and never revisit it, while actual pickup drifts with water temperature, dwell time and how the operator set the dip that morning. Sample weights before and after glazing feed a running actual by SKU and by shift, the system flags drift beyond about a point off standard, and the declared net weight on the carton comes from the measured figure. Get it wrong optimistically and you have a mislabelled net weight, which is a regulatory exposure. Get it wrong cautiously and you give away product on every pallet, quietly, forever.

They report yield by vessel, by trip, by grade, by species, by line and by shift rather than in aggregate at month end. Two boats delivering the same species at the same grade and the same price can yield differently through the fillet line because of how the crew bled and iced the fish at sea. Aggregate monthly yield averages the good boat and the bad boat into one meaningless number, and the moment a plant manager can see the split, purchasing changes within a month and so does the conversation with the captain.

They cut over in parallel, never cold. Run receiving and lot capture alongside the existing clipboard and spreadsheet for two to three weeks so the differences surface while the old process still works. The biggest schedule risk in this category is not code, it is discovering during cutover that the standards the system is validating against were never agreed.

Finally, they settle ownership before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else, in writing. At Digital Heroes the client owns the code from the first commit. A developer who hedges on that question is selling you a dependency with a software wrapper, and in this industry the dependency is often connected to an equipment vendor.