Multi Site Swine Software: Holding Pig Flow Together When a Barn Empties Late

Why flow, not the barn, is the actual business

A sow farm weans on a Thursday. Those pigs are already committed: a nursery site eleven weeks out, a finishing site after that, a packer slot months later. The schedule was set in a spreadsheet by the production manager, cross referenced against a wash and downtime calendar, a contract grower list, and his memory of which grower has had a rough year. On the Tuesday before, a finishing site fails to load out on time because the packer moved a slot. Now the nursery cannot empty, which means the wean group has nowhere to go on Thursday, which means either double stocking somewhere, holding pigs on the sow farm, or splitting a group across two sites and breaking all in all out. Every one of those choices costs money and at least one of them creates a health risk that will show up in a closeout eight weeks later, when nobody remembers the Tuesday.

The systems in a production system of this size are typically PigCHAMP or Cloudfarms on the sow farms, MetaFarms or a similar service pulling grow finish data, feed orders in the mill system, spreadsheets for the flow schedule, and email for everything that crosses an ownership boundary. Those products are not the problem in isolation. PigCHAMP has been the reference for sow farm records for a long time and its breeding analysis is deep. MetaFarms aggregates and benchmarks grow finish data seriously. Cloudfarms is a competent modern cloud platform. The gap is that all three treat a site as the unit of record, and your business is a group of pigs moving between sites owned by different parties on a schedule that is set months ahead and broken weekly.

The cost of that gap is specific. In systems we have built for, the recurring pattern is a production manager spending eight to fifteen hours a week rebuilding and re-communicating the flow schedule, disputes with contract growers at settlement because feed delivered and pigs placed do not reconcile, and post hoc investigations into a bad close where the health and movement history has to be reconstructed from three sources and a phone. The worst version is a group that gets split under pressure and nobody records it properly, so every performance number for those pigs is wrong for the rest of their life.

Problem 1: the flow schedule is a spreadsheet with no constraints in it

The schedule needs to respect real limits: barn capacity by room, all in all out at the site or room level, wash and downtime days between groups, transport availability, the packer slot, and the fact that a group cannot arrive before the previous one has left. A spreadsheet holds none of those as rules. It holds dates that a person keeps consistent by checking.

What a custom build does: model sites, rooms, capacities, wash and downtime rules, and transport as resources, then schedule groups against them. When the packer moves a slot, the system propagates the consequence backwards and shows you exactly which nursery cannot empty and which wean group has nowhere to go, on the Tuesday rather than the Thursday. It proposes the options you would consider anyway, holding on the sow farm, double stocking a specified room, or splitting the group, with the capacity and biosecurity implications of each. It does not make the decision. It makes the decision visible eight days earlier, which is usually the whole difference.

Problem 2: groups cross ownership boundaries and the records do not

A group of pigs might be owned by the production system, placed with a contract grower who owns the barn and the labour, fed from a mill that bills the owner, and cared for under a veterinary protocol set centrally. Four parties with four different information needs and four different systems, and the pigs are the only thing that actually moves between them.

What a custom build does: the group is the spine, with an unbroken history that follows it across sites and owners, and permissions are cut per party rather than per system. The grower sees his own barn, records daily mortality and feed on a phone in the barn without signal, and never sees another grower's numbers. The owner sees the group across its life. The veterinarian sees the health record with movements. One record, several views. This sounds obvious and it is the single hardest thing to retrofit onto site based products, because their data model assumes the site owns the pigs.

Problem 3: biosecurity status is the constraint nobody encodes

Health status governs movement. A PRRS positive site cannot receive naive pigs, transport has to be washed and dried with documented downtime between loads of different status, and personnel movement between sites carries its own rules. Everyone in swine production knows this. Almost nobody has it in software as an enforceable rule, so it lives in the veterinarian's head and a laminated sheet in the truck.

What a custom build does: status is a dated attribute of a site, a group, and a vehicle. Every planned movement is checked against your own matrix, which your veterinarian defines and can change, and an illegal move is blocked with the specific reason rather than warned about. Truck wash records attach to the vehicle with time stamps, so the downtime clock is real rather than assumed. If a foreign animal disease event puts movement permits into play under a Secure Pork Supply style plan, the site and group documentation you need is already assembled instead of being requested from four places while the state is deciding whether your trucks can roll.

