The Internet of Things Has Arrived Are Your App Developers Prepared

A fitness app running on a phone is one thing. The same app needing to talk to a smartwatch, a connected treadmill, a heart rate monitor, and a Bluetooth scale is something else entirely. The device count is no longer theoretical. IoT Analytics estimates there will be over 27 billion connected IoT devices worldwide by 2025, and the products sitting in the middle of those networks are apps. Most of them were never built to be there.

The gap between development practice and where connected products actually live is real and expensive.

The gap between where app development practice currently sits and where connected products actually live is real and expensive. We see it in the architecture decisions teams make in week one of a project, in the connectivity assumptions baked into a data model before a single screen is designed, and in the offline states nobody planned for until a user was standing in a field with no signal and a completely useless screen in their hand.

This article is for product owners, founders, and anyone commissioning an app that will need to operate across more than one device or context. The question is not whether IoT will affect your product. It already has. The question is whether the team building it knows that.

What IoT Actually Means for App Development Today

The phrase "Internet of Things" still sounds like a future problem to a lot of development teams. Technically, it describes any network of physical devices exchanging data, thermostats, vehicles, wearables, industrial sensors, medical monitors. Practically, it means your app is no longer the only thing in the room. It sits inside an ecosystem of hardware, connectivity, and user contexts that it needs to understand and respond to.

For app developers, this creates concrete demands. Data needs to flow between devices reliably, which means thinking carefully about synchronisation, state management, and what happens when a connection drops. Interactions need to be rethought for different screen sizes and input methods, because a tap on a phone and a tap on a watch are not the same gesture used in the same context. Security needs to extend beyond the app itself to every device in the network.

None of this is impossible to build for. The problem is that it requires a different set of assumptions from the start. An app designed around a single screen, a permanent internet connection, and a user who is sitting down with time to think is built on assumptions that break the moment a connected device enters the picture. The development team that treats IoT as an add-on feature, bolted on after the core product is stable, will spend far more time and money than the team that accounted for it in week one.

Why Most Development Teams Are Still Building for a Single Screen

The default mental model for app development is a phone. The wireframes show a phone. The user testing happens on a phone. The sprint goals are written around phone-based flows. This is the inherited shape of how most development practice was built, and it takes deliberate effort to think outside it.

Teams that have only ever shipped phone apps carry a set of invisible assumptions: that the user has two hands free, that they are looking at the screen, that they have a few seconds to read a label, that the connection is stable. Each of those assumptions breaks in a connected device context. A smartwatch wearer is glancing, not reading. A car infotainment system user is driving. A sensor mounted in a warehouse communicates in the background with no user present at all.

Extending an existing phone-based product to cover any of those contexts requires more than redesigning a few screens. It often requires rethinking the data model, the state management approach, the authentication flow, and the error handling. Teams that discover this late pay for it twice: once to undo the assumptions, and again to build the right thing. The discovery gap is the expensive part, and it opens up long before a line of code is written.

The Watch Is Not a Small Phone: Lessons From Rethinking an App Across Devices

We worked on a water tracking app that was originally built for phone only. The product was tactile and engaging on mobile, making full use of the screen with animations, gestures, and a visual language that rewarded consistent use. Then the brief expanded to include an Apple Watch component, and we had to start rethinking almost everything.

The watch offered very limited real estate compared to the phone. The interaction model that made the phone experience feel alive, the taps, swipes, and layered navigation, simply did not translate. We had to rethink the navigation patterns entirely and find a different model for how users would interact on the wrist. We also could not achieve the same fluidity as the phone experience, which required honest conversations about what the watch version could actually do well, rather than trying to replicate something it was never going to match.

Watch design requires its own design logic, not a reduction of mobile thinking.

What we found was that the watch needed to serve a fundamentally different purpose in the user's day, brief, glanceable, confirmatory rather than exploratory. We built features that made sense in that context rather than shrinking the phone features down. The lesson from that project is applicable to any IoT surface: each device in an ecosystem has its own logic, its own constraints, and its own relationship with the user. Treating a new device as a smaller version of the previous one is where the trouble starts.

Before extending your app to a new device, map the use context first, where is the user, what are they doing with their hands, how long are they looking, and what do they actually need in that moment. The answers will usually reveal that the feature list needs to change, not just the screen size.

What Structural Debt Looks Like When Connectivity Assumptions Break

