Projects should show how an engineer thinks
Selected work explained through context, problem, approach, outcome, and lessons learned.
Projects as evidence of engineering judgement
The projects below are presented as miniature case studies. The point is not only what technology was used, but what constraint existed, what decision was made, and how the result improved supportability or resilience.
Aurora Radio Mail
Context: Linux-first amateur radio messaging for remote and resilience-focused communications.
Problem: Existing workflows can be difficult for lightweight Linux systems and field operators.
Approach: Build a maintainable platform around practical session handling, gateway selection, forms, and Linux-native operation.
Outcome: A project that turns communications experience into a more usable field tool.
Lesson: Resilient communications tools must be understandable by operators, not only developers.
Ready Signal Web Infrastructure
Context: A professional evidence portfolio and engineering practice site.
Problem: The site needed to demonstrate judgement, not merely list skills.
Approach: Rebuild around doctrine, image-led page identity, open-source typography, and maintainable static content.
Outcome: A clearer employer-facing presence aligned with long-term New Zealand contribution.
Lesson: Documentation and presentation are part of technical credibility.
Self-hosted Communications Stack
Context: Personal and professional infrastructure involving Linux services, DNS, TLS, mail, and collaboration systems.
Problem: Services must remain maintainable, recoverable, and understandable without relying on vague vendor abstraction.
Approach: Use clear service boundaries, documented configuration, disciplined updates, and practical monitoring.
Outcome: Stronger operational ownership and deeper infrastructure understanding.
Lesson: Self-hosting matters when it demonstrates responsibility, not ideology.
Wireless Exam Gen
Context: Tools for amateur radio education and testing support.
Problem: Volunteer-led environments need simple tools that reduce administrative friction.
Approach: Build focused utilities around the actual workflow rather than unnecessary platform complexity.
Outcome: A practical support tool aligned with mentoring and service.
Lesson: Useful software often begins by respecting the volunteer's time.
How to read these projects
These projects are not included merely to show tools I have touched. They are evidence of how I think through constraints, design for supportability, document decisions, and connect technology to people who depend on it. The strongest lesson across them is consistent: good engineering should leave a system easier to understand, easier to recover, and more useful than it was before.
Infrastructure ownership
Self-hosted services, web platforms, DNS, certificates, mail, backups, monitoring, and documentation demonstrate day-to-day operational responsibility.
Communications continuity
Radio, satellite, messaging, rural communications, and emergency communications work show how technical systems support coordination when ordinary assumptions fail.
Documentation as evidence
Project notes, deployment records, configuration discipline, and public-facing explanations show the ability to make technical work understandable.
New Zealand relevance
The work aligns with employers needing practical infrastructure judgement, regional awareness, client communication, and maintainable systems.