RPOMS

RPOMS is the operations system for a router-refurbishment programme that Blue Bee Technologies runs with ERTH and Maxis. It records each day's production, tracks every router by serial number from acceptance into a numbered box and out on a delivery, keeps the stock of routers, chargers, cables and boxes, and produces the delivery paperwork the office already uses. A second, locked-down build of the same code gives the Ecommerce team a portal for requesting stock.

The comparison to a warehouse or resource-planning system is about shape rather than scale. It is not a commercial ERP suite and does not try to be one: there is no finance, procurement or HR module. What it shares with that category is the structure, a single operational data model that inventory, production, delivery, workforce and reporting all read from, so a figure on a dashboard traces back to the event that produced it.

It is one Next.js 15 application: about 59,600 lines of TypeScript across 16 pages and 41 API route files, with 895 automated tests. Every screenshot on this page was taken from that application running locally on synthetic data.

A physical production line (intake, acceptance, 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, which box a serial went into, whether a delivery matched what was scanned, or whether a report was still current.

Spreadsheets do not validate. They have no single source of truth once someone keeps a private copy to be safe, and no audit trail once a number looks wrong. The spreadsheet is still visible in the code: the model-detection rules were seeded from the team's Excel formula, and a registry row is described as the web equivalent of a row in the Excel ACCEPTED list.

The programme refurbishes used routers in batches, each with a target. That is a different problem from manufacturing: units arrive in unknown condition and unpredictable quantities, and each one carries a serial number the system does not get to choose.

The operation runs on a physical floor in Malaysia, with a small team, a shared set of consumables, two warehouse sites, and delivery paperwork a customer already expects in a particular format. Those constraints shaped the software more than any specification did.

The first rule was that the software should fail in the safe direction. A missing password disables that login rather than falling back to a known value. A missing session secret stops the application in production. A missing deployment flag leaves production write-locked rather than silently live. A preview deployment pointed at the production database refuses to start serving.

The second rule was that a number should be traceable. Stock is derived from the full history of adjustments and consumption rather than stored as a running total, so a figure that looks wrong can be walked back to the day that produced it.

The third rule was that business rules belong in one place. The arithmetic that decides how many packaging boxes a day's output consumes lives in a single module that the report form, the inventory and the Ecommerce planner all call, so they cannot disagree about the same day.

I am the only developer on RPOMS. Of 284 commits on the current line, every one except an uploaded copyright file and a bot branch is mine: the data model, every module, authentication and access control, the storage layer, the tests and CI, the remediation of two code audits, and the deployment and staging runbooks.

I work as IT Systems & Operations Lead around RPOMS, so I also work directly with the side it supports: the production line, the stock it consumes, and the people running it day to day. RPOMS models a physical process closely enough to run it, which only works if the person building it understands the process and not just the schema behind it.

Two things are tracked in parallel. The Daily Production Report records how many routers each person accepted, cleaned and packaged that day, and stock is deducted from those figures. Separately, the Registry, Pack and Delivery screens follow individual routers by serial number into boxes and onto deliveries.

Cleaning is recorded only as a daily count per person. There is no per-serial cleaning state, and the system does not pretend there is. Alongside the main line, the Ecommerce team requests stock, an admin approves it, stages the exact routers, and transfers them, and only that transfer deducts anything.

The day's figures are entered once. Saving updates the dashboard and deducts stock in the same step: routers by accepted plus retired, chargers and cables by packaging. Batch and target carry over from the previous report, and Completed is the batch so far plus today's packaging, so progress is continuous rather than restarting each day.

For a plain admin, the server does not trust the totals it is sent. It recomputes Accepted, Cleaned, Packaged and Completed from the workforce rows, freezes batch and target, and only lets an existing output grow. Two admins saving the same day no longer overwrite each other: each save carries the row's revision, and a stale one is refused with a message to reload.

Every router is recorded by serial number, model, who accepted it and when. The model is detected from rules stored as data (a prefix and an optional length, longest prefix first), so a new model needs a rule rather than a release. A serial no rule recognises is kept, flagged and shown at the top of the list.

Packing scans serials into a numbered box. A serial that is unknown, not accepted or already in another box is flagged, and the box will not close around it unless the close is forced deliberately. A box closed short of its capacity says so on the list, and each box prints a label with a QR code of its number.

A delivery is built by scanning box numbers. The serials inside come from the registry and are never typed. The delivery cannot be saved until the scanned load matches the quantity it was raised for; the server enforces the same rule, and only a Super Admin can accept a short load. Saving writes the delivery, its boxes and each router's delivered state in one transaction.

The Delivery Order is generated from the office's own Word document with the details filled in, not redrawn. Word splits a line of text across several runs, so a placeholder can be broken in one place and intact in another; the generator does two passes for exactly that reason. The tracker exports to Excel in the column layout the customer's sheet expects.

Stock is never stored as a balance. Remaining is always what was booked in minus what was consumed, worked out when it is read, per item and per model, so editing or deleting a report cannot leave a stale figure behind. Every movement, including those written by an Ecommerce transfer, appears in one ledger.

Workforce output is measured against per-person targets that can be set by department, by day, or for one person on one day. Names are matched case-insensitively, and the spelling shown is the one a worker is recorded under most often.

The Ecommerce team asks for routers or sealed boxes through a portal that shows them their own requests and nothing else: no stock levels, no admin screens. Each request gets a number of the form ECR/YYMM/R/CODE/NN from a per-month counter, and a network retry returns the request the first attempt created instead of raising a second one.

An admin approves or rejects it, stages the exact routers by serial or by box (each one checked against the registry), and transfers them from loose stock or a storeroom. The client never sends a charger or box quantity; the server derives them. The same deduction plan drives both the preview and the commit, and a void reverses a transfer.

The dashboard answers how today went: the four figures against yesterday, batch progress, today's workforce against target, a trend, and a comparison against yesterday, a seven-day average, last week, this month or a custom range, because a comparison supports a decision and a raw count does not. It refreshes itself, and switches to Arabic with the whole layout mirrored right to left.

Report history is searchable by date and batch and exports to PDF.

One Next.js application with no separate backend service. Pages are server components that read the store directly; writes go through route handlers that check the role and validate every body with Zod. A single middleware sits in front of every request: it refuses a preview or laptop pointed at the production database, applies the production write lock, scopes the Ecommerce build, and sets security headers. Authentication is deliberately decided in each page and route, not there.

One storage interface, three backends, selected by which environment variables are present: PostgreSQL on Supabase in production, MySQL for an earlier cPanel path (report store only), and atomic JSON files for local work. Postgres tables are created on demand behind per-store schema stamps, and only one cold-starting instance wins the build, which matters when several deployments share a database. Every read runs under a deadline, and where a fallback would be dishonest the caller gets a distinct 'could not read' value instead of an empty result.

Four roles (viewer, Ecommerce, admin, super admin), each with its own credentials. A role whose password is not configured is switched off entirely. Sessions are an HMAC-SHA256-signed cookie carrying the role, when it was issued and a session id, compared with a timing-safe function, httpOnly, sameSite and secure in production. A viewer's session lapses after twenty-four hours; staff sessions last seven days. Sign-in attempts are throttled per address.

Big packaging boxes are not calculated with a ceiling function. One box per ten packaged units, plus one more once the remainder reaches seven, because a box near enough to full has already been opened and sent, while a smaller remainder will be finished by the next day's work and would otherwise be counted twice.

The business day is resolved in Asia/Kuala_Lumpur rather than from the server clock. A deployed server keeps UTC, which would not turn the day over until eight in the morning locally, long enough for early packing to file itself under the previous day.

Translations are typed against English as the source, so a string added in English fails the build until every other dictionary supplies it.

Most of these came out of two read-only audits of the codebase, the first of which recorded 44 findings, six of them rated P0.

Silent overwrites: two admins saving the same day meant the second replaced the first with no trace. Each save now carries the row's revision, and a stale save is refused with a 409.

A client-sent 'this came from a CSV' flag relaxed the add-only rules. The server now re-parses the attached worksheet and decides for itself which sections it supplied, and refuses a worksheet dated for a different day.

Every preview deployment was configured with the production database. A guard now makes a preview refuse the production database with a 503, work flows through a staging branch, and a one-way refresh script copies production to staging with names anonymised.

Deployments sharing one database raced to build schema on cold start, holding an exclusive lock. The build is now claimed with a single statement and a sentinel, and new columns sit behind their own marker keys so two versions of the code cannot keep undoing each other.

Box stock started mid-operation, with thousands of routers already packed. Counting them would have produced a deficit no correct booking-in could explain, so box stock starts from an opening figure on a fixed date and only later packing is counted.

895 automated tests in 60 files, written with Vitest. Sixteen of those files run real SQL against PGlite, PostgreSQL compiled to WebAssembly and served in-process, so transactions, locking, concurrency and schema setup are tested with the production driver and no database server. CI runs typecheck, lint, the tests, a production build and a dependency audit on every push.

For this write-up the production build was run locally on synthetic data, every screen was exercised, and a Delivery Order and the Excel exports were generated. Typecheck and lint passed. The full test run passed 59 of 60 files; the remaining file hit a ten-second hook timeout under machine load and passed when run on its own.

The project deploys to Vercel from Git: pushing the main branch deploys production, and every other branch builds a preview. Production data lives in Supabase PostgreSQL. Work now flows from feature branches into a staging branch and then to main, and a data-preservation check compares every table's row count before and after a release.

A separate staging database is designed and its bootstrap SQL written, but it is blocked on hosting limits, so previews are protected by refusing the production database rather than by having their own. The current plan has no managed backups; a read-only JSON export is the backup path until that changes.

In production, the dashboard and the Daily Production Report are live: the day's figures are entered for real, stock is deducted for real, and the dashboard reads back what was saved. The Ecommerce portal runs as its own build of the same code.

The registry, packing, delivery and paperwork, workforce and inventory modules are complete and render live data, but they sit behind a deployment-level write lock while the programme works through sign-off. The lock is enforced at one middleware chokepoint, is on by default in production, and names the modules allowed to write, so a module goes live by being named rather than by accident.

The newest work (the remediation of both audits, the audit log, the environment guard, the login throttle, the test suite and CI) is built and tested on the staging branch and has not yet been released: production deploys from main, which is 68 commits behind.