Poultry Farm ERP, Multi-warehouse poultry-farm ERP with live IoT-sensor integration

Project Overview

We built a centralized ERP for a large poultry enterprise that runs multiple warehouses and farms. The system replaces spreadsheets and vendor portals with one operator workspace, live IoT sensor data, and a strict inventory state machine with quality checks at every handoff.

Client Background

The client is a confidential AgTech operator running a large-scale poultry business across multiple sites. They handle bird logistics, feed, vaccination, environmental control, and warehouse inventory under one operations team. They needed a single system of record so warehouse managers, vets, and supervisors stop working from disconnected files and vendor dashboards.

The Problem

The operation tracked environmental conditions, feed schedules, vaccination logs, multi-warehouse inventory, and quality checks at every handoff. Most of this work lived in spreadsheets and vendor portals. Staff checked sensors by hand and reconciled inventory on a weekly cycle.

That setup created real costs. A missed temperature alert can affect bird health before anyone notices. An unreconciled transfer can hide a shortage for days. Manual quality checks made it hard to prove an inspection actually happened at a given handoff. The team needed live visibility and a system that enforced the process instead of relying on memory.

Challenges

• Legacy workflow built on spreadsheets and vendor portals with no single source of truth.
• Multi-warehouse and multi-farm hierarchy that the data model had to represent cleanly.
• Live IoT sensor streams that needed reliable ingestion and alerting, not polling.
• Complex inventory lifecycle with Receive, Transfer, Allocate, and Return states.
• Quality check protocols that had to gate state transitions, not sit beside them.
• Multiple operator roles working in parallel across sites with different responsibilities.
• Need for an audit trail strong enough to investigate any state change after the fact.

Our Approach

We started with the facility hierarchy and the inventory lifecycle, because those decisions shape everything else. We mapped how a unit of inventory moves from receipt at a warehouse to allocation at a farm, and where a quality check has to gate the next step. Then we mapped the sensor topology: which devices report which readings, how often, and what counts as an alert.

With the data model and event model in place, we split the backend into two services. NestJS handles the operator API and business rules. FastAPI handles IoT ingestion and any AI-adjacent services. PostgreSQL is the system of record. Next.js 16 is the operator UI. We kept the boundaries clear so each service can scale and change on its own schedule.

What We Built

Admin Operations

Operators run the full enterprise from one workspace. Warehouses, farms, and facilities are modeled as a hierarchy so transfers and allocations always reference real locations. Roles separate warehouse staff, supervisors, and admins so each user sees what they need.

Automation

The inventory lifecycle is enforced as a state machine. Items move through Receive, Transfer, Allocate, and Return states, and transitions require the right inputs. Quality checks act as gates between states, so an item cannot move forward until the inspection is recorded. Every transition is written to an audit trail.

Integrations

Sensors publish readings over MQTT. A FastAPI ingest service consumes the broker topics, persists readings to PostgreSQL, and pushes alerts to the operator dashboard when readings fall outside configured ranges. The MQTT layer keeps the system event-driven instead of polling.

Reporting

Environmental dashboards show live conditions across warehouses and farms. Inventory views show current state by location with the history of how each unit got there. Quality check records are attached to the relevant state transition, so audits are a query, not a hunt.

Technical Architecture

The system has four moving parts: the Next.js 16 operator UI, the NestJS business API, the FastAPI services for IoT ingest and AI-adjacent work, and PostgreSQL as the source of truth. Sensors publish to an MQTT broker, and the FastAPI ingest service writes readings into Postgres and notifies the API when an alert condition is met.

This shape keeps the operator API focused on business rules while the ingest path can scale on its own. The database stays the single system of record, which keeps audits and reports simple.

Key Decisions

• We split the backend into NestJS and FastAPI. NestJS is a good fit for the structured operator API and domain rules. FastAPI is a good fit for the IoT ingest path and AI-adjacent work. The tradeoff is two runtimes to operate instead of one, which we accepted for clearer ownership.
• We chose MQTT for sensor transport instead of HTTP polling. MQTT fits low-bandwidth devices and event-driven alerts. The tradeoff is running and monitoring a broker, which we accepted to get real-time behavior.
• We modeled inventory as a strict state machine with quality checks as gates. This makes invalid transitions impossible and makes audits straightforward. The tradeoff is less flexibility for ad hoc edits, which we accepted because the operator needs the discipline.
• We used PostgreSQL as the single system of record for both business data and sensor readings at the working tier. This keeps the architecture small. The tradeoff is that very long-term sensor history may later need a cold store, which the team can add without changing the API.

Results

The operator team runs the entire enterprise from one ERP. Environmental anomalies surface in real time instead of after the next manual check. Inventory state stays accurate to the unit because the system, not a spreadsheet, holds the truth. Quality checks are recorded against the transition they gate, which makes review faster and reduces back and forth between sites. Day to day work involves less manual reconciliation and gives supervisors better visibility across warehouses and farms.

Project Highlights

• One ERP covering multi-warehouse and multi-farm operations.
• Live IoT data over MQTT feeding real-time environmental dashboards.
• Inventory state machine with audit trails on every transition.
• Quality check protocols enforced as gates between states.
• Clear split between operator API (NestJS) and IoT and AI services (FastAPI).
• Next.js 16 operator workspace tuned for daily warehouse and farm use.

Screens and User Flows

The most important flow is moving a unit of inventory from receipt at a warehouse to allocation at a farm, with quality checks gating each step. The diagram below shows how the state machine handles the happy path and the rejection path.

An operator records the inspection on the same screen that triggers the transition, so the audit trail captures who acted, when, and on which unit.

Future Growth Opportunities

• Add a cold store for long-term sensor history while keeping recent readings in PostgreSQL for live dashboards.
• Add predictive alerts on top of the FastAPI services, using the historical sensor data already being collected.
• Expand the role model to cover external auditors and finance reviewers without changing the core state machine.
• Add a mobile-focused operator view for warehouse floor staff, reusing the existing NestJS API.
• Onboard additional facilities by extending the hierarchy, without changes to the inventory or IoT pipelines.