I am a systems engineer, developer, infrastructure builder, audiovisual technologist, U.S. Navy veteran, longtime Dungeons & Dragons player, amateur chef, father, and habitual collector of projects that begin with:

“This should be fairly straightforward.”

It rarely is.

I have worked across cloud infrastructure, Linux, Windows, identity systems, WordPress, databases, automation, audiovisual systems, and enough half-documented legacy environments to have developed strong opinions about backups, access control, and people who name production servers after fictional characters without documenting which one runs payroll.

These days, I am especially interested in building practical AI systems that do real work instead of generating twelve paragraphs about how excited they are to help.

An email-management platform for people whose inboxes are simultaneously organized, disorganized, important, irrelevant, and best left unopened until observed.

The goal is to help users regain control of email without demanding that they immediately delete, archive, label, categorize, prioritize, meditate over, or emotionally reconcile with every message they have received since 2007.

I am building a self-hosted development and automation environment using:

• Kubernetes
• Rancher
• Longhorn
• Raspberry Pis
• Mini PCs
• Local and cloud storage
• n8n
• AI agents
• Slack-based management
• Infrastructure as code

The system is intended to support software development, browser automation, research, recurring operations, self-hosted services, and whatever else I decide nine computers and a suspicious number of USB drives ought to be doing at 2:00 a.m.

I help maintain and modernize technology for Utah Hockey, including:

• WordPress infrastructure
• Statistics and schedule integrations
• HockeyTech data
• Team and player information
• Broadcast-support tooling
• Cloud hosting
• Content workflows
• Digital operations

Sports organizations should not need an enterprise software budget to have reliable infrastructure, current statistics, and a website that does not collapse under the weight of twelve years of plugins.

I am experimenting with AI systems that can:

• Assist with software development
• Coordinate projects
• Perform repetitive browser tasks
• Manage documents and information
• Support research
• Automate operational work
• Communicate through tools people already use

I am less interested in artificial intelligence as a parlor trick and more interested in whether it can complete the irritating task everyone has quietly ignored for six months.

Linux                AWS                  Kubernetes
Docker               Rancher              Longhorn
Terraform            GitHub Actions       NGINX
Redis                WordPress            PHP
Python               JavaScript           SQL
PowerShell           Bash                 n8n
Unifi                Microsoft 365        Google Workspace
AV systems           APIs                 Questionable legacy code

I have also worked with VMware, Windows Server, Active Directory, PKI, Drupal, GCP, Crestron, Extron, Yealink, Zoom, databases of uncertain provenance, and vendor platforms whose documentation appears to have been translated from another language by a fax machine.

A system that is technically impressive but miserable to operate is just an expensive demonstration.

People should make decisions. Computers should move files, reconcile data, run checks, generate reports, and perform the sort of repetitive work that slowly turns a competent employee into a person staring silently into the middle distance.

Documentation is not complete when the person who built the system understands it.

Documentation is complete when someone else can repair it while the person who built it is unavailable, unconscious, or refusing to answer Slack.

I prefer systems that can be understood, moved, backed up, repaired, and operated without begging a vendor to unlock a feature hidden behind the Enterprise Platinum Synergy tier.

I am not opposed to paying for good tools.

I am opposed to paying $800 per month for a dashboard wrapped around three cron jobs and an API endpoint.

Real systems have budget limits, old hardware, incomplete documentation, conflicting stakeholders, unexpected dependencies, and one plugin that cannot be removed because no one remembers what it does.

Architecture diagrams are useful. So is accepting that production has opinions.

• I served in the U.S. Navy as a Cryptologic Technician.
• I have worked in infrastructure, cloud engineering, identity, systems administration, web development, and audiovisual technology.
• I am a father, which is excellent preparation for incident response.
• I have played Dungeons & Dragons for roughly 30 years, so I am comfortable managing unpredictable groups with unclear requirements.
• I enjoy cooking, travel, technology, and solving problems that probably should have been solved before they reached me.
• I believe small organizations deserve dependable technology, even when they do not have enterprise budgets.
• I believe “temporary workaround” is one of the most durable materials known to engineering.

I am currently focused on:

1. Building Schrödinger’s Inbox
2. Developing a manageable home-lab AI platform
3. Creating repeatable agentic development workflows
4. Modernizing Utah Hockey’s technical infrastructure
5. Publishing useful scripts, documentation, and deployment patterns
6. Turning several years of scattered ideas into functioning products
7. Avoiding the creation of any new “quick side projects” until at least three existing ones become self-supporting

The seventh item is not going particularly well.

Some repositories here contain active software.

Others contain infrastructure designs, migration work, prototypes, documentation, experiments, or the digital remains of an idea that seemed brilliant after midnight.

Each repository should explain its current status, setup process, dependencies, licensing, and whether anyone should reasonably trust it near production.

When it does not, assume I am still working on that part.

Thoughtful issues, fixes, testing, documentation improvements, and pull requests are welcome on projects that are open for collaboration.

Please describe:

• What problem you are solving
• Why the change is needed
• How you tested it
• What it might break

“Improved several things” is not a change description. It is a threat.

Please do not publish credentials, tokens, private keys, personal data, production configuration, or customer information in an issue.

If you discover a security vulnerability, report it privately using the instructions in the affected repository.

If the affected repository does not yet contain reporting instructions, that is a documentation bug, not permission to post the exploit publicly with a celebratory GIF.