This note draws on work connecting a browser interface, Flask APIs, operational data and an embedded dispensing system. Proprietary component and implementation details are intentionally excluded.
Start with the user journey
A device operation is not the product. It sits inside a wider journey involving setup, selection, validation, dispensing and completion. Designing APIs around those workflows creates a clearer system than exposing low-level device commands to the interface.
Model intermediate state explicitly
A physical action is not always instant or reversible. The application should distinguish requested, validated, in-progress, completed and failed states and persist only what has genuinely happened.
Separate responsibilities
The web interface collects choices and shows progress. Backend services validate rules and own persistence. The device-integration layer translates deliberate application commands into hardware operations. These boundaries make failures easier to isolate without exposing internal device complexity.
Design for physical failure
Hardware operations can be delayed, incomplete or unavailable. Timeouts, safe defaults, retry rules and clear recovery states matter. Test seams should allow business workflows to be verified without activating physical equipment on every test run.
Learning an unfamiliar domain
I entered the work without previous IoT experience. Tracing the complete journey, learning the integration boundary incrementally and testing one responsibility at a time allowed me to contribute across the full stack while protecting system clarity.