OperationSuite

Small mines run on spreadsheets. A shift report gets filled out on a clipboard, keyed into Excel at the end of the week, and emailed to whoever asked for it last. The fleet-management systems that solve this at the majors are priced for the majors, so everyone else improvises, and I had spent years of consulting being paid to untangle what the improvising produced. I'd seen an ERP pressed into service as a data warehouse. I'd seen numbers that fed real decisions sit quietly wrong for months because no system existed to notice. Every engagement started with the same archaeology, digging operational truth out of files never built to hold it.

OperationSuite was my answer, and the strangest fact about it is that nobody asked for it. Every other project in my career arrived as a pull, someone calling me with a problem. This one I pushed. I had carried the idea for years: one standardized data layer for an entire operation, a clean model of the whole business that any interface could be built on top of. Capture the data correctly at the source, through forms built for the people doing the work, and reporting stops being archaeology. So I built it on my own dime, a year of nights and weekends around the day work.

A platform this size is normally a team's job. What made it buildable by a one-person team was making smart technical decisions up front. I knew an app like this had a few pieces that get complicated fast. User permissions and management. The pile of CRUD interfaces for every operation the business needed. And the backend API feeding all of those interfaces, wired through the permissions. So before writing much of anything, I went looking for tools that would take those problems off my plate.

The first thing I came across was Hasura, young at the time, back when GraphQL was all the rage. Hasura let you essentially mock up your database and automatically generate the entire GraphQL API from it, or drive the whole thing from a GUI, API-spec first. And it had a killer feature. It made it easy to wrap in an external auth provider, Auth0 in my case, and to define permissions at each layer of the GraphQL schema, which is a notorious pain. It's still one of the best solutions I've seen for permissioning a GraphQL API to this day.

The other piece I landed on was react-admin, the first modern component-driven React framework I ever worked with, batteries included but removable, whole pieces of UI passed in as props. It made creating CRUD interfaces an absolute dream, fully featured and incredibly customizable, and it let me punch above my weight class. At the end of the day I had a backend and admin interface spanning 26 tables that covered the whole operation: crews and people, equipment down to model and manufacturer, shifts and shift reports with a workflow where operators submit their work and managers approve it, downtime by cause, material movements from the pit through the wash plant, meter readings, safety events, maintenance forecasts.

The other big piece was an idea I cared about. Every site does things a little differently, and fitting into their workflows felt important, so the plan was bespoke interfaces for each site. Let a site import shift reports in the format they already produced, key in their paper reports by hand, or use AI to pull the data off the paper forms they already ran on. We stubbed out a couple of these for a real site, built from their actual shift reports, all feeding the same backend. The why goes back to my MISOM days. From a technical standpoint, Excel is a terrible place to build an application. But the closer you build your application to the workflow the customer already uses, unless you have a really important reason to move away, the better your adoption is going to be.

None of these tools fit perfectly out of the box, and bending them is where the engineering lived. Hasura hard-deletes records by default, and in an operational record gone should mean hidden, never lost, so I remapped deletes into updates across the whole API. react-admin's Hasura adapter only fetched flat records, so I rebuilt its query layer to splice nested relations into every fetch. Every one of those fights was winnable because the stack had been picked to be bendable. That's what made it smart from the get-go.

There was one more problem. I needed data to demo with, and I didn't have a site on board yet. So I built an entire Jupyter pipeline that generated a synthetic operation, using Faker to stub out the records, fake crews running fake equipment hauling fake tons on realistic trends. A prospective site could see exactly what their data would look like in the system, what a shift report would look like, what a dashboard would look like, before ever handing over a single number.

Then I went to sell it. A friend of mine was at an aggregate mine in Arizona, and they agreed to have me come out to site so I could make the case for what we were trying to do. I ran the old MISOM playbook for the technical side: go to site, walk the processes, find where the data actually lives. I recreated their shift-report forms inside the platform, catered the build to how their operation ran, deployed the whole thing on DigitalOcean, and demoed a real, running app. There were a couple of site visits, but unfortunately we never got to a full pilot. The reality was that the product was technically good, but it was a push more than a pull. It wasn't a bleeding need for this company, and I just didn't have the sales chops to close the deal.

What I understand now, and didn't then, is that selling is a skill the way engineering is a skill, and I had given it none of the respect I'd given the schema. No pipeline, no process, no hard look at whose burning problem this actually was. Aggregate mining is a tough room to sell into, low margins and a lot of moving pieces, and a good solution to a problem an operator has learned to live with is still a no. My verdict, years later: I should have solved a better problem, and I should have sold it better, because it would have helped the organizations that needed it. I put OperationSuite on the back burner and went where the pull was.

What the year left behind is real. It was the first piece of software I built to the point where I could genuinely have stood it up for a company, the whole platform, schema to auth to both frontends, alone. And the conviction hasn't moved: most of this industry still runs on spreadsheets, and it deserves better.