"Control it from the phone" hides a whole architecture

Local control means the phone talks directly to the product -- over Bluetooth when nearby, or over the local Wi-Fi network when on the same router. Cloud control means the product holds a connection to a server and the app sends commands through it. Local costs nothing to operate and works without internet, but only within range. Cloud works from anywhere and enables push notifications and history, but adds recurring cost, latency, and an operational burden for the life of the product. The choice gets locked into the architecture early and is expensive to reverse, so it deserves a deliberate decision rather than a default.

Local control: direct, fast, no subscription

In the local model there is no server in the path. The advantages are concrete:

  • Immediate response. No round trip to a data center, so a button press feels instant.
  • Zero recurring infrastructure cost. Nothing to pay per unit, per month, forever.
  • Data stays in the building. A genuine privacy advantage, and increasingly a selling point in categories involving cameras, audio, or health data.
  • Nothing to keep running. If your company changes direction, the product keeps working. Customers have learned to worry about this.

The limitation is equally clear: leave the network and you lose control. Local is an excellent fit for products used while standing next to them -- power tools, audio gear, lab instruments, kitchen appliances, medical devices used in a clinic. The mechanics of the two local paths are covered in Bluetooth Classic vs. BLE and Wi-Fi provisioning from an app.

Cloud control: anywhere in the world, at a recurring price

In the cloud model the device maintains a persistent connection to a broker or server, and commands travel through it. That unlocks the things customers describe when they say "smart": switching something off from the office, receiving an alert when an event happens at home, reviewing months of history from a different continent, and sharing access with family or colleagues.

The costs are real and they compound with sales volume. Servers, storage, and message traffic are paid monthly for every unit in the field for the whole life of that unit -- see IoT cloud infrastructure cost for how those numbers scale. On top of that comes operational responsibility: uptime, monitoring, backups, key rotation, security patching, and platform migrations. The transport layer choice affects all of it, which is why MQTT vs. HTTP for IoT matters more than it looks. And latency increases, because every command travels phone to cloud to device and back.

The failure mode worth naming: when the internet drops, a cloud-only product becomes inert. A user standing three feet from their own device, unable to turn it on because a data center is unreachable, will not be forgiving about it.

How to decide: five questions

  • Where is the user at the moment of use? Always beside the product means local is sufficient. If the core story is "check on it while away," nothing but cloud will do.
  • What happens when connectivity fails? Anything safety-relevant, comfort-critical, or simply annoying to lose needs complete local logic, with cloud as a convenience layer above it.
  • Do you need to reach the user unprompted? A push notification while the user is away requires a server. There is no local-only version of that.
  • What is the revenue model? Recurring cost without recurring revenue erodes margin on every unit sold. A subscription product coexists comfortably with cloud; a one-time purchase needs the lifetime server cost priced into the sticker. Hardware as a service covers the model that makes cloud economics work.
  • Who owns the data, and where must it live? Enterprise and institutional buyers frequently prohibit outbound cloud connections entirely, which turns local control from a preference into a sales requirement.

Security: not a task for the end of the project

Remote control is also an attack surface. Whoever controls the channel controls the device in a customer's home. The cloud model needs strong authentication, transport encryption, and rigorous isolation between tenants and user accounts, so that no credential ever grants access to another customer's devices. The local model has its own obligations: preventing arbitrary devices on the same network from issuing commands, and ensuring the initial pairing flow does not leave a permanent open door. Both models need a way to ship security fixes to firmware over the product's lifetime, which is why OTA firmware updates are a requirement rather than a feature. The broader checklist is in IoT security for connected products.

The hybrid architecture most products land on

The pattern that survives contact with real users is local-first with cloud augmentation. The device holds complete autonomous logic: schedules, thresholds, safety limits, and a physical interface that works with no phone and no network. The app talks locally when it can, for speed and reliability. The cloud handles what only a server can -- remote access, notifications, long-term history, fleet visibility, and update distribution -- and its absence degrades the experience without breaking the product.

This costs more than either pure model at first, because you build two command paths and have to keep state consistent between them. It costs far less over the product's life, because it is the only architecture where an internet outage, a platform migration, or a change in your own business plans does not turn installed hardware into scrap.

Decide it before development starts

Retrofitting remote access into a locally designed product means redesigning identity, security, and the data model. Retrofitting offline operation into a cloud-designed product means rewriting the firmware's decision logic. Projects House designs the firmware, app, and cloud layers together so this decision is made once, against your real use case and revenue model. Describe your product in the contact form and we will help you choose the architecture that fits.