Technical debt is a familiar concept, but connectivity debt is a specific and nastier version of it. It accumulates when an app is built on the assumption that it will always have a reliable connection, and then deployed into a world where that assumption does not hold. Every feature that touches the network, every data fetch, every sync, every real-time update, becomes a liability the moment the signal drops.

The deeper problem is that debt of this kind does not stay still. We have seen it on a long-running communications product where connectivity assumptions were embedded in the original architecture and deferred repeatedly as the team kept shipping new features on top. The structural fragility grew with every release. It was not until the accumulated debt became so large that the product's basic reliability was at risk that the team was forced into a much larger intervention than incremental fixes would have required.

By that point, the cost of addressing it dwarfed what managing it incrementally would have cost. Research published in the Science of Computer Programming journal found that development teams spend roughly 25% of their time dealing with technical debt. When connectivity assumptions are embedded in architecture from the beginning, that figure does not go down as the product matures.

Audit your connectivity assumptions early, list every feature that requires a live connection and ask what happens to each one when the connection disappears. If the answer is "it breaks", that is a debt item. Decide consciously whether to carry it or clear it.

The Offline Trap: When Your App Becomes Useless in the Field

We worked with a travel product used for exotic holidays and backpacking in remote wilderness areas. The app covered map search, saved pins, tickets, itineraries, and location timing, everything a user needed to navigate their trip. The problem surfaced when the product expanded into a new type of trip, and users started taking it to genuinely remote locations without reliable connectivity.

Without a signal, the app displayed a "not connected" error and became completely unusable. No cached maps. No offline itinerary access. No saved location data. For a user standing in a wilderness area relying on the app to navigate, this was, as Simon put it at the time, "an absolute disaster." The app had to be retrofitted with offline capability after launch, which meant reworking data storage, caching logic, and sync behaviour that had never been designed with any of that in mind.

The rework cost significantly more than building for offline from the start would have. And the damage in that window, users who experienced the failure before the fix shipped, was real. IoT deployments make this failure mode more common, not less. A sensor network operating in a building with inconsistent Wi-Fi, a wearable that needs to store data during a tunnel commute, a vehicle app that must function on a remote road, all of them expose the same assumption: that connectivity is guaranteed. It never is.

API Dependencies and the Hidden Cost of Inherited Architecture

Connected products rarely communicate directly. They talk through APIs, interfaces that allow devices, services, and apps to exchange data according to agreed rules. In an IoT context, an app might be consuming APIs from a sensor manufacturer, a cloud data platform, a third-party analytics service, and a device operating system simultaneously. Each of those dependencies carries risk.

The risk is not just that an external API changes or goes down, though both of those happen. The deeper risk is architectural: when an app is built around a particular API's data model, the shape of that API gets embedded in the app's own logic. Change the API, and you may need to change far more than the connection layer. This is the hidden cost of inherited architecture, and it is especially acute when a team takes over a product that was built by someone else.

What Inherited Architecture Costs

We have seen this in wellness and health products where a design handoff went through an intermediary, adding distance between the original intent and the implementation. Applying a new interaction layer on top of an existing codebase is possible, but the gap between what the design asks for and what the underlying architecture can support creates rework. In a connected product, that gap is multiplied across every API surface in the ecosystem.

The discipline required is to map the API dependencies before committing to an architecture, to ask what happens if any one of them changes, and to build a data layer that isolates the rest of the app from that risk. Teams that skip this step do not avoid the problem, they defer it until it is more expensive.

Discovery Gaps and the Price of Skipping Ecosystem Thinking

The most expensive decisions in any connected product are made during discovery, or rather, they are made by default when discovery is skipped. We worked on a dating app project where the product's entire premise was built on verified profiles and preventing bots. The client chose to skip discovery for the messaging component and focus the scoping work purely on the onboarding process.

What was built without that discovery was a generic messaging feature that contradicted the core premise of the product. It allowed automated messages and fake accounts to communicate freely, the exact behaviour the onboarding had been carefully designed to prevent. The mismatch between a rigorously verified onboarding and a permissive messaging system meant the entire messaging section had to be rewritten. That rewrite cost approximately £15,000 in additional budget and added around two months to the project timeline.

In an IoT product, the cost of skipping ecosystem thinking is the same problem scaled. A messaging feature touches one part of the experience. A connectivity model, an offline strategy, or a cross-device data architecture touches everything. When those decisions are made by default rather than by design, the rewrite reaches the foundation.

