Hardware & IoT

What hardware and IoT apps are worth building?

The easiest openings are software layers over devices people already own. A device that reports its own power use, status or battery level gives an app something to work with. Build around questions a single device cannot answer, such as the total cost of several appliances, or whether any device has gone quiet.

The honest version of the running-cost question is an estimate. Say how the estimate is made and which tariff it assumes.

Who uses device software, and how do you reach them?

Device owners with a dozen or more gadgets, property managers with a handful of flats, and small businesses with sensors on equipment are the likely users. They care about cost, uptime and surprises. A household might look at its devices once a year, while an operator needs to know daily, so operators are the group to test payment with first.

Reach them through the places where they buy and set up devices: owner forums for particular brands, property management groups, and small-business communities that discuss equipment. Ask what they check each month, and what they stopped checking because it took too long.

• Build a spreadsheet of one owner’s devices and send them a monthly note. It tests the question before any code exists.
• Ask a property manager which device failure cost them most last year, and whether they learned about it from a tenant or from a system.
• Test payment only with operators, and only for a report or alert they would otherwise make by hand.

What makes a hardware or IoT idea good?

• It reads existing data: the device or its cloud already reports the number. A new sensor would be a second product.
• It works without the manufacturer’s cooperation, or the manufacturer’s terms allow it. Check this first.
• It answers a yes-or-no question. “Is anything offline?” is easier to act on than “show me telemetry”.
• A wrong answer is cheap: a wrong energy estimate is annoying, but a wrong safety alert can be harmful.
• It has a monthly rhythm: costs, updates and check-ins recur, which gives people a reason to return.

What would a first device app look like?

Hypothetical example: a household with eleven connected devices wants to know what they cost to run. The first version asks for each device’s rated power and hours of use per day, plus the electricity price the owner pays, and returns a yearly cost per device. It needs no hardware and no manufacturer account.

Build a single-page running-cost calculator. Input: a list of devices with rated watts, hours of use per day, and a price per kilowatt-hour that the user types in. Output: yearly cost per device and in total, sorted by cost, with the formula shown. Label every figure as an estimate based on rated power. No device connections, no accounts, and no stored data.

The test is whether the owner acts on the result. If they unplug or replace one device, the question was worth answering. If they only look at the number and move on, add the step that turns it into a decision, such as a suggested swap.

What are the pitfalls for connected devices?

• Certification. Electrical and radio products often need certification or a mark before they are sold, such as CE in Europe or FCC in the United States. Which ones apply depends on the product and the market, so check before you sell hardware, not after.
• Manufacturing and stock. A physical product needs component sourcing, minimum orders and shipping. Each adds lead time and cash you must front. A software layer avoids most of that.
• Cloud costs after launch. An app that polls a cloud service for many devices pays for every request. Model the cost per connected device before you promise a free tier.
• Security. A connected device with a weak setup can be taken over. Do not ask users to open network ports, and never store device passwords in plain text.
• Safety functions. Smoke, gas, water and medical devices are regulated in many places. An app that raises alerts about them can become a safety product with a duty of care.
• Breaking updates. A manufacturer’s firmware update can break an integration without warning, and some devices will stop working with your app.

Where should you start with device software?

The board has one idea filed under hardware and IoT, “What every device in the flat costs you per year”. It is the running-cost calculator from the worked example. A related idea sits under Sustainability: what that appliance actually costs you per year. Read the two together, because the same energy estimate serves both categories and shows where the data has to come from.

1. Pick one set of devices you own, list them, and note the rated power printed on each label or in its manual.
2. Build the calculator from the prompt above, with no device connection at all.
3. If your device problem is not among the hardware and IoT ideas, post it and say which data the device already reports.
4. Read how to validate an app idea and how to scope an MVP before you consider connecting any device.