An AI poultry ERP that watches every shed in real time

The problem

Poultry is a margin business measured in grams and days. Feed conversion ratio, mortality, the temperature and ammonia in a shed overnight — these decide whether a cycle makes money. On most farms that information lives in a register, in a WhatsApp message, and in the head of whoever happened to be walking the sheds. By the time a problem is written down it has already cost birds.

What we built

NigehBaan is a complete ERP for the farm, not a dashboard bolted onto it. It follows a flock from the day-old chick through to the broker sale, and it covers the three shed types Pakistani farms actually run — open, smart and control.

• 📡Real-time IoT sensing. Temperature, humidity and ammonia stream out of each shed and land in a time-series store, so a reading is a trend rather than a number on a clipboard.
• 🚨AI disease early warning. Each flock carries a risk score that moves before symptoms are visible to a person walking the shed — the only point at which intervention is still cheap.
• 📈Forecasting, not just reporting. Every flock carries a predicted end-of-cycle FCR, mortality and average weight, each with a confidence interval, so a prediction made on thin data admits it rather than sounding certain.
• 🌍Bilingual Urdu and English, and it works offline on a phone. Sheds are not where connectivity is good, and the person entering the data is in the shed.
• 🇵🇰Data hosted in Pakistan, which for this market is a requirement, not a preference.

Where the AI sits

A dashboard tells a farmer what already happened. The money is in what is about to. Every flock carries a forecast of its end-of-cycle FCR, mortality and average weight, recalculated as the cycle runs and the readings accumulate.

Each number comes with a confidence interval, and a flock without enough history to forecast says so instead of producing a figure. That is the part worth insisting on: a prediction presented without its uncertainty invites a decision it cannot support, and on a farm that decision is made at four in the morning with birds in front of you.

The engineering

Sensor telemetry is a different shape of problem from business records, so it gets different storage: a purpose-built time-series store for the readings, a cache in front of the hot paths, and a dedicated broker taking the traffic off the devices. There are three separate front ends — the public site, the tenant application a farm uses day to day, and an operator console for running the platform itself.

The offline requirement shaped more of the design than anything else. Data capture has to succeed on a phone with no bars in a shed, and reconcile cleanly when the phone comes back into range — which means thinking about conflict and ordering up front rather than retrofitting sync later.

Why it matters for your project

If your product has hardware at one end and a business process at the other, this is the one to look at. Getting readings off a device is the easy half. Making them trustworthy, storing them so a year of history is still queryable, and putting them in front of someone who is standing in a shed and does not read English — that is the work.