A bit about me and how I work.

I'm the IT coordinator at McCourt Equipment, a heavy-equipment dealership with locations around Texas. I'm the person on site for the technical side of things — the network, the cameras, the door access, the computers, the Microsoft environment. An outside provider handles some of the deeper server administration; the day-to-day and most of what gets built here is me.

The tool-building wasn't part of the job description. It started the ordinary way: someone needed a report that didn't exist, or a task that took four hours needed to take twenty minutes, and I was the person around to sort it out. That kept happening, and it's now a good share of what I do.

How I actually build these

I want to be straightforward about this, because it's the first thing I'd want to know if I were reading someone else's site. I'm not a trained software developer, and I didn't hand-write most of the code behind these projects. I build them working with AI tools — mainly Claude and ChatGPT — describing what's needed, reviewing what comes back, testing it, fixing what's wrong, and doing that over and over until it works.

What I bring is the part the tools don't do on their own. Knowing what the business actually needs, which usually isn't what people first ask for. Describing it precisely enough to get something useful. Noticing when the output is subtly wrong — and it often is. Then getting it onto a server, in front of real people, and keeping it working when it breaks at an inconvenient time.

A couple of examples of what that looks like in practice. The manuals system had to be built so it refuses to answer when the manual doesn't cover something, rather than producing a confident guess — because our technicians act on what it tells them. The screen sizing tool once sent a customer a report listing screen media nobody had actually chosen, and fixing that meant understanding why the two things had gotten confused and making sure they could never be again. Those calls came from knowing the business, not from the tools.

I'd rather say all this plainly than let someone assume otherwise and find out in an interview. It's how a lot of work gets done now, and I've gotten reasonably good at it.

Background

I don't have a computer science degree. I have CompTIA A+ and Network+, Ubiquiti's Full Stack Professional certification, Security+ in progress, and about three and a half years doing this full time. Before McCourt I was the only technician covering four elementary campuses for Brenham ISD, which is a good way to learn how to work things out on your own.

There are real gaps and I'd rather name them. I came to version control late — a lot of these projects are versioned by copying the folder and adding a number to it, which is exactly the problem proper version control solves. Automated testing is thin. And I've never worked on a team with code review, so most of what I've learned came from something breaking rather than someone catching it first. Those are all things I'd like to fix somewhere with people to learn from.

What I'm looking for

Networking is what got me interested in this field to begin with, and it's still what I'm most drawn to. A fair amount of the work here touches it — connecting software to network gear and physical hardware, getting servers set up and reachable, sorting out why something works on one network and not another.

More broadly I'm interested in infrastructure and internal tooling: the systems other people's work depends on. I'm not certain yet whether that means going deeper on the networking side or on the building side, and I'd be glad to talk about either.

Practical details

Based in La Grange, Texas. US citizen, clean background check, and used to travelling between sites. If you've read this far you probably have a question about one of these projects, and I'd be happy to answer it.