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 offline Recovery Key input at the device. The cloud holds an encrypted file; it cannot interpret or use what it holds.
Phase 2 — Full Cloud Connectivity (Architect Now, Build Next)
The next phase introduces full remote cloud control — live device streaming, cloud-to-device commands at scale, and real-time remote access from anywhere. The Lead Engineer does not build Phase 2 first, but must design Phase 1 so that Phase 2 is an extension, not a replacement. This requires deliberate choices today around identity architecture, data models, relay infrastructure extensibility, and security posture — so that when Phase 2 arrives, the foundations are already there.
What You'll Do
Technical Leadership
• Own the backend architecture end to end — design decisions, standards, trade-off calls, and documentation — with no backend lead above you.
• Defend the cloud-optional, minimal-footprint design philosophy across the team and with stakeholders, and resist feature creep that compromises the privacy model.
• Lead technical design reviews and collaborate directly with the firmware and mobile leads to ensure the cloud, Hub, and App layers remain coherent.
• Define and enforce engineering standards for API design, security posture, observability, and code quality.
• Mentor engineers on the team and raise the technical bar across the backend. Hands-On Engineering
• Design and deliver the MQTT relay broker with Mutual TLS 1.3, Hub UUID-based routing, and DoS-resilient connection handling.
• Build and maintain the Installer Portal REST API — project management, AccessKey lifecycle, credential verification, and handover state machine integration.
• Implement the analytic ingest pipeline with server-side payload filtering and GDPR-compliant retention policies.
• Design PostgreSQL schemas and Redis caching strategies for installer project data, access control, and real-time sync.
• Implement API security across all surfaces — OAuth2/OIDC, JWT, RBAC (Electrician vs Homeowner roles), rate limiting, and input validation.
• Configure and manage AWS API Gateway for routing, throttling, and token validation, behind Cloudflare for external security and DDoS protection.
• Own the CI/CD pipeline end to end — GitHub Actions → ECR → ECS Fargate (Sydney, production), with Render for dev environments.
• Integrate OTA firmware distribution with Hub state-awareness — updates pause during PENDING_HANDOVER lockdown states.
• Drive observability through OpenTelemetry → Grafana Cloud + Sentry — structured, trace-correlated logging via Serilog, diagnosable without accessing device payloads
Requirements
What We're Looking For
• 10+ years of backend engineering experience, with at least 3 years owning architecture in a technical lead capacity — not contributing to an architecture, but defining one.
• Proven experience designing and shipping a connected device backend — you have built the cloud layer of an IoT system and can speak to every decision: protocol choice, relay vs. state-store model, provisioning flows, command pipelines, and security posture. Bonus if you have navigated the transition from an edge-first to a full cloud-connected architecture.
• Deep understanding of IoT communication protocols — MQTT and/or AMQP at the infrastructure level, including broker design, QoS trade-offs, session management, connection resilience, and mTLS. Experience with AWS IoT Core and with custom broker implementations are both valued — AWS IoT Core comes into scope in Phase 2.
• Security-first engineering mindset — you understand Zero-Trust models, end-to-end encryption architectures where the relay cannot inspect the payload, RBAC with multiple persona types, and IoT-specific threat modelling. Familiarity with Australia's IoT Code of Practice is a plus.
• Strong command of C# and .NET 10 — Clean Architecture, CQRS, modern async patterns, dependency injection, hosted services, and performance-sensitive REST API design. Lightweight data access via Dapper or equivalent (full SQL control, no heavy ORM). Node.js or Go experience is also considered for auxiliary services.
• Production-grade PostgreSQL — schema design, advanced indexing, query optimisation, and the judgment to keep a schema deliberately lean. MS SQL experience is a plus. • Redis for real-time state, pub/sub, and session management — including Redis Streams for event-driven patterns.
• Container deployment in production — Docker and AWS ECS Fargate — including ownership of the GitHub Actions → ECR → ECS pipeline from commit to production. • Strong written and verbal communication — you can write a design proposal, run a technical design review, and explain an architectural trade-off to a non-technical stakeholder without losing precision.
Preferred Skills
• Experience with the Matter protocol — particularly its implications for cloud architecture: what the cloud must not own, how commissioning and fabric administration work, and how a Hub-centric model differs from a cloud-centric one.
• Familiarity with offline-first and edge-computing patterns — systems where local operation is the primary path and cloud is an optional extension, not a dependency.
• Experience with infrastructure-as-code — Terraform or AWS CDK — for reproducible AWS deployments (ECS, RDS, API Gateway, ECR). • Background in privacy-by-design engineering — GDPR-compliant data pipelines, identity-free storage patterns, and consent-based telemetry architectures.
• Experience with background job processing — Wolverine, AWS SQS + worker services, or equivalent — for OTA orchestration, scheduled data retention, and queued provisioning tasks.
• Familiarity with event-driven messaging systems — AWS SQS, Kafka, RabbitMQ, or equivalent — for notification pipelines and async installer workflow processing.
Why This Role
This role offers something rare in IoT engineering: the opportunity to design both ends of the spectrum. Phase 1 demands the discipline to build a minimal, privacy-first cloud that does exactly what it should and nothing more. Phase 2 demands the depth to extend that into full cloud connectivity — real-time remote access, live streaming, and cloud-to-device control at scale. Most engineers have built one or the other. This role needs someone who has built both and can architect the bridge between them.
You will work with a small, senior team. There is no bureaucracy between your architectural decisions and production. The firmware, mobile, and backend leads work directly together. The system you build — and the foundation you lay for what comes next — will reflect your judgment directly. Real hardware. Real installers. Real homes.
If you have navigated the full arc of a connected device system — from edge-first launch through to cloud-native scale — and want to do it again with full ownership and a team that will not dilute your decisions, this role is for you.
Benefits