Swine Production Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the flow schedule get scoped as a calendar so often?

Because that is what it looks like today. The production manager opens a spreadsheet with sites across the top and weeks down the side, and a supplier sees dates in cells and quotes a scheduling screen with drag and drop.

What the spreadsheet does not contain is any of the rules the manager applies in his head. Barn capacity by room. All in all out at site or room level. Wash and downtime days between groups. Transport availability. The packer slot. The fact that a group cannot arrive before the previous one has left. He keeps those consistent by checking, every week, which is exactly why he spends eight to fifteen hours a week on it in the operations we have built for.

The consequence of scoping it as a calendar is that the new system reproduces the spreadsheet with a nicer interface and nobody's Tuesday changes.

The fix is to model sites, rooms, capacities, wash and downtime rules and transport as resources, then schedule groups against them. When the packer moves a slot, the consequence propagates backwards and shows which nursery cannot empty and which wean group has nowhere to go, on the Tuesday rather than the Thursday. The system should not decide whether to hold on the sow farm, double stock a room or split the group. It should present the capacity and biosecurity implications of each about a week earlier than a spreadsheet would, which is usually the whole difference.

What goes wrong when sow farm records and group history are migrated?

The breeding data is the part that matters and the part that exports badly. Years of service records, farrowing outcomes, parity structure and sow cards carry the analysis your production team relies on, and the export from an existing records system is rarely clean. Identifiers get reused, animals appear in more than one location, and events recorded under a superseded protocol do not map to the new categories.

The second problem is that historic groups were never recorded as groups. Site based systems record what happened at a site, so reconstructing a group's life across a sow farm, a nursery and two finishing barns means stitching together records that were never linked. Teams try to build that history retrospectively so the new system launches with benchmarks, and what they produce is a set of numbers that look authoritative and cannot be defended.

The fix is to profile the export before promising a migration, and to draw a line. Migrate the sow farm breeding history properly, because it has genuine analytical value, and start group level history from go live rather than fabricating it backwards. Carry a marker on anything reconstructed. Ask a supplier to look at your actual export file before quoting; the ones who have done this ask for it unprompted.

Why do feed mill and barn controller integrations break after launch?

Because both sit outside your control and neither was built for you.

• Mill interfaces vary wildly. One mill offers a clean interface, the next exchanges files with a system installed in 2004, and a third sends a delivery ticket by email. A build that assumes one shape breaks when you change suppliers or add a site.
• Deliveries post to bins, not groups. A bin holds two diets across a transition and serves whichever group is in residence, so the link from delivery to group has to be derived from dates rather than read from the ticket.
• Controller data is only worth having if you will act on it. Temperature and ventilation feeds are easy to collect and easy to ignore, and an integration nobody uses still costs maintenance every time the controller firmware changes.

The fix is to treat each mill as an adapter behind one internal delivery model, and to post every delivery to a bin, a site and the group in residence on that date. Consumption is then derived from events rather than estimated at settlement. Variance against the phase feed budget shows weekly, which is when it is still actionable, and a group eating fifteen percent under budget becomes a health flag before it becomes an accounting argument. Leave controller integration out of phase one unless you have named the decision it will change.

What happens when biosecurity status and withdrawal intervals are not enforced?

They stay where they are today, which is in your veterinarian's head and on a laminated sheet in the truck. Everyone in swine production knows that a positive site cannot receive naive pigs, that transport needs washing and documented downtime between loads of different status, and that personnel movement carries its own rules. Almost nobody has any of it in software as an enforceable rule, so compliance depends on the person under the most time pressure remembering it.

Withdrawal is the same failure with a different consequence. Medication delivered in feed or by injection carries an interval that must be observed before pigs go to the packer, and the person deciding to load is usually not the person who recorded the treatment weeks earlier. A load out inside the interval is not a paperwork problem.

The fix is dated status on sites, groups and vehicles, validated on every planned movement against a matrix your veterinarian defines and can change, with an illegal move blocked and the specific reason shown. Truck wash records attach to the vehicle with timestamps so the downtime clock is real rather than assumed. Treatments record product, dose, route, treater and a computed withdrawal end date that sets a state on the group, and a load out attempted inside it is blocked at the point of shipment with any override logged against a named veterinarian. A checkbox on a site record is not enforcement.

Should you build custom or configure what you already own?

Single site operations should not build, and we would say so on the call. If you run one farrow to finish site, or a sow farm whose pigs go to one buyer, PigCHAMP or Cloudfarms will serve you better than anything custom. They encode decades of production record keeping, their breeding analysis is deep, and your problem is husbandry rather than coordination. Configure what you have and spend the money on the barns.

If what you actually want is benchmarking against a wider dataset, MetaFarms offers something a custom build never can, because your own data cannot benchmark itself. That is a genuine reason to keep a service in the stack even if you build around it.

The build case starts when two or more of these hold. Pigs move between three or more sites. Your flow is scheduled more than eight weeks ahead and gets rebuilt weekly. Contract growers hold a meaningful share of your finishing space and settlement generates disputes. Ownership is mixed, so a group's records must be visible to different parties under different permissions. Or your veterinarian's movement rules are enforced by people remembering them.

The tipping point is the ownership boundary. One owner and one site is a records problem, and records products solve it. Several owners, several sites and a schedule is a coordination problem, and coordination logic between parties is what no vendor can generalise, because your grower contracts are not somebody else's grower contracts.

How do hidden costs get into the quote?

Through variation nobody has counted.

• Grower contract formulas. Each settlement arrangement is its own logic, and growers rarely have identical contracts. This is usually the largest single cost driver and it is invisible until someone reads all the agreements.
• Mill integration, which ranges from a clean interface to a file exchange with an old system, priced per mill rather than once.
• Sow farm data migration, where the breeding history matters and the export is rarely clean.
• Multi language field capture. Barn crews frequently work in Spanish, and a partially translated app produces bad data rather than none.
• Offline synchronisation, which sounds like a checkbox and is a real engineering problem once you require that a retried upload cannot duplicate a mortality entry.
• Party portals. Growers, outside owners and your veterinarian each need a different cut with different permissions, and each is a surface to design, test and support.

Ask for the estimate broken down per settlement formula, per mill and per portal, and ask who is reading the grower contracts.

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

Making the group the spine and everything else a view of it. The group carries an unbroken history across sites and owners, and permissions are cut per party rather than per system, so the grower records mortality and feed on a phone in his own barn and never sees another grower's numbers, the owner sees the group across its life, and the veterinarian sees the health record with movements attached. This is the hardest thing to retrofit onto site based products, because their data model assumes the site owns the pigs, and it is the thing that makes a bad close investigable instead of a guess.

The second marker is scope discipline. Start with flow scheduling and movement capture for one flow, and leave settlement to phase two once the event data is trustworthy. Settlement computed from an event stream both parties have watched all cycle is what removes the argument; settlement computed from data nobody trusts yet just moves the argument into your software.

When vetting a developer, ask them to model a group that gets split across two finishing sites under pressure. If both halves cannot keep the parent history and close out separately, everything downstream is wrong. Ask how the biosecurity matrix is enforced and expect dated status on sites, groups and vehicles with a hard block and a reason. Ask specifically how repeated submissions from the same phone are handled, because duplicated or lost daily entries corrupt closeouts and any build that assumes connectivity in a finishing barn will fail.

Then settle ownership in writing before kickoff. Your production records have years of value and they should sit in infrastructure you control. At Digital Heroes the client owns the code from the first commit, and a developer who wants to host your herd history on their own accounts is building a dependency rather than a system.