NMOLD Inventory Management Redevelopment

Problem & Context

NMOLD’s inventory system began on a Python/Laravel stack. As requirements grew — image-based product categorization, remote poultry-farm monitoring, industrial PLC data streaming — the team moved to a more mobile-first, cross-platform stack.

Solution & Architecture

flowchart LR
  Mobile[Flutter app] --> API[Express backend]
  API --> DB[(MongoDB)]
  API --> Vision[Image recognition module]
  PLC[Siemens / Delta PLC] --> NodeRED[Node-RED]
  NodeRED --> OPCUA[OPC UA client]
  OPCUA --> API

• Flutter frontend replaced the earlier Python/Laravel UI, giving a single cross-platform codebase for mobile and web inventory operations.
• Express + MongoDB backend replaced the relational Python/Laravel backend, chosen for flexible schema needs as inventory categories and product attributes evolved.
• Image recognition module to identify product categories automatically, aimed at reducing manual data-entry overhead during stock intake.
• OPC UA client + Node-RED integration streamed real-time PLC data (Siemens and Delta PLCs) for industrial monitoring use cases adjacent to the inventory system.

Key Decisions & Tradeoffs

[!NOTE] The system went through three tech-stack iterations (Python+Laravel → mixed → Flutter+Express+MongoDB) before settling — each transition driven by specific feature needs (image recognition, frequent-itemset analysis, remote monitoring) rather than a single rewrite decision.

• Frequent itemset analysis was explored on the earlier stack to recommend popular product groupings — a feature carried into later iterations rather than discarded during the rewrite.

Lessons Learned

[!WARNING] Multiple stack transitions in a short window increase the risk of feature parity gaps. Image recognition and remote-monitoring features were treated as first-class requirements during the rewrite specifically to avoid losing capabilities that had already shipped on the earlier stack.

Choosing MongoDB’s flexible schema over staying relational was specifically a bet on the rate of change in product attributes and categories — a relational schema would have meant a migration for every new attribute type the inventory model needed to track, while a document model let the shape evolve per-category without a blocking schema change. That tradeoff favors iteration speed over the stronger consistency guarantees a relational schema would have given the inventory counts themselves, which is a real cost worth naming rather than treating MongoDB as a strictly superior choice.