A shared workbook, replaced end to end
Sierra Transport hauls municipal solid waste and biosolids in the Central Valley — their own trucks plus contract haulers alongside them. Every truck that runs produces a scale ticket, and every ticket has to end up on a run sheet the office can bill from. That ran on a shared Excel workbook: one file, one person in it at a time, the tonnage typed twice, the tickets in a folder or a phone somewhere else, and no way to answer “did that load ever get billed?” except by scrolling. The portal replaces it end to end, on the client’s own hosting, in daily use since September 18.
The day, at a glance
The first screen is a list of what actually needs doing: loads waiting to be checked, tonnage not yet entered, tickets not yet matched, days ready to close. Not a dashboard of charts — a list of work. When the list is empty, the day is done.
Dispatch, against what came back
What each hauling company was asked for that morning, next to what actually arrived. The day’s lineup imports straight from the dispatcher’s own spreadsheet — the file the operation already produces — and each row finds the driver it belongs to.
That one screen answers the question the workbook never could without a phone call: who was short today, and by how much?
Tickets from the gate
Drivers and contract haulers photograph the scale ticket at the gate and send it in. It lands in the office inbox, gets matched to its load, and the load can then be proved — the ticket lives with the load it belongs to, not in a folder or on somebody’s phone.
Images are converted to PDF on the way in, so every ticket in the system is one kind of file.
It runs from a phone, properly
The driver’s view is not a squeezed-down desktop. It is his run, his truck, his loads, and nothing else — and no money anywhere on it. A contract hauler’s driver sees his own work; he does not see the rest of the yard, and he never sees a rate.
In a company that hires its competitors, hiding per-load money from everyone who has no business with it is the difference between a tool people use and a tool nobody is allowed to open.
Reporting that answers a question
Tonnage by trailer type, by hauler, by month — walking floors compared against walking floors, possum bellies against possum bellies, because comparing a truck to the whole yard tells you nothing about the truck.
One report shows the spread beside the average, because an average on its own cannot tell an unlucky week from a habit. And a finished day is finished: closing a day locks its loads, so nothing about it changes afterwards by accident and the invoice matches what was agreed.
Craft details
Light, dark and auto — per person
Every screen designed twice rather than inverted, chosen in each person’s own preferences. The screenshots on this page follow your device’s theme the same way the portal does.
Who’s on
A panel showing who is in the system right now and what device they are on, with a button to message them without leaving the page — the portal has its own built-in messenger.
Taking it down on purpose
A maintenance window signs everyone out, shows a countdown, and lets them back in by itself when the work is done. Nobody has to be told to refresh.
No framework, no build step
One stylesheet, one script file, no CDN, no npm — the same way this very site is built. It loads instantly on a phone with one bar in a yard, which is where it is actually used.
Built to be broken into
Four rounds of audit in the portal’s first eleven days live — two of them adversarial reviews commissioned specifically to find what the build had missed. Twenty-eight findings across the four. Every one fixed, and every one given a regression check written to fail against the old code — so the same mistake cannot come back quietly. This is what taking someone’s operational data seriously looks like. Three of those findings, in plain language:
A refund that reversed too much
A partial refund on one card payment was reversing every payment on the invoice, so the next checkout asked the client for money they had never got back. Now a refund is tied to the single capture it came from.
A checkout left open in a browser tab
An approved card payment collected the balance as it stood when the tab was opened — so a check recorded in the office in between could be collected twice. Now the balance is re-read and the payment claimed together, and the invoice is reserved for as long as the card payment is in flight.
A purge that took a month it wasn’t asked for
Clearing out January’s ticket photos could take February’s with them, because the photos were grouped by the day they were uploaded, not the day the load ran. Fixed, with a check that would fail the old behaviour forever.
How it is built
Nothing exotic, everything deliberate — chosen so the system runs for years on ordinary hosting with nothing to keep alive.
- PHP 8.4, server-rendered
- SQLite, one database per client
- Versioned migrations, applied automatically
- Nightly off-site backups
- No containers, no queue, no Redis
Four independent test suites
- The portal itself — 831 automated checks on every release
- A fresh install, stood up from the update bundle
- The web-server configuration
- One that proves two clients on the same server cannot reach each other’s data
Built for one operation — the way yours could be
The portal is a private internal system — there is no public demo, and every screen above shows invented demo data. What is real is the shape of the work: an operation that ran on a shared workbook now runs on a system built around its own process, audited on purpose, and maintained by the people who built it. Similar systems suit any operation where the same information is being typed twice.
- Custom internal systems
- Hand-coded business sites
- Hosting & maintenance
- Independent security audits
- Built in Bakersfield