matthurley.dev
I design, build, and maintain practical systems for schools, hardware makers, and small teams — under real constraints, with privacy built in from the first line, not bolted on before launch.
What I Do
Every engagement starts from the same question: what does this system actually need to survive contact with real users and real constraints?
Full-stack builds from spec to shipped software — web, desktop, and mobile — with architecture decisions documented as you go, not reverse-engineered later.
Field-driven maintenance and hardening for software already in production, where the next release is judged by what it fixes, not what it demos.
Governance-aware systems with explicit access boundaries and audit trails, built for environments — schools, small operators — where trust is the product.
Desktop applications that talk to real hardware and telemetry honestly — a missing sensor reads as unavailable, never faked as zero.
Selected Work
A school platform trusted with real student wellbeing data, a hardware utility with an active community, and a client-facing desktop product built to tell the truth about what it measures.
01 / Client Delivery
Student Tracking and Recording System
A pastoral care platform built for school operations with role-based access, automated workflows, and complete audit visibility — replacing disconnected spreadsheets with one governed source of truth.
"STARS has made our processes significantly more streamlined and the immediacy of information for pastoral leaders has been exceptional."
Mr N, Pastoral Leader
02 / Open Source
Hardware control center for HP OMEN and Victus laptops
184+ GitHub stars and 13 field-driven releases since April, capped by a v4.0.0 that paid down architecture debt instead of chasing new features — 953/953 tests passing, zero build warnings.
03 / Client Product
Local-first Windows telemetry and maintenance companion
A premium desktop companion built for a real PC-building business — live thermal telemetry, maintenance tools, and a hard rule: a missing sensor is reported as missing, never fabricated as zero.
How I Work
01
Requirements are the easy part. Governance, staffing reality, and who actually has to operate this at 4pm on a Friday matter more than the feature list.
02
Narrow, frequent releases beat big rare ones. Every change should be small enough that you — or I — can actually explain why it works.
03
Software is judged on release two through twenty, not release one. Reliability, honest telemetry, and support are part of the build, not an afterthought.
About
I split my time between senior leadership at a school in South East Queensland and building the software that leadership actually needs. That dual seat — user and builder — is why the systems here are designed around real operational pressure instead of a clean-room spec.