Manufacturing Planning Management System
- Aug 2024 - Mar 2025
- Full-Stack Engineer
- Shipped
MPMS is a comprehensive manufacturing planning platform built from the ground up with multi-tenant architecture, genetic algorithm-based scheduling optimization, and a Conversational AI interface powered by RAG. It enables manufacturers to optimize job allocation, manage production schedules, and interact with the system through natural language.
25%
Throughput gain
99.8%
Uptime
15+
REST APIs shipped
50%
Faster release cycle
The Problem
Manufacturing companies struggled with inefficient job scheduling across multiple machines, leading to production bottlenecks. Existing solutions lacked intelligent optimization and required extensive training, creating a steep learning curve for floor managers.
Floor managers shouldn't need a degree in operations research to ask "what changes if Machine 3 goes down at noon?"
The Solution
Built a multi-tenant architecture with secure data isolation and scalability. Developed a Genetic Algorithm using the DEAP framework for job allocation and sequencing optimization. Integrated Retrieval-Augmented Generation using Pinecone, LangChain, and GPT-4, enabling natural language interaction with the platform.
Key Decisions
Genetic algorithm over MILP solvers
We chose DEAP's evolutionary approach for job allocation because manufacturing constraints kept shifting weekly — a hand-tuned MILP would have needed re-modelling every time a customer onboarded with new equipment quirks. GA tolerates messy, evolving constraints and ran fast enough on commodity hardware for live re-planning.
Tradeoff: Solutions are near-optimal, not provably optimal — but operations didn't need optimality, they needed speed and adaptability.
RAG layer over a custom SQL agent
Instead of a text-to-SQL agent, the assistant retrieves over a Pinecone-indexed schema, glossary, and historical Q&A. It composes structured tool calls under the hood. This kept hallucinated joins out of production and let the model answer domain questions the schema alone couldn't.
Tradeoff: Required a tighter content pipeline, but produced an assistant that was actually trustable on the floor.
Per-tenant row-level isolation in Postgres
Multi-tenant isolation via row-level security policies rather than per-tenant schemas. Backups, migrations, and shared dashboards stayed simple as the tenant count grew, and a single connection pool served them all.
Tradeoff: Heavier on policy testing during CI, but operationally simpler than schema-per-tenant at this scale.
The Impact
Significantly improved operational efficiency across industrial machines. Reduced the learning curve through conversational AI, enabling non-technical staff to interact with complex scheduling data through natural language queries.
With hindsight
If I rebuilt this today I'd put the GA scheduler behind a worker queue from day one rather than retrofit it after the first long-running run timed out a request. I'd also lean harder on Postgres LISTEN/NOTIFY instead of Celery polling for the live dashboard.