RPOMS

RPOMS is the operations platform for a router-refurbishment programme that Established Malaysian technology company runs with Malaysia's No. 1 E-Waste Recycling Company and Leading Malaysian telecommunications provider. 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 customer-facing portal enables electronic proof of delivery with digital signatures, while 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, Control Center 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: over 65,000 lines of TypeScript across 96 compiled routes and 2,388 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 292 commits on the production branch, every one except an uploaded copyright file is mine: the data model, every module, authentication and access control, the storage layer, the tests and CI, the remediation of two code audits, the deployment and staging runbooks, and the production releases.

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.

A router model used to be described in several places: a stock variant in inventory, detection rules in the registry, a request code in Ecommerce. They could drift apart, and a second spelling of the same model quietly became a second model. The model is now one record that all three modules read. A new name is matched against the existing models first, so a variant spelling links to the model that already exists instead of duplicating it, and detection rules point at the model by ID rather than by name.

Configuration health is computed on every request and never stored: a model with no serial prefix or length, an orphaned or conflicting rule, or a request code that is missing, invalid or not yet confirmed is flagged on the Super Admin tabs, on a strip in each affected module and in a Needs attention list with the fix beside it. Request codes print only after a Super Admin confirms them, a model that still has rules cannot be deleted from under them, and every configuration write is Super Admin only. The schema change is additive, and a test builds a production-shaped database to prove the migration changes no existing value.

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.

A production incident, written up as one: for about six minutes the admin panel showed an error page. The cause was not the code but connection-pool exhaustion, because production and a preview shared Supabase's session-mode pooler, which allows fifteen connections. Production now connects through the transaction pooler, which its public health endpoint reports, and the code detects which pooler a deployment is on from the host and port alone, warns when production is on the wrong one, and fails the environment check for it.

2,388 automated tests across 198 test files, written with Vitest. The database 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.

The test suite expanded across release milestones: 958 tests in the 28 September baseline, 1,637 tests in the 20 October release, 2,317 tests in the 4 November Delivery Tracking & ePOD production release, and 2,388 tests in the 6 November Control Center staging branch. Real PostgreSQL 17 concurrency tests validate adversarial scanner storms, ensuring zero duplicate writes and complete rollback integrity under simulated deadlocks.

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 flows through feature branches and a staging branch before it reaches main, and a data-preservation check compares every table's row count before and after a release. The September release went out as one verified branch: main was fast-forwarded to it, following a written release plan that lists the additive schema steps a first cold start runs, the release order and the rollback.

Since October 2026 staging runs on its own database, reported on its health endpoint, and the application refuses to start a preview against the production project. In November 2026, an end-to-end backup restoration drill proved full database restoration on an isolated PostgreSQL copy using the pg_trgm extension, verifying zero data loss.

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, but they sit behind a deployment-level write lock while the programme works through sign-off: while the lock is on, those screens show an under-development notice in production rather than their data. 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.

On 28 September 2026 the staging line was released to production: the remediation of both audits, the audit log, the environment guard, the login throttle, the test suite and CI, the full Ecommerce module, the centralised model configuration and the connection-pooler diagnostics. Production deploys from main on Vercel, and that release is what it runs today.

The 12 October production release added multi-box delivery batching and paginated inventory history. An 8,332-row historical router archive now lives in the production database as its own table with an import ledger; the 250,000-router import it was designed for was measured head-to-head on an isolated copy and has not been run against production.

Built between 13 and 20 October and released on 20 October: a Refining workstation where the first scan starts a cleaner's session and each scan registers the router once, with a partial unique index rather than a per-scan lock catching concurrent duplicates; a Printing page that saves scans side by side and sends each label to the running Print Engine tab as soon as its own save answers, where a lost answer is shown as status unknown and never as not saved; Today's Refiner Breakdown, drill-down and Bring from Refining into the Daily Report; a Router History page with one toolbar and a Filters panel instead of a filter grid; and Row Level Security on the Refining tables.

The central platform work adds Google sign-in through the Supabase project's provider with server-side PKCE and no client library, a services portal, and per-service grants: a Printing-only account sees no other tab, access requests name capabilities, and a revoked grant takes effect on the next request. Registry hardening sorts the first page on an indexed column, from 160 to 200 ms down to under 1 ms at 250,000 routers on an isolated copy, and the application now refuses to build or alter a store's schema on the production database. The 20 October handover package lists the five schema-only migrations production needs, in order, each with a rollback block; 1,637 tests pass on that branch.

