Case 01 · telecom infrastructure

Inspection that works with the radio off.

PANTAU is an inspection and asset integrity platform for telecom towers, built by Gen IO for a Malaysian tower operator. Technicians record what they find at the structure on a tablet; the office reads the same records, with the evidence attached, and nothing is re-entered. The name is Malay for keeping watch, which is what the work is.

← All work

Client
Malaysian tower operator (name withheld)
Product
PANTAU — inspection and asset integrity platform
Sector
Telecom tower inspection and asset integrity
Our scope
Product design, field client, backend, operations console, deployment
Stack
Flutter · Next.js · FastAPI · PostgreSQL with row-level security · MinIO · Redis + Celery · Caddy · WireGuard
Deployment
On the client's own infrastructure, no public cloud in the path

The problem

Tower inspection is a paper-and-messaging workflow in most of the industry. A crew climbs, photographs what is wrong, writes it on a form, and someone in the office re-keys it into a spreadsheet days later. Three difficulties follow from that:

  • The site has no signal. A tool that assumes a live connection is one the crew stops using within the first weeks.
  • The photograph is the evidence. Unless it is tied to an asset, a date and a defect record, it is a file in a chat group rather than a record of condition.
  • Re-keying loses the context. By the time the office sees the defect, the detail that made it urgent has been left behind.

What we built

Two surfaces over one set of records: a tablet client the crew takes up the tower, and a console the office reads. Both write to the same rows, so there is no import step and no second copy of the truth.

The field client runs on a tablet. The technician selects the site and asset, captures photographs from the camera or the gallery, and classifies defects against a fixed taxonomy: defect type, severity, location on the structure, remarks. The survey date is fixed at capture time, so a record cannot be back-dated by accident. Where a GPS fix is available it is attached; where it is not, the record still saves.

The operations console is the office view: what was inspected, what was found, which defects remain open, and the evidence behind each one. It reads the same rows the tablet wrote.

PANTAU is in its second generation now. The pilot proved the workflow; the rebuild is about doing it well — a steadier sync engine under poor connectivity, a clearer defect model, and a console that a supervisor can work from without training.

Decisions that mattered

  1. Offline is the default, not a mode. There is no offline switch, because a switch implies the normal path needs a network. Writes queue on the device and replay idempotently, and the client shows what is still pending rather than presenting it as saved.
  2. Lock the evidence, not the workflow. Capture time and asset identity are immutable. Everything a person might reasonably need to correct — remarks, severity — stays editable, with an audit entry recording the change.
  3. Tenancy in the database. Row-level security in PostgreSQL rather than filters in application code, so a query that omits its tenant clause returns nothing instead of another operator's towers.
  4. No cloud in the data path. Object storage, database and application all sit on the client's infrastructure, reachable over an encrypted tunnel. The trade-off is that we cannot patch it at 2am without a conversation, which is the right trade-off for asset evidence.

What it does not do yet

Defect classification is entered by the technician. Automated detection from the photographs is not shipped; when it is, we will describe what it does and what it misses.

The test we build to: a technician with no bar of signal is a first-class user, not a degraded one.

Something similar on your side?

If your work happens where the network does not reach, or your records are not permitted to leave the building, that is the kind of problem we work on.