Problem 4: feed budgets, withdrawal, and grower settlement all fail on the same missing link

Phase feed budgets say a group of a given size should consume so much of each diet by weight over a window. The mill delivers to a bin at a site. Nobody reconciles the two until settlement, and by then the group has moved and the bin has held two diets. Meanwhile any medication delivered in feed or by injection carries a withdrawal interval that must be observed before pigs go to the packer, and the person deciding to load is often not the person who recorded the treatment.

What a custom build does: feed deliveries post to bin, site, and the group in residence on that date, so consumption is derived from events rather than estimated at the end. Variance from the phase budget shows weekly, which is when it is still actionable, and a group eating fifteen percent under budget is a health flag before it is an accounting one. Treatments record with product, dose, route, and computed withdrawal end date, and a load out inside that date is blocked at the point of shipment. Settlement then computes from the same event stream both parties have been looking at all season, which is what removes the argument. In our experience this alone changes the tone of grower relationships more than any payment term.

Problem 5: when a close goes bad, the cause is unrecoverable

A finishing group closes at a mortality rate well above target. The investigation asks the obvious questions: where did those pigs come from, what was the source sow farm's health status at weaning, were they split, what did they eat, what was treated and when, what was the temperature curve in that barn. The answers exist in five places and two of them are memories. So the conclusion is usually a guess, and the same failure repeats.

What a custom build does: because the group carries an unbroken event history, the investigation is a query. Source farm, weaning group, every movement, every treatment, every feed delivery, every mortality entry with the person who recorded it, and any environmental data you have chosen to capture from the controllers. Comparison across groups from the same source or the same grower becomes routine rather than a project. This is where multi site systems find the two or three structural problems that were costing them every cycle, and it only works if the history was captured as events at the time rather than assembled afterwards.

What this costs and how long it takes

Digital Heroes has delivered more than 2,000 projects, and for multi site swine production the shape is this. A first release with group flow scheduling against site and room capacity, movement events with biosecurity checks, grower level daily capture that works offline, and withdrawal enforcement runs $85,000 to $180,000 in 14 to 20 weeks. A full platform adding contract grower settlement, phase feed budget reconciliation against mill deliveries, closeout analytics, and portals for growers and outside owners runs $220,000 to $520,000 across 9 to 15 months.

What drives price up specifically here: the number of ownership arrangements, because each settlement formula is its own logic and growers rarely have identical contracts. Mill and feed order integration, which ranges from a clean interface to a file exchange with a system installed in 2004. Barn controller integration for temperature and ventilation data, which is worth doing only if you will act on it. Sow farm data migration out of an existing records system, where the historical breeding data matters and the export is rarely clean. And multi language field capture, since barn crews frequently work in Spanish and a partially translated app produces bad data rather than no data.

What keeps price down: starting with flow scheduling and movement capture only, for one flow, and leaving settlement to phase two once the event data is trustworthy.

Build versus buy, and when buying is right

Do not build if you are a single site farrow to finish operation, 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, and your problem is husbandry rather than coordination. If your need is benchmarking against a wider dataset, MetaFarms offers something a custom build never can, because your own data cannot benchmark itself.

Build when two or more of these are true. You run three or more sites with pigs moving between them. 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 have to be visible to different parties with different permissions. Or your veterinarian's movement rules are enforced by people remembering them.

The tipping point is the ownership boundary. One owner, 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 exactly what no vendor can generalise, because your contracts are not somebody else's contracts.

How to choose a developer for swine production software

Ask them to model a group that gets split across two finishing sites under pressure. If the data model cannot represent a split with both halves keeping the parent history and the ability to close out separately, everything downstream is wrong, and this is the specific thing that breaks in generic builds.

Ask how the biosecurity matrix is enforced. The right answer is dated status on sites, groups, and vehicles, with movement validation against a veterinarian editable rule set and a hard block with a reason. A checkbox on the site record is not enforcement.

Ask who owns the code and the data, and get it 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 any developer who wants to host your herd history on their own accounts is building a dependency rather than a system.