Dalton
I'm the founder, engineer, designer and — on a good weekend — the support desk behind Restless Mind Technologies. I've spent about fifteen years turning messy, real-world domains into software that quietly does its job for years at a time. I also race.
One trick, run on repeat
Find a corner of the world with rules nobody's bothered to model properly — fire code, flight-duty limits, the scoring math of a twenty-four-hour race — learn it until it's boring, then turn it into software that's correct enough to disappear into the work.
Do that well and people stop noticing the software at all. They just notice that the thing they have to do every day got quietly easier. That's the whole job, and it's the one I keep coming back to.
A fire-alarm app and a borrowed degree
My first real product was a fire-alarm inspection system I built for my dad's company while I was supposed to be paying attention in college. It encoded the parts of NFPA 72 the techs actually wrestle with, generated the reports they had to hand to inspectors, and ran for five-plus years with effectively zero maintenance — long enough that management tried to replace it and couldn't make the case.
The degree was almost an accident. I didn't really want to be there, I was already shipping software on the side, so I followed friends through CS, CE and EE classes and walked out with a computer engineering degree and a habit I never kicked: build the thing once, build it right, watch it just keep working.
Different rulebooks, identical job
Since then the same skill has shown up in three unrelated places — fire-safety inspections, aviation crew-duty scheduling, and endurance racing. Take a fuzzy domain that lives entirely in someone's head and make the computer understand it without ever getting it wrong.
It turns out modeling the FAA's duty-hour math and modeling pit-stop penalties are the same problem wearing different clothes. Most engineers never get to do this once. The pattern of my career is getting to do it over and over.
The entire engineering department of a racing series
For the better part of a decade I've quietly been the whole technical org behind an endurance racing series. Live timing and scoring pulled straight off the hardware, RFID read over cell modems trackside, a custom server I wrote just to time pit stops, registration and payments, and the messaging that keeps a paddock of two hundred teams pointed the same direction — all of it mine, all of it still running, basically crash-free, across years of race weekends.
GridPulse is what happens when you take everything you learned doing that the hard way and decide to build it properly, for everyone else. I'm not guessing at this market from a spreadsheet. I'm in the paddock.
Make it work, make it right, make it fast
In that order. I build to find the real shape of a problem, then delete most of the first attempt once I can finally see it clearly. I care about the whole thing — architecture, interface, and all the unglamorous edges in between — because that's exactly where software earns trust or quietly loses it.
And I genuinely cannot leave a finished thing alone. Every "done" just looks like a better place to start. Which is, more or less, why the studio is called a restless mind.
Still around cars
When I'm not building, I'm usually still near a track — in a race seat at an AER event, or in the sim chasing tenths on iRacing. The rest of the time it's game-design notebooks I may never ship and a trading-card habit I'm not going to defend.