Tower inspection that works with the radio off.
A tablet-first inspection and asset integrity platform for telecom towers, built by Gen IO for a Malaysian tower operator. Technicians capture at the structure; the office reads the same records, with the evidence attached.
- Client
- Malaysian tower operator (name withheld)
- Sector
- Telecom tower inspection and asset integrity
- Our scope
- Product design, field client, backend, operations dashboard, deployment
- Stack
- Flutter · Next.js · FastAPI · PostgreSQL (row-level security) · MinIO · Redis + Celery · Caddy · WireGuard
- Deployment
- On the client's own infrastructure, no public cloud in the path
- Status
- In delivery
The problem
Tower inspection is a paper-and-WhatsApp 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 things go wrong with that, every time:
- The site has no signal. Anything that assumes a live connection is a tool the crew stops using by week two.
- The photo is the evidence. If the picture cannot be tied to an asset, a date and a defect record, it is not evidence — it is a file in a chat group.
- Re-keying loses the point. By the time the office sees the defect, the context that made it urgent is gone.
What we built
Two surfaces over one set of records.
The field client runs on a tablet. The technician picks the site and asset, captures photos from camera or gallery, and classifies defects against a fixed taxonomy — defect type, severity, location on the structure, remarks. The survey date is locked at capture time, so a record cannot be back-dated by accident. GPS is attached when there is a fix; when there is not, the record still saves.
The operations dashboard is the office view: what was inspected, what was found, which defects are open, and the evidence behind each one. It reads the same rows the tablet wrote — there is no import step, no nightly reconciliation, and no second copy of the truth.
Decisions that mattered
- Offline is the default, not a mode. There is no "offline mode" switch, because a switch is an admission that the normal path needs a network. Writes queue locally and replay idempotently; the client shows what is pending rather than pretending it is saved.
- Lock the evidence, not the workflow. Capture time and asset identity are immutable. Everything a human might reasonably need to correct — remarks, severity — stays editable, with an audit entry.
- Tenancy in the database. Row-level security in PostgreSQL rather than application-level filters, so a query that forgets its tenant clause returns nothing instead of someone else's towers.
- 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 correct trade-off for asset evidence.
What it does not do yet
Defect classification is human-entered in the pilot. Automated detection from the photos — the obvious next step, and the one everyone asks about first — is not shipped, and we would rather say so than show a demo that flatters it.
The test we build to: a technician with no bar of signal is still a first-class user, not a degraded one.
Also ours.
Padu OS
The on-premise AI operating system for Malaysian business: planning, automation, data and AI departments on one set of records, on hardware the customer owns.
Gen IO Hub
Our own ERP — sales, projects, timesheets, invoicing with SST, double-entry ledgers in MYR, payroll, assets and banking. We run Gen IO on it, which is the only reference we trust.
Something similar on your side?
If your work happens where the network doesn't, or your data is not allowed to leave the building, that is the conversation we are good at.