The First Question Is Usually the Wrong Question
Most IoT projects begin with a problem statement:
“Our refrigeration units are failing without warning and we’re losing product.” “We don’t know where our equipment is on a 40-acre construction site.” “Our maintenance team finds out about machine failures after the fact.” “We’re spending too much on energy and we can’t figure out where it’s going.”
These are real problems. Solving them with IoT technology is sensible. The natural instinct — find the solution that addresses this specific problem, deploy it, move on — produces a working solution for the stated problem and a partially-built foundation for everything else.
The instinct is understandable. The outcome is the point solution trap: one problem solved at a time, one tool deployed at a time, until the operation has six specialized systems with no shared data, no common platform, and integration costs that exceed the individual tool costs.
Foundation-first thinking asks a different first question: “What infrastructure do I need to build before I build anything else?” The answer to that question produces a network and platform layer that enables use cases one at a time without rebuilding the foundation for each one.
What a Foundation Consists Of
An IoT foundation has two components: connectivity infrastructure and a platform layer. Neither component is use-case specific. Both are investments that compound in value as use cases are added.
Connectivity Infrastructure
The connectivity layer is the network that devices communicate over. For facilities-based deployments, this is typically a combination of:
LoRaWAN network: One or more LoRaWAN gateways providing coverage across a facility, campus, or geographic area. A single gateway can cover a 50,000 sq ft manufacturing facility or a 10-mile-radius rural area. Once installed, the gateway provides connectivity for any LoRaWAN sensor deployed in its coverage area — regardless of what that sensor measures or what use case it serves.
Wired/IP infrastructure: For devices that communicate over Ethernet or cellular and connect via MQTT or HTTP, the connectivity infrastructure is an internet connection and a network that devices can access. Most facilities already have this; the foundation investment is the platform, not the network.
The key property of connectivity infrastructure as a foundation: it is use-case agnostic. A LoRaWAN gateway installed to support cold chain monitoring also supports equipment monitoring sensors, environmental sensors, asset tags, and utility meters. The gateway doesn’t care what the sensor measures.
Platform Layer
The platform layer is the software that receives device data, stores it, evaluates it against rules, presents it in dashboards, and enables action. For IoT, this is an IoT Application Enablement Platform — VX-Olympus in this framework.
The platform layer is also use-case agnostic. VX-Olympus can manage refrigeration monitoring data and equipment health data and energy monitoring data and asset tracking data in the same system. The rule chains, dashboards, and integrations are configured per use case — but the underlying platform doesn’t need to be re-deployed for each new use case.
The key property: once the platform is deployed and the team knows how to use it, adding a new use case means adding the sensors and the device profiles. The platform infrastructure is already there.
The Marginal Cost Advantage
Application-first thinking treats each use case as a separate project with a separate budget. Foundation-first thinking treats each use case as an incremental deployment on an existing infrastructure investment.
The cost comparison across three use cases:
Application-first approach:
- Use Case 1 (cold chain): Deploy specialized cold chain tool. Cost: platform subscription + sensors + deployment.
- Use Case 2 (equipment monitoring): Deploy separate equipment monitoring tool. Cost: new platform subscription + sensors + deployment + integration with Use Case 1 tool.
- Use Case 3 (energy monitoring): Deploy separate energy management tool. Cost: new platform subscription + sensors + deployment + integration with Use Cases 1 and 2.
Each use case carries its full platform cost and creates integration requirements with existing tools.
Foundation-first approach:
- Foundation (connectivity + platform): Deploy LoRaWAN gateway network + VX-Olympus. Cost: gateway hardware + platform subscription.
- Use Case 1 (cold chain): Add cold chain sensors. Configure device profiles, rule chains, dashboard. Cost: sensors + configuration time.
- Use Case 2 (equipment monitoring): Add equipment monitoring sensors. Configure device profiles, rule chains, dashboard. Cost: sensors + configuration time.
- Use Case 3 (energy monitoring): Add energy monitoring sensors. Configure device profiles, rule chains, dashboard. Cost: sensors + configuration time.
The platform cost is paid once. The connectivity infrastructure cost is paid once. Each subsequent use case adds sensor hardware and configuration time — but not another platform or another network.
The Knowledge Compounds
There is a second compounding effect of foundation-first that doesn’t appear in cost models: operational knowledge.
When an operations team deploys a new point solution for each use case, they learn each new tool from scratch. The learning curve is repeated for each tool — different interface, different data model, different configuration approach. With six tools, this is six learning curves, and the team never develops deep expertise in any one platform.
When the same team deploys multiple use cases on a common platform, each use case builds on their existing knowledge of the platform. The person who learned VX-Olympus for cold chain monitoring already knows how to configure device profiles, rule chains, and dashboards when equipment monitoring is added. The second use case deploys faster than the first. The third faster than the second.
This is not trivial. Operational technology literacy — the team’s ability to configure, extend, troubleshoot, and get value from their IoT deployment — is a competitive advantage. It compounds when built on a common platform and fragments when built on a collection of specialized tools.
The Objection: The Foundation Requires Budget Before There Is Value
The honest objection to foundation-first thinking is timing: the foundation investment must be justified before the first use case produces return, while application-first thinking justifies each investment by the value of the problem it solves.
A budget conversation for foundation-first looks like: “We want to deploy a LoRaWAN network and a VX-Olympus platform that will enable us to do cold chain monitoring, equipment health monitoring, energy management, and eventually several other use cases.”
A budget conversation for application-first looks like: “We’re losing product to refrigeration failures. This cold chain monitoring system costs $X and will prevent $Y in product loss per year.”
The second conversation is easier. The first requires communicating a future capability value that isn’t realized yet.
There are two responses to this objection:
Start with a use case that justifies the foundation. The foundation-first approach doesn’t require ignoring the specific problem that motivated the project. Deploy the foundation to solve the specific problem — but scope the foundation to support the full range of future use cases, not just the immediate one. A LoRaWAN gateway and VX-Olympus deployment sized for cold chain monitoring at 52 locations is also sized for equipment monitoring, energy management, and restroom monitoring. The first use case justifies the foundation; subsequent use cases are incremental.
Calculate the total cost trajectory. A forecast that shows the cost of adding three use cases application-first versus the cost of adding three use cases foundation-first often inverts within 18–24 months. The foundation has higher upfront cost; the incremental use cases have lower cost. Application-first has lower upfront cost; the incremental use cases carry platform-plus-integration costs that accumulate rapidly.
Foundation-First in Practice: What to Build First
Not all foundations are equal. A foundation that supports current use cases but constrains future ones is a partially-built foundation that will require rework.
The relevant properties to evaluate when building an IoT foundation:
Multi-protocol connectivity. A gateway and platform that support only one sensor protocol (LoRaWAN only, or Wi-Fi only, or cellular only) constrains future use cases to sensors that speak that protocol. The best sensor for a given measurement may use a different protocol. Foundations that support multiple protocols don’t face this constraint.
Multi-tenant architecture. For operations with multiple sites, departments, or customer relationships, a platform that supports hierarchical multi-tenancy enables proper data isolation and access control at scale. A flat architecture that treats all devices as belonging to one account becomes a liability as the deployment grows across organizational boundaries.
Protocol-agnostic data model. The platform should normalize data from different sensor types and protocols into a common data model. A temperature reading from a LoRaWAN sensor and a temperature reading from an MQTT-connected sensor should appear identically in dashboards and rule chains — the underlying connectivity should be invisible at the application layer.
Extensible rule engine. The rule engine that handles cold chain threshold alerts should also be capable of multi-condition equipment health rules, derived metric calculations, and integration with external systems. A rule engine designed only for simple threshold alerts will constrain use cases that require more sophisticated logic.
VX-Olympus was designed with these properties because the use cases that come after the first one demand them.
Conclusion
“Foundation-first” sounds strategic. “Solve the refrigeration problem” sounds operational. Both orientations are valid — the question is whether the solution to the immediate problem is also building a foundation for the next one.
The organizations that end up with the most effective IoT deployments are typically not the ones that solved the most problems first. They are the ones that built the foundation most thoughtfully and then deployed use cases rapidly on top of it.
Use cases follow networks. Intelligence follows data. Value compounds on a good foundation.
The decision at the beginning of an IoT project — whether to build a foundation or solve a point problem — has consequences that extend 3–5 years forward. Getting the foundation right is the highest-leverage decision in an IoT deployment lifecycle.
Talk to our team about designing an IoT foundation for your operation.