Argotemp

Context#

Argotemp runs equipment rentals and the maintenance that comes with them. The operations team needs to know what is out, what is coming back, what is broken, and what to bill, all without a fragile spreadsheet seam between any of those questions.

Operations and state machines#

A unit is a small state machine with three states: available, hired, in maintenance. A rental is not. Rentals have no status column at all. A job is an append-only linked list, where each row points at the one it superseded and two booleans say whether it has been retired and whether it has a successor. Renewing a job creates a new row carrying the same job number, client, location and attached units, starting exactly where the old one ended, and retires its predecessor in the same transaction. Nothing is ever mutated in place, so the whole rental history stays readable back to the first hire.

The two machines have to agree, because the expensive failure is a unit sitting in the workshop that the system still thinks is rentable. Ending a job, and ending a maintenance record, are each a single transaction that closes the record and returns the unit to available in the same commit. A nightly job sweeps for rentals whose end date has passed, retires them, and frees their units, so the reconciliation happens eagerly on every transition and lazily once a day as a backstop.

Billing lifecycle#

Invoices hang off the rental as first-class records rather than a parallel spreadsheet, each carrying its expected collection date beside its actual one, so how late the money arrives is a query rather than a memory. Rental duration is derived from the job's own dates instead of being stored, which means an extension or a renewal cannot leave a stale number behind it.