The system that runs a router-refurbishment production line.

RPOMS is an internal operations system built for a router-refurbishment program that Blue Bee Technologies runs in partnership with ERTH and Maxis. Before RPOMS, the operation was tracked in spreadsheets. RPOMS replaces that with a single system covering the whole path a unit takes: arriving, accepted, cleaned, packed into a box, and delivered with the paperwork that goes with it.

A physical production line (intake, cleaning, packing, delivery) was being coordinated through spreadsheets shared across a team. That made it hard to know, at any moment, what had actually happened on the floor: what stock remained, who did what, whether a delivery matched what was scanned, or whether a report was even current.

I work as IT Systems & Operations Lead around RPOMS, which means the role isn't just writing the software. I designed and built the system end to end (data model, access control, every module, the deployment path to production, and I remain its maintainer), and I work directly with the operational side it supports: the production line, the stock it tracks, and the people running it day to day.

That combination is the point. RPOMS models a physical process (a router arriving, getting cleaned, getting packed, going out the door) closely enough to actually run it, which only works if the person building it understands that process, not just the database behind it.

On the systems side: application development, the data model, three-tier access control, database and storage architecture, admin functionality for every stage of the pipeline, reporting and export workflows, and ongoing maintenance as requirements change.

A Daily Production Report is entered once and updates the public dashboard and deducts stock in the same step. A Serial Registry tracks every unit by serial number, with configurable detection rules so a new model doesn't require a code change. Report history, CSV import, and PDF/Excel export all sit on the same data layer.

On the operations side: the actual production workflow (intake, cleaning, packing, delivery), the inventory it consumes (routers, chargers, LAN cables), and the constraints that come from a physical floor rather than a spec document.

Packing scans serials into numbered boxes and reports its own problems (an incomplete box or a duplicate serial) instead of leaving them to be discovered later. Delivery requires the scanned load to match the quantity a delivery was raised for before it can be saved, and generates the delivery paperwork directly from the operations team's own document template rather than redrawing it. Packing a router is never allowed to record the packer as its acceptor, because those are different jobs on the floor and conflating them would corrupt the daily report. Rules like that come from working with the process, not guessing at it.

Frontend: Next.js 15 (App Router) and React 19 in TypeScript, styled with Tailwind CSS v4, with data tables via TanStack Table, charts via Recharts, and forms validated with React Hook Form and Zod.

Backend: a single storage interface with three interchangeable backends, PostgreSQL (via Supabase, for the Vercel deployment), MySQL (for a cPanel deployment), and a local file store for development, selected automatically by which environment variables are present, with no code change between them.

Access & sessions: three access tiers, each gated by its own password. A tier with no password configured is switched off entirely rather than falling back to a default. Sessions are an HMAC-signed cookie, and the app refuses to start signing sessions in production without a configured secret.

Exports: delivery orders and tracker sheets are generated to match the formats the operations team already uses, and report history exports to PDF.

Auto-refreshing public dashboard with daily figures, batch progress, and trend comparisons against yesterday, a 7-day average, or a custom range.

Serial-level registry with staged CSV import: duplicates are surfaced before anything is written, not after.

Packing and delivery flows that validate against the registry and the raised quantity, rather than trusting manual entry.

Per-person workforce output against targets, with case-insensitive name matching so data-entry variance doesn't fragment the numbers.

A configurable demo mode: a deployment can run as a full walkthrough where only explicitly named modules actually write data, enforced at a single middleware chokepoint.

The spreadsheet-based tracking this program previously relied on has been replaced by a single system in active use for daily production reporting, registry, packing, delivery, and workforce tracking.