Pugaran: Translating Poultry Operations Into a Mobile Inventory System

Pugaran is a mobile-first system for a poultry business where products, stock, requests, purchasing, approvals, and delivery all affect one another. The project began with process diagrams before interface screens because the central challenge was not displaying inventory. It was preserving responsibility as stock moves through a real organization.

Mapping the Work Before Designing Screens

The operational flow starts when an employee requests an item. A manager consolidates the request, the warehouse checks inventory, and available stock can be delivered immediately. If stock is unavailable, the request moves through approval and purchasing before returning to receiving and inventory.

Drawing that path exposed states that a simple inventory table would miss: pending approval, urgent, denied, approved for purchase, awaiting supplier, received, and delivered. Those states became the vocabulary shared by the data model and interface.

The diagrams also identified the documents attached to transitions, including request forms, purchase orders, and acknowledgment receipts. Modeling them explicitly creates an audit trail instead of relying on a mutable status field with no explanation of how it changed.

Designing Roles and Tenant Boundaries

Pugaran supports work performed by staff, request managers, warehouse managers, owners, and purchasing personnel. Each role needs a focused view of the same operation. Staff create and track requests; warehouse users update stock; managers consolidate and approve; owners see exceptions and overall health.

Permissions must be enforced at the data boundary. Hiding an approval button is not authorization. Every read and mutation needs to verify the farm account, membership, and role so one tenant cannot access another tenant's records through a modified request.

A Dashboard Built Around Exceptions

The dashboard does not attempt to show every record. It highlights the state requiring attention: inventory stability, requests that need action, total stock value, and low-stock items. A prominent New Request action supports the most common workflow without burying it in navigation.

The approval view applies the same principle. Pending and urgent counts appear before the list, with filters for urgency and department. Each request includes the requester, time, item quantities, and direct approve or deny actions. The design makes the consequence of a decision visible before the action is taken.

Catalog and Inventory as One System

The product catalog combines a customer-facing description with operational stock. Categories and search help users find items, while stock badges expose availability and low-stock conditions directly on the product. This avoids a split where the catalog promises an item that the inventory system already knows is unavailable.

Inventory changes are event-driven. Receiving a delivery increases stock; employee consumption or fulfilled requests reduce it; crossing a configured threshold creates a low-stock event. Storing those movements makes the current total explainable and supports historical reporting later.

Turning Low Stock Into Action

A low number on a dashboard is only useful if it starts the right workflow. When stock falls below its minimum, Pugaran notifies responsible staff and creates a clear path to requisition. Managers can review urgency and consolidate demand before purchasing, reducing duplicate orders from separate departments.

Notifications are separated from the underlying event. The stock transition remains recorded even if push delivery is temporarily unavailable, allowing the system to retry and ensuring a messaging failure does not erase the operational fact.

Building for Field Conditions

Farm and warehouse work does not guarantee office-quality connectivity. Mobile screens use large actions, direct status language, and persistent navigation because users may be moving, wearing gloves, or checking information quickly.

The data layer should queue safe updates during connection loss, indicate when information may be stale, and reconcile changes after reconnecting. Operations such as approval require extra care because blindly replaying the same action could duplicate a purchase or advance a request twice. Idempotent commands and server-side status checks protect those transitions.

What the Prototype Proved

The prototype demonstrates that the requisition, approval, purchasing, receiving, catalog, and low-stock paths can share one coherent model. The interface is not a collection of farm-themed screens; it is a view into the operational states defined before implementation.

A production version would add barcode-assisted receiving, configurable thresholds by location, richer supplier records, offline queues, scheduled reports, and a complete audit view. The most important foundation is already present: every number on the dashboard can lead back to a movement, request, decision, or delivery in the real workflow.