The problem
The manufacturer was developing a fully connected thermal management system for hot water installations, combining an embedded control board with cloud monitoring and control. The hardware and firmware were within their own engineering capability, but the cloud platform, the optimisation intelligence and the customer-facing applications were not. We were engaged to define and scope that entire software side, and subsequently to author the technical sections of a government innovation grant application.
The product required a cloud platform, web dashboards, mobile applications and an AI optimisation layer that did not exist and had no defined architecture.
Hot water installations drew from multiple energy sources, including electric, solar thermal and heat pumps, with no system deciding which to use and when.
Electricity tariff data was not factored into heating decisions, so energy was consumed without regard to cost.
There was no defined data contract between the embedded hardware and any cloud system, making the two workstreams impossible to run in parallel.
The grant application required detailed technical sections, deliverables and a phased plan that the client could not produce internally.
What we designed
We drew a firm line between the disciplines rather than overreaching. Embedded firmware, mains-voltage switching and PCB design sit outside our scope and stay with the client's hardware engineers; we took the cloud backend, the AI optimisation layer, and the web and mobile applications. We made that split a condition of the engagement, because a software team accepting responsibility for safety-critical hardware would have put the project at risk. For the grant application we then defined the full technical programme in phases.
Who owns what
The boundary we set
Client's hardware team
- Embedded firmware
- Mains-voltage switching
- PCB design
- Safety certification
AMZU
- Cloud backend
- AI optimisation layer
- Web dashboards
- Mobile applications
Device platform
REST and MQTT services handling telemetry ingestion, device registration and command dispatch to the control boards
Time-series data layer
Storage and aggregation of temperature, flow and current sensor readings
AI optimisation engine
Decides energy source and heating schedule across electric, solar thermal and heat pump inputs using tariff data
Web dashboards
Installation monitoring, control and performance reporting
Mobile applications
IOS and Android remote monitoring and control for end users
Device and user management
Provisioning, authentication and role-based access
How it works
From trigger to result.
How the system works
7 stages
01Control board
TriggerDrives heaters, pumps and valves. Reads temperature, flow and current sensors.
02MQTT broker
LogicTelemetry is published continuously. Commands are subscribed.
03Time-series store
DataReadings stored and aggregated.
04Optimisation engine
AICombines sensor state, available energy sources and tariff data.
05Command dispatch
LogicHeating decisions return to the board over MQTT.
06REST API
LogicAuthentication, provisioning and user control.
07Web and mobile apps
ResultMonitoring, control and performance reporting.
Our approach
How we worked.
Feasibility split
Assessed the product discipline by discipline and separated embedded and hardware work from backend, AI, web and mobile.
Scope negotiation
Established the condition that the client retains hardware and firmware ownership end to end, with a defined data contract between the two sides.
Technical authoring
Wrote the grant proposal's technical sections, including project description, objectives, deliverables and phased timeline.
Risk flagging
Raised supplier eligibility, intellectual property ownership and hardware readiness as conditions affecting the application.
The outcome
What the client received.
The client received grant-ready technical documentation covering architecture, objectives, deliverables and a phased plan.
We declined the hardware and firmware scope rather than accepting it, keeping safety-critical engineering with the engineers qualified to do it.
We raised eligibility and intellectual property questions early, before they could affect the grant submission.
Questions
What people ask.
Can a software consultancy deliver a connected hardware product end to end?
Not responsibly, and we do not claim to. Embedded firmware, mains-voltage switching, PCB design and safety certification require embedded and electronics engineers. We take the cloud platform, the intelligence layer and the applications, and require that hardware and firmware stay with qualified engineers on the client side.
What makes hardware and software workstreams able to run in parallel?
A published data contract. Once the MQTT topics, payload structures and command set are agreed, the firmware team and the platform team can build independently against that contract and integrate later. Without it, both sides block on each other.
Why does MQTT suit connected hardware rather than a standard REST API?
MQTT is lightweight, designed for constrained devices and unreliable connections, and supports publish-subscribe messaging in both directions. Devices publish telemetry continuously and subscribe to a command channel. A REST API still sits alongside it to serve dashboards and applications.