Lead Software Engineer - Voltex Electrical

We are building Ora — a connected device ecosystem for professional electrical installers and homeowners. The architecture is deliberately two-phased, and the Lead Engineer must hold both phases clearly from day one. Phase 1 launches with a strict privacy-first, local-first philosophy: the Hub is the brain, the cloud is a relay. Cloud connectivity is disabled by default. The backend does not store device state, does not process command logic, and does not inspect device payloads. It routes encrypted packets, manages installer workflows, and stays out of the way. Phase 2 expands into full cloud connectivity — remote device access, live streaming, and cloud-to-device control at scale. This is a fundamentally different architecture from Phase 1, and the single most important design constraint on the Lead Engineer is this: Phase 1 must be built in a way that does not make Phase 2 a rebuild. The foundations laid now — data models, identity architecture, relay infrastructure, security posture — must extend cleanly to full cloud connectivity without structural rework. This is not a role for someone who has only built relay systems, or only built full-cloud IoT platforms. It is a role for someone who has built both, understands the transition between them, and can architect the bridge from day one. You will be the sole technical authority on the backend. There is no backend architect above you — you are that person.

What You Are Building

The Ora cloud backend has four primary responsibilities, all shaped by the cloud-optional design principle: 1. MQTT Relay Broker

A lightweight, Mutual TLS 1.3 encrypted relay that routes packets to Ora Hubs by UUID. The cloud does not decrypt, store, or process the payload — it is a secure tunnel, not a state manager. Experience designing relay-model MQTT infrastructure rather than full-stack IoT backends is directly relevant here. 2. Installer Portal & Project Management Backend

A professional-grade backend serving licensed electricians: account and credential management, project templates, floor plan and pairing plan storage, AccessKey lifecycle (create, claim, expire, regenerate), and encrypted Project Key custody for the remote handover path. This backend enforces Voltex ID re-verification before releasing sensitive handover credentials and strips user-identifiable data from project records post-handover. 3. Analytic Ingest Service

A minimal, privacy-enforcing telemetry pipeline. A server-side filter explicitly drops any payload containing camera, microphone, occupancy, or contact sensor keys. Only system health metrics (CPU, RAM, signal strength) are stored. GDPR-compliant and aligned with Australia's Code of Practice for Securing the Internet of Things. 4. Identity-Free Backup & Restore

Configuration backup that stores only Matter node topology and room layout — explicitly excluding personas, shadow identities, and system lifecycle data. Restore requires offli