Released to production on 4 November 2026 under explicit owner instruction (RPOMS_DELIVERY_TRACKING=1, RPOMS_EVIDENCE_STORAGE=vercel-blob): a full delivery tracking subsystem and electronic proof of delivery (ePOD) with zero regression on existing delivery orders. Every delivery order now carries a permanent, PIN-protected QR code that links to a dedicated customer-facing tracking portal (/cp/do/[id]). The system generates Word Delivery Orders matching the office's template byte-for-byte with embedded QR verification, eliminating manual paperwork discrepancies.

The ePOD mobile interface enables receiving customers and logistics operators to capture digital signatures directly on touchscreen devices. Proof uploads are validated via file magic bytes (strictly JPEG, PNG, or WebP under 4 MB) and hashed with SHA-256 before being committed to an isolated private blob store (rpoms-epod-production-proofs). A five-stage state machine (staged, in_transit, out_for_delivery, delivered, and delivery_discrepancy) governs order lifecycle transitions, supported by automated discrepancy reporting when delivered unit counts diverge from the scanned load.

Extensive layout verification ensured 32 of 32 responsive viewport checks passed cleanly from 320 px to 1280 px across dark and light themes, while production performance baselines showed scan-to-screen response times dropping from 316 ms to 81 ms on packing and 75 ms to 39 ms on registry scans.

Staged on 5–6 November 2026 (feat/control-center-2026-11-05), the RPOMS Control Center introduces real-time operational monitoring alongside an append-only production ledger (rpoms_production_ledger). To eliminate the risk of database locks and round-trip overhead on the warehouse line, ledger history is recorded using folded common table expressions (CTEs) within the router-move statement itself over RETURNING. This architecture guarantees zero standalone ledger round trips and zero duplicate entries on retries or concurrent scanner storms.

Data integrity is enforced at the PostgreSQL engine level: database triggers explicitly refuse UPDATE, DELETE, and TRUNCATE statements across all three Control Center tables (rpoms_production_ledger, rpoms_asset_specifications, and rpoms_progress_adjustments) for every database role, including the application itself. Row-level security revokes all public and anonymous privileges, preventing unauthorized PostgREST exposure.

An Asset Specification Matrix tracks model component requirements with versioned immutability, while supervisor adjustments record before-and-after deltas in an audited ledger without altering historical scan records. Keyset pagination over idx_cc_ledger_created guarantees consistent sub-millisecond retrieval across millions of historical events.

High-throughput warehouse operations suffer when technicians must continuously glance up from physical barcode scanners to computer screens to confirm each read. To solve this ergonomic bottleneck, an audio feedback engine was integrated across six core operational scanning modules: Intake, Acceptance, Refining, Packing, Delivery Loading, and Dispatch.

The engine plays immediate, distinct auditory cues: a clean chime for accepted units and a crisp warning buzzer for rejected, unassigned, or duplicate serials. Sound synthesis runs entirely client-side with zero network latency, ensuring audio playback never stutters or blocks the UI thread during rapid barcode scanning runs.

Refurbishment facilities frequently encounter routers that fail secondary functional testing or require component rework (such as port resoldering or cosmetic casing swaps) after initial acceptance. The RPOMS Rework architecture (RPOMS_REWORK=1) models this cyclical reality without corrupting the historical audit trail.

Routers routed into rework preserve their initial intake serial number, original batch origin, and historical test notes while initiating a secondary processing lifecycle. When reworked units re-enter the packaging line, the system enforces secondary quality-check clearances, prevents duplicate box assignments, and preserves both first-box and final-box lineage for post-delivery warranty investigations.

The router registry is benchmarked for large enterprise scale: 250,000+ historical router records are indexed using PostgreSQL pg_trgm trigram indexes, enabling sub-millisecond fuzzy prefix and serial searches even under heavy warehouse load.

Disaster recovery readiness was verified through an end-to-end production dump and restore drill (1,269,977 bytes dump, SHA-256 verified). The restoration verified table schemas, row-level security policies, and trigram extensions, proving zero operational data loss and rapid recovery capability.