PRODUCT STATUS
Buying maintenance software means trusting a roadmap. This page states where UR Maintain actually is, in the product's own words — including the parts that are not finished.
WORKING TODAY
Reviewed against the application's own engineering documentation in September 2026.
Sign-in runs through Keycloak (authorization code + PKCE) — no password ever touches the application. The app lists the plants you are actually a member of and asks which one you are working in. Site scope is applied on the server, so it is a limit rather than a label.
Assets list with status and site and open into a full record: tag, type, maker, model, serial number, criticality, location and plant. A field nobody has recorded reads “Not recorded” rather than sitting blank. The Scan tab resolves a QR sticker to that machine, so a technician goes from standing at the equipment to its record without typing.
Filing works with the API unreachable: the report is written to the device first. A connectivity strip shows what is waiting and whether the plant has confirmed it, and coming back online pushes it automatically. A plant that refuses a report says so on the device as “Needs review” instead of retrying forever.
Take, start, wait with a reason, resume, report the machine running and finish the report — all of it working offline. A supervisor then verifies and closes. Reporting the machine running is a fact about the equipment and does not move the job, so a line can be back in service at 03:00 and the report written after the shift.
Everything written on a job — notes, waits, diagnostics and handover remarks — is listed back on it, oldest first, with the name of whoever wrote it. The next shift reads the history instead of guessing from the last line.
A parts catalogue with per-bin availability. From a job a technician reserves or issues a part, and the stock ledger shows what moved. A reservation appears as a promise, never as used stock, and an issue that would take a bin below zero is refused with the plant's own figures.
A planner defines a recurring job — for example every two weeks on Monday and Wednesday at 06:00 in Europe/Warsaw — against the machines it covers. The plant generates the work orders itself, exactly once, and holds the local time across a clock change. Editing a plan creates a new revision, so a job generated last month still names the plan it came from.
A planner writes a checklist and publishes a version. A technician starts an inspection pinned to that version, answers its items, and the plant decides which answers count as failures from each item's own rule. The corrective work order is offered as a separate, deliberate action. A published checklist cannot be edited afterwards.
A drawing, manual or procedure stays linked to the machine it describes. Replacing it means uploading a new revision; the old ones stay readable exactly as they were, and exactly one revision is marked current. Downloads come straight from object storage and files never pass through the application.
One field answers about machines, jobs, defect reports, parts and documents — grouped, ranked and scoped to the plant, or to a single machine from that machine's own screen. It tolerates half-remembered codes and misspellings, and results carry the plant, the machine and the revision of the row behind them.
A manager stages a CSV of machines or parts from a legacy system. Every row is judged before anything is written and reported back as valid, warning, error or applied. Applying is safe to repeat, and a row already applied is never written twice. The import never touches an asset tag, a part number, stock levels or money.
The outgoing shift files a handover for the incoming one: the lines it carries, the machine or job each line names, and the rows flagged as needing attention. The incoming shift opens the whole handover — every line, in the order the outgoing shift wrote it — and both the feed and the screen are there. A filed handover cannot be edited or deleted: the tables grant reading and inserting and nothing else, so a correction is the next handover rather than a silent rewrite.
Stated limit: filing is online-first. A handover needs the plant reachable, nothing is queued on the device, and the screen says so before a shift types anything.
The application ships with a service worker that precaches its own shell, so a handheld closed in a dead zone opens the application again instead of a blank page, and an /api/ path is never answered out of that cache. Stated limit: no automated test exercises the worker — the browser suite runs the development server, where the plugin registers nothing — so this is described as configured rather than claimed as proven. What is tested today is a full reload with the API unreachable, which proves the application's own offline gate rather than the worker.
Every plant's rows are separated by PostgreSQL row-level security in forced mode, with a runtime role that cannot bypass it. Another plant's record answers as “not found” rather than leaking, and a reference to another plant's site or machine is refused by the database, not by application code that could forget to check.
IN DEVELOPMENT
Each item below is a deliberate decision with a reason, not an oversight. None of them is sold as available.
A document revision can be downloaded and opened in your own reader. Searching inside a PDF by page number, and reading text out of a scanned drawing, are not built — today documents are found by their number or title.
Defect reports, the six job commands and photos work offline, and so does opening the app with no network at all. Inspections, inventory movements, preventive-maintenance commands and shift handovers need a connection, and the screens say so rather than pretending to queue them.
With no connection the search box answers only from what the device itself holds — the reports filed on it and the commands issued from it. The plant's machines, jobs and parts are not cached on the device, and the screen says exactly that instead of presenting the subset as the plant's answer.
Open work, breakdowns, preventive-maintenance status and inventory issues are visible in the lists today. The manager dashboard, downtime figures and compliance reporting are not built — and no decorative numbers are shown in their place.
There is no audit-log table. Where a movement must be provable, the immutable ledger row itself is the evidence, carrying actor, timestamp and reason.
Import works; export does not exist yet, and neither does a tenant export or deletion workflow. Both need a decision about what a plant is entitled to take out before they can be built.
Nothing sends an email, a push or a webhook when something changes. The notification design is agreed; the tables are not written.
Preventive maintenance runs on the calendar today. Maintenance driven by running hours or counters needs the meter-reading queue, which is not built; the generator refuses that kind of plan by name rather than ignoring it.
Receiving, issuing, returning, reserving, releasing, adjusting and scrapping all work. Moving stock between bins as a linked pair is designed but not built, and the API refuses it by name rather than posting half of a transfer.
Search currently scans the caller's own plant, which is correct but does not stay fast forever. The next piece of work is a per-plant search table with an index that forced row-level security cannot invalidate.
SEE IT FOR YOURSELF
Ask us for access and we will show you the parts that exist — and tell you plainly about the parts that do not.
