Industris Pro
The plant's production report, filled in at the machine and written into its own spreadsheet without breaking a formula.
What it does
The plant ran its daily production report as one very large Google Sheet: more than 25,000 rows and over 80 columns, with formulas that look up each part's customer, cycle time and hourly target, and total every rejection and idle minute. The sheet already behaved like software. The weak point was the typing.
Industris Pro moves the typing to a phone at the machine. An operator scans the machine's QR label, picks the part and operation from the plant's master list, and presses Start. Hours later the same job is ended with output, rejections and idle time. Behind each tap, the system writes only the input cells of a row it owns, then checks that every formula in that row still holds and still adds up.
The plant keeps every report it already trusts, and gains what a spreadsheet cannot give it: logins and roles, one running job per machine, a record of who entered what, drawings at the machine, and a way back when the internet drops.
The pilot writes to an isolated copy of the report. Moving to the real one is a single switch, guarded by a seven-point readiness check.
machines, each with a printed QR label
operators, synced from the sheet every minute
rejection and idle reasons, one tap each
rows in the live report it writes into
input cells written per job, and nothing else
formula columns checked before and after every write
checks before the switch to the real report
automated tests on the system itself
Before
- Each job was typed by hand into one large shared spreadsheet.
- Cycle times and targets were looked up, then typed again.
- Drawings sat in a Drive folder, away from the machine.
- The supervisor's end-of-shift report was written by hand.
After
- The operator scans the machine's QR label and presses Start.
- Customer, cycle time and the hourly target fill in on their own.
- At the end the operator enters output, rejections and idle minutes.
- A lost signal cannot create a duplicate entry.
- The part drawing opens on the phone, at the machine.
- The shift report builds itself and goes to WhatsApp.
A job, start to finish.
Scan
The operator scans the machine's QR label. The server looks the machine up; the phone is never trusted to say which machine it is.
Choose
Only parts and operations that fit the machine's category are offered, with customer, cycle time, load time and targets shown to confirm.
Start
One tap creates the job under a one-time request id. The database allows one running job per machine.
Write
In the background, the start goes into one row of the plant's report that the system has claimed and marked as its own.
Run
The part drawing opens on the phone, and supervisors see every running machine on one screen.
End
Output, rejections and idle minutes, one tap per reason. Rejections can never exceed output, and the stop time must fall inside the job's shift.
Verify
The same row is updated, read back, and its formulas and totals checked. A failed write retries itself after 1, 2, 5, 15 and then 60 minutes.
Rate
The phone rates the run good, average or poor from its efficiency and rejection rate.
Inspect
Finished pieces go to pre-delivery inspection at one of six QR-labelled tables, counted OK, rejected or reworked.
How it is built.
Where people work
Phone app
Android and iPhone, for operators and supervisors at the machines and for the inspection tables.
Web console
People and roles, machines with printable QR labels, the report switch with its readiness check, and the inspection tables.
Where the rules live
One database
PostgreSQL with row-level security: logins, roles, machines, running jobs, the record of who entered what, row claims and the retry queue.
Server functions
Ten of them hold every rule and every key. The phone never holds a Google credential or a Drive link.
A scheduler
Every minute it re-syncs machines and operators and retries any write that is due.
What it connects to
The plant's Google Sheet
Still the factory's record, and still calculating. Written only in input cells, and only in rows the system owns.
Google Drive
Part drawings, streamed through the server with a short-lived token.
WhatsApp
The end-of-shift report, posted as one PDF to the plant's group.
The hard parts.
Writing into a live spreadsheet without breaking it
The system writes 32 input cells across a job's row and nothing else. Before each write it checks the header row and the formula cells; afterwards it reads the row back to confirm every value landed and that the sheet's own totals for rejections and idle minutes came out right. If the layout has moved, the write stops with a plain error instead of filling the wrong column.
Under the hoodHeader verification, formula checks before and after, read-back reconciliation.
Every row has an owner
Rows are claimed one at a time inside a database transaction, separately for each workbook, and each carries a marker naming the job that owns it. A row holding someone else's marker is a collision and is never overwritten. A row with a missing formula is set aside and the next one tried, and a retry rewrites the same row, so no blank row is left behind.
Under the hoodAtomic row allocation, ownership markers, collision and unusable-row tracking.
A weak signal cannot make a duplicate
Every Start and End carries a one-time request id, so a lost reply followed by a second tap finds the same job instead of creating another. Retries hold a lease, so two workers can never write competing rows, and the database itself allows only one running job per machine.
Under the hoodIdempotency keys, phase-bound leases, a partial unique index.
The phone never waits for Google
Start and End reply the moment the database commits. The sheet is written in the background, and if Google is slow or down the write retries on a schedule while the phone says plainly where the entry stands: being written, in the report, or retrying on its own.
Under the hoodBackground tasks, timed retries with backoff, recovery of abandoned leases.
The sheet's own dropdowns are the master list
Every minute the server follows the sheet's dropdown rules back to their source and syncs machines and operators from them. A read that is partial, still loading, or would shrink a list by more than half changes nothing. On the first sync, all 61 machines and 182 operators matched the sheet letter for letter.
Under the hoodScheduled sync, data-validation tracing, shrink guards, archiving instead of deleting.
Time that knows the shifts
The plant runs a day shift and a night shift on Indian time, and a night job started after midnight belongs to the previous working day. A stop time outside the job's own shift is refused by the phone, by the server and by a database trigger, because the sheet's formulas would otherwise turn it into negative minutes.
Under the hoodTimezone-bound shift windows, three layers of validation.
Drawings at the machine, without opening the Drive
The server fetches each part drawing with a short-lived Google token and streams it to the phone. Raw Drive links never reach the phone, oversized files are refused, a copy is kept for the job so it reopens without the internet, and everything is wiped at sign-out because the phones are shared.
Under the hoodServer-side token exchange, authenticated streaming, a per-job cache.
A switch with a seven-point check
Moving from the test copy to the real report is one switch, and only the owner presses it. Before it will turn, the server checks edit access, the column headers, protected cells, the dropdown lists, rows left, formulas in the next thousand empty rows and the rows the system already wrote. Any failure keeps it off, and every switch is recorded.
Under the hoodA read-only readiness check, a typed confirmation phrase, an audited switch history.
Department by department.
Operators
- Sign in with a mobile number
- Scan the machine, pick the part and operation
- The part drawing opens on the phone
- A rating after each job: good, average or poor
- Several machines at once; each machine runs one job
Supervisors
- Start and end jobs on behalf of an operator
- Times entered on wheels and checked against the shift
- Every running machine on one screen
- Retry any entry that failed to save
Pre-delivery inspection
- Six inspection tables, each with its own QR label
- OK, rejected and reworked counts for each batch
- In-house and bought-in parts, named by item code and part name
- A job stays listed until every good piece is checked
Office
- People, roles and photographs
- Machine list with printable QR labels
- Shift QR access for operators, ready to switch on
- A readiness check before switching to the real report
Reporting
- The existing spreadsheet formulas stay in charge
- Machine and operator lists re-sync every minute
- A shift report PDF on WhatsApp at 9 pm and 9 am
How it was tested
- 95 automated tests, from the sheet-layout reader to the readiness check and the shift report.
- Every migration applied from scratch to a disposable PostgreSQL database, with a harness of 15 behaviour groups that includes two administrators racing each other.
- Database rollouts rehearsed on the live project inside a transaction that was then rolled back.
- Every server function checked to refuse a caller without a login or the scheduler's secret.