About

Thirty-five years of building what didn’t exist yet.

People ask how one person could build something this wide. The honest answer is the career behind it.

I've gone deep in an unusual number of fields that don't normally belong to one person.

Networks. Storage. Medical imaging. Security. Compliance. Mergers. Most people go deep in one of these and call it a career. I was doing all of them at the same time — and that turned out to be the whole reason HollywoodOS exists.

Where it starts

I was born and raised in Russellville, Arkansas. I started my first technology company there in 1989, at eighteen — Michael's Computer and Printing Service. A few years in I renamed it Micro-Designs, and it grew into a network and server company with more than fifteen hundred clients and a team of thirteen, serving medical, government, banking, distribution, and manufacturing across the state.

Early on, in 1990, I started writing software for St. Mary's Regional Medical Center. A radiology program they ran for years. A transcription program for their transcription department. And I built and installed their first local network, tying every computer in the building together — at a time when almost no one around here was doing that yet. That's where the healthcare thread really starts: not running someone else's systems, but writing the ones a hospital ran on.

Writing custom software was a through-line from the start, and not only in healthcare. A program for Tyson Foods that generated the federal forms to export food to more than sixty countries, used across the state. Barcoded inventory systems for a commissary. Different industries, same instinct — find the part nobody had automated yet, and build it.

Later, we built one of the first wireless wide-area networks in Arkansas — before wireless internet existed, before the cell companies were doing it. It covered a fifty-mile radius with Russellville at the hub, reaching Dardanelle, Pottsville, Atkins, Dover, and Hector. I contracted with the city and county water utilities to mount relays on their water tanks, and a tower company put up towers wherever I needed one. We were also putting Linux and Microsoft servers into rural Arkansas before most people had heard of either.

I earned my bachelor's and my master's in computer science at Arkansas Tech University while I was running that company. The theory and the real thing at the same time, each one sharpening the other. I think that combination matters more than either piece alone — enough formal grounding to design something properly, and enough time in the real thing to know what actually breaks.

The students I taught, I usually hired

While I was there, I set up one of the first direct relationships between an IT company and the university — a way for students to get real-world experience at my shop instead of only reading about it. The instructors would send me the ones they believed in. I usually hired them.

When one of the computer science instructors had to take medical leave, I stepped in and taught two semesters myself.

I was also the head of technology for the Russellville Chamber of Commerce — the place where a town's businesses and its government actually meet. Running the technology at that seam, between institutions, is apparently something I've been doing for a very long time.

People in a position to judge the work kept handing me more of it. That part never changed.

Cleared for all of it

In between the early company and the cardiology years, I spent two years at Arkansas Children's Hospital in Little Rock as a senior network analyst — five thousand users, three hundred servers, two hundred Cisco devices across multiple campuses.

The part I'm proudest of there isn't the scale. It's that they let me work across the network team, the server team, and the help desk at the same time — three groups they normally kept walled off from each other. In a place that careful about access, that kind of reach isn't handed out — you earn it by being someone who can be trusted with all of it.

Two Crossing the Creek awards came out of those two years. One was a problem nobody could crack: a vendor's code wouldn't talk to the hospital's entrance gates. It came down to encapsulating the serial connection over IP — bridging old hardware to a modern network. Unglamorous, and exactly right. That's the kind of problem I like.

They gave one person the keys to everything. I made sure that was the right call.

Two decades running the whole stack

Then came nearly two decades in healthcare IT. I started at Heart Clinic Arkansas — the largest cardiology practice in Arkansas, and one of the largest in the country — and over the next seventeen years it was acquired twice, into Catholic Health Initiatives and then CommonSpirit Health. My role grew with each merger. This is the part that matters most for what I built, so I want to be specific about it.

This wasn't one slice of the stack. It was almost all of it, hands-on and at depth. The Cisco network and the firewalls. The Cisco IP phone system my team ran. The servers and the storage. The medical imaging — PACS — that cardiology lives and dies on, virtualized after we were told it couldn't be done, so physicians could read echoes and images remotely, around the clock. The Citrix layer that delivered the applications. The national cybersecurity posture, with penetration testing and remediation. The national PCI compliance work. And the mergers themselves: making one organization's systems become another's without losing a record or a day.

The mergers are what led to the relationship with the national M&A team. It started with the platforms — every system our cardiology practice ran, laid out faster and in more depth than they were used to seeing at the national level. From there it grew into helping the other sites through the same acquisitions. Once you've been through an integration, you know where the next one is going to break.

Most people specialize into one or two of those for an entire career. I operated every one of them, in a regulated environment where the stakes were real, while I was also the IT director running my own office.

Identity. Records. Security. Compliance. Reconciling systems that were never built to talk. You don't read about those problems. You live them.

Why my team trusted me

I was the director, but I was never only the director. I was the most hands-on technical person in the room, and I stayed that way. That's why my team trusted me, and I think it's why the physicians did too.

You can't lead people who do hard technical work from a distance. They can tell in about five minutes whether you can actually do the thing you're asking them to do. Mine knew I could, because I was in it alongside them — not describing the work, doing it.

Trust earned by what people can verify, not by the title on a door. I believed that about running teams long before I ever built a system around it.

Authority should come from what's real and checkable. I learned that leading people, not designing software.

The range was the qualification

Here's the thing I didn't fully understand until I started building HollywoodOS. The range that never fit neatly on a résumé was the qualification.

A system that reasons across fields — that can treat a person's health, their property, their lineage, and their jurisdiction as one connected question under one set of rules — can really only come from someone who spent a career working across those seams. You can't govern across domains you've never operated inside of. You'd be guessing, and it would show.

I'd operated inside an unusual number of them. So when it came time to build a system that reasons across all of them at once, I wasn't guessing about any single one. I knew where each one breaks — because at one point or another, I'd been the person it broke on.

I didn't set out to work across that many fields. That's just where the work kept taking me. HollywoodOS came out of that.

The honest version

About HollywoodOS. It's deployed, and it's running today — not a pitch deck, not a prototype, not a diagram of something I intend to build.

HollywoodOS was designed to outlast and outlive me. The founder is an office, not a person; the rules are the thing that lasts, and the people and the parts beneath them can be swapped. I spent my whole career watching institutions quietly depend on one person remembering the right thing at the right moment. I wasn't going to build another one of those.

Thirty-five years of doing the work is the reason I could build the thing. That's the honest version.