Enterprise architecture, custom software, and data systems for organizations running complex operations.
The best system is the one that fits the problem — not the one tied to a single platform. We help close the gap between what's actually happening in the field and what leadership can see, measure, and act on.
Built for operations, not just offices
Our work concentrates in industries where field execution and office reporting drift apart — and where getting that connection right is worth real money.
Exploration, development & production
Field data capture, cost-per-metre tracking, safety and compliance systems, and reporting that connects underground execution to office-level decisions.
Transmission & substation construction
Project controls, estimating, and field-to-office reporting for utility-scale transmission line and substation work — built from direct experience running that work.
Any field-heavy, data-heavy business
Manufacturing, construction, environmental services, and other industries where crews in the field generate the numbers leadership needs to run the business.
How we judge whether something worked
Three tests. Everything we build has to pass all three before it's considered done.
It has to remove steps
We count the steps a task takes before and after. If we haven't removed several, and if the same number still gets entered twice, we've built a different way of doing the same work — not an improvement.
It has to be obvious
We hand it to someone who's never seen it, with no training and no manual. If they can't complete the task in minutes, it isn't finished — and we test with the person actually doing the work, not the person most excited about technology.
It has to be built so AI can reason about it
Bad data should be structurally impossible to enter, not merely caught later. And every system we build is modeled clearly enough that AI can genuinely reason about it — not just search it.
"We'd rather deliver a working prototype than a slide deck — and we'd rather tell a client to buy an existing product than build them something worse."
Ownership
Your systems stay yours
Everything I build runs inside your own Microsoft tenant. Your data, your environment, your ownership — I don't host it and I don't hold it.
You keep the files
You receive the solution files and the documentation, not just a login. If we stop working together the system keeps running.
Access you control
My access is delegated and revocable in one click, and every change I make is logged where you can read it.
A thirty-day handover
If you want out, you get everything a successor needs within thirty days. No conditions and no exit fee.
I've seen operations held hostage by whoever owned the database. That isn't a business model I'm interested in. Why I think you should own your own data.
Background
Cronk Companies LLC is built on direct field and project experience across several industries, not just a technology background applied from the outside.
Currently, I work full-time as a project manager and estimator in the power delivery sector, specifically transmission lines and substations — running the same estimating, cost-tracking, and field-to-office reporting problems this practice is built to solve.
Earlier I did field exploration and sampling on a mineral exploration project in Nunavut, out of a remote fly-in camp, and assisted in the core processing facility. Before that, core processing and field support on a uranium exploration project in Colorado, and contract grid line-cutting for geophysical surveys in northern Minnesota.
I also spent years on the clinical side. I hold a bachelor's degree in human biology, taught biology as an adjunct professor, worked as an athletic trainer alongside physicians and professional athletes, and practised as a chiropractor. I never subscribed to the adjustment philosophy — what interested me was biomechanics: how a body moves, how it compensates, and why every patient needs a solution built for them rather than a protocol applied to them. I no longer practise. My wife runs the clinic now and I help on the technology side.
And before all of it, I was 21 years old and serving overseas when I was asked to help with casualty reporting in Iraq. I inherited a pile of data that did not agree with itself. I built a spreadsheet. That spreadsheet ended up in front of people whose decisions depended on those numbers being right, which is not a thing I expected and not a thing I have forgotten.
That range — construction and utilities on one side, mining and exploration geology on the other, technology and data systems tying it together — is exactly why this practice isn't built around a single industry or a single software platform.
I've also spent years on the clinical side: practising as a chiropractor, teaching human biology, working as an athletic trainer alongside physicians and professional athletes, and running a clinic with staff — scheduling, billing, insurance reimbursement and the operational detail that goes with it.
Across exploration camps, a clinic, a lecture hall, a war zone and a substation estimate, one thing has never changed: all anyone wants is good information they can trust. That is the whole job. Everything else is plumbing.
Experience
Writing
Notes on the work
Occasional pieces on why these systems succeed or fail. Mostly drawn from having been on the other end of them.
Why you should own your own data
Most vendors end up holding their clients' data. It is a business model, not a technical necessity — and five questions worth asking anyone who builds for you.
The camp and the spreadsheet
Field sampling out of a fly-in camp, then writing estimates from other people's records. The distance between those two jobs is where the money goes.
Nobody is doing your exercises
Clinicians know most patients skip the home programme. The same four things decide whether your crew uses the software you bought.
Get in touch
If your business has a gap between what's happening on the ground and what leadership can see, that's the conversation worth having.