uPALMS

Context

uPALMS is a full refactor of a ten-year-old asset lifecycle management system that UBIVELOX has run internally for most of the last decade. Three roles — Administrator, Manager, Auditor — work across 61 screens grouped into 10 modules covering master data, assignment, audit, depreciation, and disposal. The constraint set the tone of the entire engagement: every operational workflow had to stay faithful to the process the client had already validated. Only the interface and the technology underneath it were allowed to change.

Problem

The old system worked, but it had aged into the kind of tool people tolerated rather than used. Field auditors carried laptops into warehouses to do work that should have been a phone scan. Managers and auditors saw the same dense screens regardless of context. Ten years of feature accretion had blurred the line between configuration and core workflow. The team needed a faster, role-aware interface that respected mobile reality — without re-litigating a single business rule the client had already operationalized.

Insight

Watching how the three roles actually used the system surfaced two ideas that reorganized everything that followed. Web is a control center; mobile is a field instrument. And an asset record is not an inventory row — it is a lifecycle artifact moving through purchase, assignment, audit, depreciation, and disposal. Once those two ideas were named, the 61 screens stopped feeling like a flat list and split themselves cleanly into 10 modules with clear ownership.

Decisions

▾ uPALMS/                                 # repository root├── ▸ .claude/                            # AI working memory├── ▾ upalms/                             # spec layer · source of truth│   ├── CLAUDE.md                         # project-wide working contract│   ├── README.md                         │   ├── ▸ docs/                           │   ├── ▸ data-schema/                    # per-module schemas · 12 files│   ├── ▸ design-system/                  # tokens · status colors · mockups│   ├── ▸ i18n/                           # en · ko translations│   └── ▸ outputs/                        ├── ▾ upalms-demo/                        # production prototype · React 19│   ├── package.json                      │   ├── vite.config.js                    │   ├── eslint.config.js                  │   ├── index.html                        │   ├── ▸ public/                         │   ├── ▸ src/                            │   └── ▸ docs/                           └── upalms-demo-source/                   # mirror of upalms-demo/

Execution

The deliverable is a single-file React 19 + Vite + Tailwind v4 prototype, backed by a custom GlobalDB layer that mirrors the planned NestJS schema and persists to localStorage. 61 screens, 10 modules, 3 roles. Six asset status states are locked at the design-system level — Available, Leased, Checked Out, Broken, Disposed, Lost — each rendered through a single StatusTag component so that color and meaning never drift across screens. Documentation lives next to the code: the SRS, data-schema files, and CLAUDE.md form a working contract that both AI agents and human developers can read.

Outcome

The prototype is now in the client's hands for hands-on evaluation, not as a clickable mock but as a real frontend that responds to real interaction. Because the prototype is shipping code, the development team's remaining work is mostly backend and API — an experienced frontend engineer can refactor the prototype directly rather than rebuild it from a spec. The case is honest about where the work ends: this is a foundation handed forward, not a launched product. What it proves is that an AI-augmented design pipeline can take a decade-old enterprise system through a full UI refactor without losing fidelity to the process the business runs on.