Features
Mobile app
The technician surface is not a smaller version of the desktop one. A biomedical engineer triaging a queue wants density: filters, history, cost. A technician standing in front of an autoclave wants one task, its checklist, and a camera. Building the second as a shrunken first is the most common mistake in this category.
- Field technicians
- Biomedical engineering
What is the Rydya mobile app?
Definition
The Rydya mobile surface
The Rydya mobile app is an installable, offline-capable interface for field work, serving the technician the specific tasks assigned to them along with the checklist, readings and evidence capture each one needs, from the same backend and data model as the web workspace.
The phrase carrying the weight is same data model. A mobile app that syncs a subset into its own schema is a second system, and a second system drifts. When the ward asks what happened to a device, the answer must not depend on which application you ask.
It is delivered as an installable progressive web app rather than a native binary. That is a deliberate trade, and it has real costs as well as real benefits, which the comparison below states rather than hides.
Why technician tools fail to get adopted
Because they are designed for the person who buys them rather than the person who holds them, and a technician standing in a plant room will not fight an interface for information nobody asked them for.
Adoption in this category is not a training problem, it is an arithmetic problem. If the tool costs a technician more time than it saves them, it will be filled in at the end of the week from memory, which is worse than useless because it looks like data. Every field marked mandatory that nobody downstream reads is a direct withdrawal from that account.
The second failure is context. A phone screen showing a list of forty jobs, filters, and a dashboard is a desktop app that has been squeezed. The technician does not need to triage; that already happened. They need the job they are standing in front of, and the fastest possible route to recording what they just did.
The third is signal, which is not a design failure but is treated as one by tools that simply stop working. Plant rooms, basements and lift shafts are where the equipment lives. An app that requires connectivity has decided not to be used where the work is.
How a technician works a job on the phone
Five things, in order, on one screen, with no step that exists purely to feed a report.
- 1
Open my work
A ranked list of what is assigned to them, ordered by what needs a person now rather than by when it arrived. Not a dashboard, not counts. The next job.
- 2
Scan to confirm the asset
The QR code on the equipment resolves the exact device, so the record attaches to the right one of the four identical pumps on the ward. Scanning also works for lots, serials and work items.
- 3
Work the checklist
The steps and checks from the template, with the readings to capture. The procedure version is recorded with the result, so what was done stays interpretable years later.
- 4
Capture evidence with the camera
Photos attach to the job as real bytes rather than metadata. A picture of the damage taken at the moment of work is frequently the difference between a supported warranty claim and an argument.
- 5
Submit, and see the sync state
Offline, queued and syncing are shown rather than implied. The tick means synced, not attempted. If four items are waiting, the technician can see four items waiting.
Why a PWA rather than a native app
This is a trade with real losses, not a free win. Here is the actual reasoning.
| Consideration | Installable PWA | Native app |
|---|---|---|
| Getting it onto a phone | A URL. No store, no MDM queue, no device enrolment | App store or MDM distribution |
| Agency and bank staff | Works immediately on their own device | Often blocked entirely |
| Updates | Ship once, everyone current, deferred while work is unsynced | Store review, then user updates eventually |
| One codebase with the workspace | Yes, same data model, no second system to drift | A second client to keep in step |
| Camera and scanning | Available | Available, with deeper hardware access |
| Background sync when closed | Limited by the platform | Better |
| Deep hardware integration | Constrained | Better |
What the progressive web app choice buys and costs
What the mobile surface deliberately cannot do
The refusals are the same ones that make offline safe, and they are worth stating plainly rather than discovering.
It cannot return a device to service offline
Return to service is a gate requiring the tests and an authorised clearance, and it is server authoritative. An offline device cannot establish that equipment is safe, so the action is unavailable rather than queued.
It cannot quarantine offline
Same reasoning, opposite direction. Quarantine is a decision about clinical use that must be authoritative the moment it is made.
It cannot approve or set final cost offline
Server authoritative, and financial records are immutable with corrections as audited amendments rather than edits.
It cannot see beyond the technician's scope
Permissions are scope aware and checked on the server. A phone is not a privilege escalation, and losing one is not a data breach of the estate.
When to put it in technicians' hands
On day one, before the register is perfect, because the mobile surface is what generates the information that fixes the register.
The temptation is to complete the data first and deploy to the field later. It is exactly backwards. The technician with a phone in front of a real device is the highest quality data source the organisation has, and every scan is a confirmation of where an asset actually is. Deploying the field surface late means paying for a discovery exercise you could have got for free.
The pragmatic sequence: import the register, put codes on the equipment that matters most, and give technicians the app in the same week. The first month of scans will tell you more about your asset data than any audit, and it will cost nothing extra because the work was happening anyway.
Questions
Is there an app store download?
It is an installable progressive web app, so it is added from a URL rather than a store. That is deliberate: it means agency and bank staff can use it on their own device immediately, without an MDM enrolment queue, and updates ship once rather than waiting on store review and user action. The trade is less deep hardware access and more limited background sync, which is stated in the comparison above rather than glossed over.
Does it work with no signal?
Yes, for the observation work: my work, scan, checklists, readings, notes and photos, queued durably in IndexedDB so it survives the app closing or the battery dying. Safety-critical actions such as quarantine, return to service and approvals stay online by design, because an offline device cannot establish that equipment is safe.
Is it a different system from the web workspace?
No, and that matters more than it sounds. One backend and one data model serve web, installable PWA, desktop, mobile and tablet. A mobile app with its own schema is a second system, and second systems drift until the answer to "what happened to this device" depends on which application you ask.
Will an update interrupt a technician mid-job?
No. A new version is deliberately not applied while there is unsynced field work, because reloading could strand queued changes. The update waits until the queue has drained.
What if a phone is lost?
Permissions are scope aware and enforced on the server, so the device only ever had the holder's scope rather than the estate. Sign-out wipes local data. A lost phone is a lost phone rather than an exposure of the organisation.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us