Poultry Farm Management

Background

A broiler batch lives about six weeks, and its profitability is decided by numbers most farms only estimate: how much feed became how much bird (FCR), and what a kilogram actually cost to raise. When those live in notebooks — and the money in a separate ledger — they get calculated once, at sale time, when it's too late to change anything.

This started as flock tracking and grew, batch by batch with the farmer, into the system the farm actually runs on.

What I built

A farm ERP organised around two ledgers: the flock (what's happening in the shed) and the accounts (what it costs). One deployment runs multiple farms, each with its own sheds, staff, and books, with role-based users — the farm's vet gets his own login.

Flock operations

Each batch is tracked from chick placement to closing: daily mortality (day and night counts, plotted as a trend), feed consumption against Ross breed targets, water, medication entries, and weekly weights by shed zone. FCR, feed efficiency, and mortality % are computed live, mid-batch — while feeding decisions can still change. Closing rolls bird sales (cash or credit, weighed at the vehicle), salaries, and expenses into the batch's final numbers.

Real accounts, not a cash notebook

The money side is proper double-entry bookkeeping: cash and bank payment/receipt vouchers, journals, purchase and sale vouchers, a hierarchical chart of accounts, and the reports an accountant expects — trial balance, party ledgers, receivables/payables, cash & bank book. A bird sale recorded at the shed posts as a sale voucher in the books, so operations and accounts can't drift apart.

The shed talks back

Live readings per shed zone — temperature, humidity, ammonia, CO₂, oxygen — are checked against Ross target ranges. Out-of-range values raise alerts with AI-generated advice on what to do about them, in English and Urdu, because Urdu is what actually gets read in the shed.

Forecast and planner

A 90-day calendar scores each day's expected demand and cost risk from local factors: Eid and wedding season, payday timing, heat stress, chick and feed prices. And before any chicks are placed, the planner projects the whole batch's economics — expected FCR, break-even rate, profit at different sell rates, and how sensitive that profit is to feed-price moves.

Everything else a farm runs on

Farm-store purchases (feed, medicine, diesel) with supplier credit tracking, and staff check-in with on-time bonuses, late fines, and salary tracking.

Stack notes

React + TypeScript with Supabase for data and auth. The data model is deliberately boring — batches, daily logs, and ledger-style accounts — because the value is in the derived numbers, not the schema.

Outcome

TODO: real usage figures — batches tracked, flock sizes, and what changed in feed or sale decisions.