We worked with a property developer building a concierge app for high-rise residents who came to us with a pre-formed idea and a budget in mind, looking essentially for validation. We pushed for a proper discovery phase, including focus groups and user workshops. What emerged was a product far simpler than originally envisaged, with many planned features dropped, and a tighter focus on human connection rather than system replacement. A better product at lower cost.

How to Scope an App That Will Need to Operate Across an Ecosystem

Scoping a connected product is a different exercise from scoping a phone app. The questions are different, and the order in which you answer them matters. Getting the ecosystem picture clear before committing to architecture decisions is the discipline that separates projects that ship well from projects that accumulate debt from day one.

Ecosystem Questions to Answer First

A useful way to structure the scoping work is to answer these in order before any architecture decisions are made:

1. What devices does this product need to operate on, and what is the user's context on each one?
2. Which features are core to every surface, and which are surface-specific?
3. What happens to each critical feature when the connection drops?
4. Which external APIs or hardware dependencies does the product rely on, and what is the plan if they change?
5. What does the data model need to look like to serve all of these surfaces without duplication?

These questions surface the structural decisions early, where they are cheap to make. Teams that answer them in week one of a project avoid spending months untangling assumptions that were never tested. Teams that answer them during a retrospective after a troubled launch pay the full price. Discovery is not a project management formality. In a connected product, it is the architecture.

Signs Your Current Development Team Is Not IoT-Ready

A development team's readiness for connected product work shows up in the questions they ask at the start of a project. A team that has built for single-screen, always-connected contexts will ask different questions than a team that has shipped products operating across multiple devices and variable connectivity. The gap between those two sets of questions is where risk accumulates.

What to Listen For

There are concrete signals that a team is not thinking in ecosystem terms yet:

• They treat offline states as edge cases rather than first-class scenarios to design for.
• They have no clear answer for how data will synchronise when a device reconnects after a dropped connection.
• Their API integration plan has no contingency for a dependency changing or going down.
• They are proposing to adapt the phone UI for a watch or other connected device rather than rethinking the interaction model from scratch.
• Their discovery process does not include mapping all the device contexts a user will encounter.

None of these gaps means a team is incapable of growing into connected product work. But they do mean the product owner needs to be more active in asking the questions the team is not yet asking for themselves. The moment to discover these gaps is before the architecture is committed, not after the first user files a bug report from a location with no signal.

What Prepared Looks Like: Principles for Connected Product Development

A team that is ready to build connected products does not necessarily have a longer portfolio. They have a different orientation. They think in ecosystems rather than screens, they treat connectivity as a variable rather than a constant, and they ask what happens at the edges of the experience before they design the centre of it.

On the water tracking product where we added Apple Watch support, the question we had to keep asking was not "how do we fit this feature onto the watch?" but "what does a user actually need from this product on their wrist?" Those are different questions, and they produce different designs. The first leads to a shrunken phone interface. The second leads to something that actually belongs on a watch.

A few principles that distinguish prepared teams from unprepared ones:

• Offline is a design requirement, not a fallback. Every feature that touches the network has an offline state.
• Each device surface gets its own design logic, informed by user context, not adapted from another surface.
• API dependencies are mapped and risk-assessed before architecture is committed.
• Discovery covers the full ecosystem, not just the primary screen.
• Technical and connectivity debt is tracked and addressed incrementally rather than deferred until it becomes structural fragility.

At the start of any connected product project, ask your development team to describe what happens to the five most critical features when the internet connection drops. Their answers will tell you more about their IoT readiness than any portfolio review.

Conclusion

The IoT shift is not something happening to a narrow category of specialist products. It is happening to fitness apps, travel products, property technology, automotive software, and health tools. Over 1 billion connected wearable devices are already in use globally, according to ElectroIQ, and each one represents a context that phone-first development assumptions were never built to serve.

The projects we have described in this article, the water tracking app that needed a fundamentally different design logic for the watch, the travel product that became useless without signal, the communications product whose deferred structural debt eventually threatened its own reliability, the dating app that paid £15,000 and two months to fix a discovery gap, are cautionary tales about something deeper. They are what happens when experienced teams apply the right thinking for one context to a context it was not designed for.

Preparedness is a set of questions asked at the right moment, a willingness to design for the edges before the centre, and the discipline to treat every device surface as its own design problem rather than a smaller version of the last one. If your product is moving into connected territory and you are not sure whether your team is asking the right questions, that uncertainty is itself a useful starting point.

Let's talk about your connected product and work out what needs to be in place before the first line of code is written.

Frequently Asked Questions