Project · Sketch a Connected Product End-to-End

Pick a real problem in your own life — a houseplant that dies on vacation, a garage door whose state you can never remember, a fridge that gets left open — and produce a one-page architecture sketch of the IoT product that would solve it. No code. The output is a system diagram, a component list, a data flow, and a deliberate justification for every connectivity decision. The point is to force every decision (which MCU? which radio? where does the data live? what happens offline?) out of intuition and onto paper.

• A single-page architecture diagram showing device, gateway (if any), backend, and user interface — with the protocol on every arrow.
• A bill of materials for the device side: MCU, sensors, actuators, power source, and radio, with one-sentence justification for each choice.
• A data flow description: what data is captured at what rate, where it is buffered, how it eventually reaches the user, and what happens during a 24-hour internet outage.
• A short threat-model paragraph: who would attack this product, what would they gain, and what is the cheapest defense that mitigates the most likely attacks.

• Diagram explicitly labels each tier (device / gateway / cloud / user) with the protocol on every link.
• Each component choice is justified against the four constraints introduced in this module (cost, power, radio, ecosystem).
• The offline-failure section names a specific behaviour for each tier, not a hand-wave.
• The threat-model section identifies a realistic attacker (not 'hackers') and a proportional defense (not 'encrypt everything').