Operational proof • lessons learned • field realities

Case Studies

A structured library of practical work showing how infrastructure, communications, reliability, public trust, and resilience come together.

Case studies are where the claims become visible.
Each case study is intended to show the operating environment, constraints, decisions, systems involved, and lessons that transfer into present-day technical work.

Case-study purpose

The strongest technical portfolios do not merely list technologies. They explain judgement. These case studies are designed to show how I approach communications problems, infrastructure reliability, regulatory workflows, remote environments, public-facing systems, and practical recovery.

EMCOMM

Interior Alaska storm communications

A cornerstone case study connecting prolonged infrastructure failure, amateur radio emergency communications, Alaska conditions, message clarity, and operational calm.

Open case study
MAIL

Mail infrastructure and deliverability

DNS, PTR, SPF, DKIM, DMARC, TLS certificates, Mailcow, Postfix/Dovecot, Rspamd, mobile client configuration, and the operational reality of running independent email.

COMMS

Matrix + IRC bridge infrastructure

Interoperability between decentralized chat and traditional IRC, including Synapse, bridging, identity mapping, channel behaviour, and service restoration.

EXAMS

ClearSession and Wireless Exam Gen

Regulatory workflow design, applicant registration, FCC Form 605 handling, VE coordination, accessibility, identity verification, and session integrity.

CLIENT

Aurora IRC Client

Desktop UX, packaging, dependency handling, Linux distribution support, update flow, visual state management, and communications usability.

IRCD

ColdCore IRCd and IceLink Services

Custom IRC server/services development focused on operational simplicity, services integration, user/channel control, logging, SSL, and maintainable deployment.

CLOUD

Self-hosted cloud and privacy stack

Nextcloud, Matrix, Jitsi, Vaultwarden, nginx vhosts, certificates, DNS, mobile integration, and infrastructure ownership across U.S. and New Zealand servers.

SAT

Satellite and rural communications

HughesNet, rural connectivity, Starlink planning, remote service expectations, field access, and the difference between ideal networks and practical networks.

How each case study will be written

SituationWhat problem, environment, or operational need existed?
ConstraintsWhat technical, geographic, regulatory, time, or support limits shaped the work?
ActionWhat was built, repaired, configured, coordinated, documented, or improved?
Transferable skillWhat does the case demonstrate about current capability?

Evidence templates and current status

Preview written

Interior Alaska storm communications

ContextExtended infrastructure disruption in Interior Alaska conditions.
ProblemPeople needed clear, calm communications when normal assumptions were under stress.
ActionApplied disciplined amateur-radio operating, message clarity, practical troubleshooting, and community coordination.
ResultA durable example of resilience thinking that connects field conditions to present-day ICT reliability.
LessonInfrastructure resilience depends as much on calm communication and documented judgement as on equipment.

Open Fairbanks 2015

Future write-ups

Remaining cases

Mail infrastructure, Matrix/IRC bridging, exam systems, satellite communications, and self-hosted cloud operations will be kept honest as incomplete or evolving until each case is fully written with Context, Problem, Action, Result, and Lesson.

Connection to New Zealand

These case studies are especially relevant to New Zealand because many of the same themes recur: geographically distributed communities, rural connectivity, maritime and aviation relevance, emergency communications, infrastructure resilience, open systems, practical field service, and the need for calm technical ownership when services matter.

New Zealand landscapeBrandin Hess outdoors

Expanded case-study direction

The case studies on this site are being framed as evidence of judgement, not as exaggerated claims. The intended depth for each full case is roughly 600–1000 words, with enough context for a hiring manager to understand what existed, what was constrained, what decisions were made, and what changed as a result.

Why the work existed

Each case will start with the operational reason for the work: the people affected, the systems involved, and the risk or opportunity being addressed.

Constraints and trade-offs

Good engineering happens within limits. Each case will explain time, access, support, environment, budget, knowledge, and regulatory constraints where relevant.

Decisions and implementation

The most useful evidence is not only what was built, but why a particular approach was chosen over a more complicated or fashionable option.

Outcome and lesson

Each case will close with what improved, what remained imperfect, and what lesson carries forward into future ICT, resilience, or advisory work.