The operating problem
A successful bench demonstration often creates the impression that the difficult work is complete. The sensor reads correctly, the controller connects to Wi-Fi and a value appears on a web page. In reality, the prototype has proved only one path under favourable conditions. Deployment introduces power interruptions, weak networks, duplicated messages, firmware changes, device replacement, configuration drift and users who need to know what to do when the system is uncertain.
Engineering judgement tied to operating evidence.
Founder and software/electronics engineer at INESSOFT. Reviewed against current INESSOFT delivery practice and operating evidence.
Published 10 Jul 2026 · Last reviewed 10 Jul 2026The prototype proves possibility, not reliability
A prototype answers whether the concept can work. Production asks whether it can keep working, fail visibly and recover without the original developer standing next to it. These are different goals and should not be confused in scope, budget or acceptance criteria.
- State the exact decision the prototype is intended to unlock.
- List which production concerns were deliberately excluded from the experiment.
- Do not let temporary credentials, hard-coded values or manual resets become invisible dependencies.
Device identity must survive replacement and reset
Server records are only useful when the source is known. A device needs a stable identity, provisioning method and configuration history. The design must explain what happens when a board is replaced, credentials are rotated or the same physical asset receives new electronics.
- Separate device identity from network address.
- Record firmware and configuration versions with incoming events.
- Define secure provisioning and decommissioning rather than cloning credentials.
Messages need delivery semantics
Sending a payload is not the same as guaranteeing that it is processed once. The system must decide what acknowledgement means, how retries behave, whether duplicated messages are harmless and how long the device should retain unsent data. These choices depend on whether the event is a periodic reading, alarm, transaction or state transition.
- Use identifiers or sequence numbers where deduplication matters.
- Design local buffering around realistic memory and power constraints.
- Make late, duplicated and out-of-order messages visible to the server logic.
Diagnostics must cross the whole stack
A blank dashboard could mean sensor failure, firmware lock-up, power loss, network failure, rejected authentication, server validation error or database outage. Support becomes practical only when each layer produces enough evidence to narrow the fault without physically visiting every device.
- Track last contact, last valid event and last reported device error separately.
- Expose rejected payload reasons and protocol-version mismatches.
- Provide a simple support view rather than relying exclusively on raw logs.
Firmware and server contracts evolve together
Payload fields, units and state meanings change as the product develops. Without versioning, an apparently small firmware update can silently break server interpretation or historical consistency. The contract should identify message version, units, optional fields and backward-compatibility expectations.
- Version the protocol deliberately.
- Reject unsupported messages clearly rather than storing corrupt values.
- Test mixed device versions if staged rollout is expected.
Operational value requires a response workflow
Data collection alone rarely creates value. Someone must review an exception, acknowledge an alert, schedule maintenance, issue a report or use the history in a decision. The server application should be designed around that action, not around a collection of attractive charts.
- Name the user and action associated with each important event.
- Distinguish informational telemetry from events that require ownership.
- Record acknowledgement and closure where accountability matters.
Use the operating signal to choose the next action.
The same symptom can justify a custom system, a smaller integration, a stabilisation phase or no build at all. The decision should follow evidence rather than enthusiasm for a particular technology.
The goal is a temporary proof for an investment decision.
Production hardening can be intentionally limited.
Document the shortcuts and define the evidence required for the next phase.
A small number of devices will be maintained by the development team.
Provisioning and diagnostics can be simpler but still explicit.
Build identity, logs and recovery before adding visual polish.
Devices will be deployed widely or remotely.
Support cost will dominate if failures are opaque.
Prioritise fleet status, configuration, update strategy and remote diagnostics.
Events trigger business or safety actions.
Delivery semantics and accountability are critical.
Define acknowledgement, retry, escalation and human ownership end to end.
Evidence that the current approach is becoming risky.
- The device posts without a stable identity or message version.
- A failed HTTP request simply discards the reading.
- The dashboard shows no distinction between stale, missing and normal data.
- Firmware updates require server changes but compatibility is undocumented.
- The business has not defined who acts when an alert appears.
What to clarify before commissioning work.
- Define device identity, provisioning and replacement behaviour.
- Classify each message as reading, state, transaction or alarm.
- Agree acknowledgement, buffering, retry and duplicate handling.
- Version payloads, units and state meanings.
- Create cross-layer diagnostics and support views.
- Connect important events to an owned operational action.
Case studies behind the lesson.
These links provide system context, architecture, workflows and engineering decisions connected to the article.
Questions that usually appear during scoping.
Is MQTT required for a reliable device system?
No. MQTT, HTTP, serial gateways and other transports can all be appropriate. Reliability depends on identity, delivery semantics, validation, diagnostics and recovery behaviour.
Should the device store data while offline?
Only where the value of the missed data justifies the memory, power and complexity. The retention period and overflow behaviour should be explicit.
Can firmware updates be added later?
Yes, but deployment strategy should be considered early if devices will be remote or numerous. Otherwise every update may become a physical service operation.
What is the minimum useful server layer?
Authentication, validation, device identity, durable storage, error visibility and a user workflow that turns the event into an action or trusted record.