Logger

The first app I ever designed got built without me, got a name I didn't pick, and got sold, part of a deal worth several million dollars. In 2013 every developer at MISOM was a backend engineer or an IT expert, so when the founder decided that small mines deserved a fleet-management product of their own instead of hand-me-downs built for the largest mines in the world, figuring out what it should look like fell to me. I could script but I couldn't build apps, so I found a tool that stitched wireframes into a clickable mockup and designed the thing screen by screen. Then I left for my next job. MISOM built it, called it FARA, and when the company later sold to MST Global, FARA was part of the deal. Equipment time entry is the longest-running thread in my working life, and for seven years my part in it was a stack of drawings other people made real. In 2020 I knew enough to take my own swing. This time I could build it with my own hands.

Fleet management sounds grander than it is. It is the record of what a mine's machines and people actually did all day: which loader worked which area, who ran it, for how long, moving what. Every plan, budget, and safety analysis sits on top of that record. The biggest mines capture it automatically, with dispatch systems priced for operations running hundreds of machines. Smaller mines run on paper timesheets and end-of-shift forms, to this day. I had spent most of a decade downstream of that record, and it had scarred me. As a consultant I wrestled millions of hand-entered rows from a major copper producer and a major coal producer into shape for machine-learning models, and learned that a field can sit silently broken in production for eighteen months before anyone notices. I helped another coal producer restart a stalled equipment time-entry rollout. Two things drive me nuts about most operations software: the inputs are wonky, and once the data is in, it is hard to edit. Nearly every rotten dataset I ever cleaned went rotten at one of those two spots. Logger was my run at the first.

Logger's answer is that the form is a calendar. A shift is a vertical timeline cut into 15-minute blocks. Tap the moment the work changed and a block drops onto the timeline; a card asks two questions, what were you doing and on what machine, both quick searchable pickers fed from the mine's own time codes and equipment list. Save, and the block takes the color of its category, operating green, delays blue, standby yellow, so a finished shift reads like a bar chart of the day. Tap any block to fix it or delete it. And the calendar refuses to lie about time. A new entry clamps against its neighbors and the form rejects overlaps outright, so double-counted hours, the classic shift-log rot, cannot be entered at all.

The pit dictated the architecture. Mine geometry blocks signal. There are places you cannot move data into or out of, and an entry tool that loses a shift when the bars drop is worse than paper. So Logger is offline-first. Every entry gets an ID minted on the phone and lands in a cache persisted on the device, the pick lists persist too, and whenever signal returns an idempotent upsert pushes the backlog. You log, and the app worries about when. Distribution had its own constraint. Getting anyone to install an app from a store was real friction back then, so Logger is a progressive web app: visit a link, add it to your home screen, done. Underneath sat Hasura serving GraphQL over Postgres, Auth0 for identity, and a second app, a react-admin back office whose GraphCool data provider I hand-modified to speak Hasura, managing the world behind the form: users, machines, models, manufacturers, time codes.

It was peak GraphQL season, and I was as guilty as anyone. We were all shoving GraphQL into everything it shouldn't have ever existed in. I will defend this one. Pushing the API complexity to the backend let a one-person prototype move fast, no bespoke endpoints, which is the scenario GraphQL is actually good at. It was just never the REST killer we were all selling it as.

Logger started as me proving to myself that I could build a full application, top to bottom, interface to schema, and I intended for it to become a product. What I actually learned was where the real work lived. The architecture I'd laid out didn't accommodate one of the biggest requirements, full CRUD against the data, because equipment time entry is, at its core, a content management system for time entry. By the time I understood that, I'd proven out interfaces I thought were useful and a tech stack that looked viable. Logger never met an operator, and the backend ran out its days on a free Heroku dyno with the word "learn" still in the URL. A year later I picked the idea back up as OperationSuite. That story gets its own page. What survived all of it is the belief I still design by. Five years later, I caught myself griping that commercial crop-planning software's forms were slow, wonky, and boring, and I answered the same way, with fast, purpose-built inputs, in software a real farm ran on. Operations data lives or dies at the moment of entry, so the form isn't a detail. It's the product.