Case · field operations

Man-hours per technician, on every vessel

A service company sends technicians to support its clients' vessels and bills them by the man-hour. Those hours used to come from whatever each technician wrote down. Now every vessel has a QR code stuck on board: technicians scan it with their phone when they board and when they leave, which records the time and the location. They have to be on the vessel to clock in. Those scans add up to each technician's hours on each vessel, used to bill the client and pay the crew, and the office sees on a map who is on board right now.

What the map shows

The map only plots open attendance records: the ones with a clock-in and no clock-out yet. It shows who is on board right now.

Dashboard with a map of the Peruvian coast and, below it, the list of technicians on board with their vessel and their clock-in time — The dashboard: the map with whoever is on board at this moment and, below it, the table with their vessel, the company and the clock-in time. Every row has a button to center the map on that position.

Man-hours report per technician and vessel — **Man-hours per technician and per vessel.** This is the number that justifies the system. It is calculated from the clock-in and clock-out records, so nobody types the hours in by hand.

List of work orders with their status — The work orders and their status. Work in the field is closed against an order; otherwise the hours do not tie back to anything.

Permissions per resource

A technician, a supervisor and whoever does the invoicing need different screens of the same system. Permissions are granted per resource and grouped into roles, and the frontend router honors that same list: if you do not have the permission, the screen does not exist for you.

How it is built

A Node API with Express and Prisma on MySQL, a React frontend built with Vite, and the map with Leaflet over open tiles. All of it in containers.

Node · Express
Prisma
MySQL
React · Vite
Leaflet
Docker

Running it outside the client's network

These screenshots come from running the whole system outside the client's infrastructure, with made-up data. This is what turned up along the way:

The list of allowed origins was written into the code, with the client's domains in it. From anywhere else, the system answers with a server error that does not say what is wrong. That belongs in an environment variable.
A master permission that opens every route is convenient while you are developing, and it has to be reviewed before handing out real roles.
The development server is not the production one. Building and serving with nginx, as on the real server, removes a whole class of surprises.

Do you have people working where the office does not reach?

Work reports, clock-in with location, orders closed out in the field and a number you can trust at the end of the month. You can have that without chasing anyone on WhatsApp.

Let's talk →