Poultry Management Software: Flock, Feed Conversion, and Contract Settlement

Why flock and house software makes or breaks a poultry operation

Same scene on nearly every poultry engagement we take. It is 5:40 in the morning. A grower walks house 6, sees mortality is up, writes the count on a clipboard hanging on the door post. That number gets keyed into a spreadsheet at the office sometime after lunch, maybe. Meanwhile the Chore-Tronics controller in that same house already knows the water draw dropped 9 percent overnight, which is the actual early warning, but that data sits in the controller and in the Chore-Tronics Mobile app and it never meets the mortality number in the same place. By the time anyone connects the two, you are three days into a health event instead of half a day.

Then look at the office side. The settlement sheet arrives from the integrator as a PDF. Somebody, usually a controller or an ops manager who is worth more than this task, retypes feed delivered, live weight, condemnations, and the flock average into Excel to check whether the ranking math actually matched what you were paid. Most operations we work with are running some combination of the integrator's grower portal (Tyson, Perdue, Pilgrim's, whoever holds the contract), Chore-Tronics or AgriNET or Rotem for the houses, QuickBooks or Sage Intacct for the money, and between four and eleven spreadsheets that nobody wants to inherit. The spreadsheets are where your actual business logic lives.

The leak is not dramatic, which is why it survives. On the mid-size operations we work with it runs 6 to 12 hours a week of retyping, a settlement discrepancy caught some of the time instead of every time, and a feed conversion number you cannot trust to two decimals when two decimals is the entire margin. On a 40-house operation, a 0.03 swing in feed conversion is real money every single flock. You are not managing it. You are reconstructing it after the fact.

Problem: flock records live in three systems that do not know about each other

A flock is a simple object conceptually: placement date, chick source, head count in, house assignment, feed deliveries, water draw, mortality by day, medication events, catch date, head count out, live weight. In practice that object is smeared across the hatchery paperwork, the house controller, the grower's clipboard, the feed mill ticket, and the integrator's settlement PDF. Nothing owns it end to end.

Off-the-shelf will not fix this because the tools are each honest about their own scope. Chore-Tronics is a house environment system, it is excellent at that, and it has no concept of a contract. The integrator portal is the integrator's view of your flock, not yours, and it shows you what they want you to see, on their schedule, after their processing. QuickBooks knows a feed invoice, not a feed conversion. There is no seam where these meet, and no vendor is incentivized to build one, because the integrator's incentive is specifically not to hand you a clean audit trail against their own settlement.

What a custom build does: one flock record as the system of record, with everything else as a feed into it. We poll the house controllers directly (Chore-Tronics and Rotem both expose data locally, AgriNET has an API, older Cumberland units usually need a gateway box) on a 15 minute interval and write temperature, water, feed bin weights, and ventilation state against the flock, not just against the house. The grower's mobile app records mortality and culls at the house door with the flock already pre-selected by geofence, so a walk takes 20 seconds instead of a clipboard-to-Excel round trip. Feed tickets get matched to the flock by delivery timestamp and bin. By catch day, the flock record is complete and it was complete the whole time, not assembled in retrospect.

Problem: contract settlement is checked by hand, or not at all

This is the section that pays for the project. The settlement sheet comes in as a PDF, and the tournament or ranking math inside it depends on your flock's performance relative to other growers settled in the same week. You get the inputs and the output. You do not get to easily verify the middle. So most operations spot-check, find a discrepancy every few months, argue it, sometimes win, and quietly assume the rest were fine.

No off-the-shelf tool does this, and the reason is structural: settlement math is contract-specific, sometimes grower-specific, and it changes when the contract renews. A software vendor would have to model every integrator's ranking formula and keep up with amendments across dozens of contracts. Nobody is doing that for a per-seat subscription. So the math lives in a spreadsheet your controller built in 2019 and nobody fully understands anymore.

What a custom build does, and the one AI feature we would fund first in this category: document extraction on the settlement PDF. The sheet arrives, an extraction model pulls feed delivered, live weight, head settled, condemnation counts, the ranking position, and the pay rate, and writes them into a structured record. Then your own contract terms, encoded once as a rules engine, recompute what the payment should have been from your own flock data. Discrepancies over a configurable threshold, we usually set it at $500 or 1.5 percent, open an exception with the two numbers side by side and the supporting flock data attached. Your ops manager reviews exceptions, not PDFs. On the 40-house operations we have shipped this to, it turns a half day per settlement cycle into 20 minutes, and it catches the small ones you were letting go.

Problem: feed conversion you cannot trust until the flock is gone

Feed conversion is the number the whole business runs on and most operations only know it accurately at settlement, which is to say after every decision that could have changed it has already been made. Mid-flock you are estimating from bin levels and gut feel. The feed mill knows what it shipped. The bin sensor knows what is left. Nobody is computing live feed conversion against a projected live weight per house per day.

The incumbent tools cannot do it because it requires joining feed mill delivery data, bin load cell readings, live bird count net of mortality, and a weight curve, and those four things live in four vendors. Even the better house systems show you consumption, not conversion, because they do not know your bird count after yesterday's culls.

What a custom build does: a daily feed conversion calculation per house, using delivered feed minus current bin weight, divided by estimated live weight from a breed standard curve calibrated against your own historical catch weights. Then forecasting on top, and this is the second model worth building: trained on your own last 24 to 36 months of flocks, projecting catch weight and conversion at day 14, so you can act on a house that is drifting instead of learning about it on the settlement sheet. We have found the useful output is not a prediction, it is a ranked list: these three houses are tracking 0.04 or worse against the flock, here is what is different about them (nighttime temp variance, water draw, feed delivery gap). That is actionable at day 14. At day 42 it is a post-mortem.

Problem: the grower network runs on text messages and phone calls

If you run contract growers, or you are a producer coordinating multiple farms, coordination is happening in group texts. Placement schedules, catch crew timing, feed delivery windows, medication instructions, mortality reporting. Somebody's phone is the integration layer. When that person is on vacation, the operation degrades.

Generic tools are the wrong shape. Slack and Teams are not built for a grower who has gloves on and is standing in a house. The integrator portal serves the integrator, and half your growers will not log into it. Off-the-shelf farm management tools like Agworld or Granular are built for row crop and have no useful concept of a house, a flock, or a placement.

What a custom build does: a grower-facing mobile app doing four things and nothing else. Today's tasks for their houses. Mortality and cull entry. Photo capture for anything unusual, attached to the flock. Placement and catch schedule for the next 21 days. Push notification when the schedule moves. On the office side, an after-hours intake path matters more than people expect: a grower calling at 11pm about a downed fan gets an AI voice intake that captures house number, symptom, and severity, writes a ticket against the house, and escalates to the on-call number only if severity crosses the bar. Most calls are not emergencies. The few that are should not be buried in the rest.

Problem: compliance and audit paperwork is reconstructed, not recorded

NPIP records, medication and withdrawal logs, mortality disposal, biosecurity entry logs, welfare audit prep for whatever program your integrator is enrolled in. When an audit is scheduled, somebody spends a week rebuilding records from clipboards, texts, and memory. That week has a cost, and the reconstructed record is weaker than a contemporaneous one.

Nothing off the shelf covers it because the requirements are a union of federal, state, integrator program, and customer program, and the intersection is unique per operation. Vendors ship a generic checklist. Your auditor does not want a generic checklist.

What a custom build does: capture as a byproduct. Biosecurity entry logged when the mobile app crosses the geofence at the farm entrance. Medication events recorded at administration with the withdrawal date auto-calculated against the projected catch date, and a hard block plus alert if a treatment would put the flock inside withdrawal at catch. That single rule has saved condemned loads on operations we have built for. Mortality disposal logged with method and volume. Audit export as a single PDF pack for a date range, generated in under a minute, built from records that existed at the time rather than assembled after the request.

What this costs and how long it takes

These are our own delivery bands from 2,000-plus projects, not market averages. A focused first release runs $60k to $130k and ships in 12 to 16 weeks. For poultry that scope is: flock and house data model, controller integration for one make, grower mobile app for mortality and tasks, feed conversion dashboard, and settlement extraction plus reconciliation for one contract structure. That is the release that changes your week. A full platform, meaning multiple controller makes, feed mill dispatch integration, integrator EDI, grower portal, forecasting models, accounting sync, and audit packs, runs $150k to $400k phased over 6 to 12 months.

What drives price up specifically here. Controller integration count is the big one: one make is a known quantity, four makes plus a 1990s Cumberland unit that needs a hardware gateway is a different project, and each additional make adds roughly $12k to $25k. Multiple contract structures multiply the settlement rules engine, and each distinct integrator contract is another $10k to $20k of modeling and testing. Connectivity is the underestimated one: houses in rural Alabama or Arkansas do not have reliable data, so the mobile app needs real offline-first sync with conflict resolution, which is a genuine engineering cost, usually $15k to $30k, and skipping it means the app is useless exactly where you need it. Historical data migration from spreadsheets of unknown provenance is another $8k to $20k depending on how bad the sheets are, and they are usually bad.

Build versus buy: where the line sits

Buy, or rather stay put, if you run a single farm under about 8 houses on one integrator contract with one house controller make. The integrator portal plus Chore-Tronics Mobile plus a well-kept spreadsheet is adequate at that size, and a $90k build will not pay back. Take the free tools, keep the spreadsheet clean, spend the money on equipment.

Build when these show up. You run two or more contract structures at once, because that is the point where the spreadsheet becomes a liability nobody can audit. Your settlement reconciliation depends on one person and you cannot say precisely how their sheet works. You are past roughly 20 houses, where a 0.03 feed conversion drift is real annual money and you have no mid-flock visibility to defend it. You have made an acquisition and inherited a second controller make and a second set of records. Or you are a contract grower network operator, where coordination cost scales with growers and text messages do not.

Our position: in this category the build case is almost always the settlement reconciliation and the mid-flock feed conversion, not the flock records. Flock records are the boring foundation. The return is in the two numbers that touch money. If a developer pitches you a build and leads with dashboards, they have not run this before.

How to choose a developer for poultry management software

Ask them to whiteboard the flock data model before you sign anything. If they cannot draw placement, house, flock, feed delivery, mortality event, and settlement as related entities with the right cardinality, and explain why a flock is not the same as a house, they will learn it on your budget. The tell is whether they ask about split placements and partial catches unprompted.

Ask what they have integrated with. Not "we do IoT," specifically: which controller makes, how they got data out, whether they went through the vendor API or polled Modbus or used a gateway, and what broke. Anyone who has done this has a story about a controller firmware update silently changing a register. If they have no story, they have no experience.

Make them explain how they will model your settlement contract and what happens when it renews with new terms. The right answer is a configurable rules engine with versioned contract terms and the ability to recompute historical flocks against the terms in force at the time. The wrong answer is hardcoded formulas, which means every contract amendment is a change order.

Confirm code and data ownership in writing before kickoff, including the controller integration layer and the trained forecasting models. You should own the repository, the infrastructure accounts, and the data outright. And ask directly how they handle withdrawal period logic and NPIP record retention, because a developer who has not thought about a condemned load is a developer who has not shipped in this industry.