# How to Scope an IoT Project Before Buying Any Hardware

> A scoping sequence that produces a one-page IoT project scope before the first purchase order, and how to test it on the platform with a simulated device.

![How to Scope an IoT Project Before Buying Any Hardware](https://tago.io/og/blog/scope-an-iot-project-before-buying-hardware.png)

The natural first step in an IoT project is to order a development kit and a few sensors. It feels like progress, it costs little, and it gives the team something to plug in. Most projects start there.

The catch is that hardware bought before scope makes decisions for you. A LoRaWAN sensor commits you to a network you may not have coverage for. Its firmware fixes the payload format and the variables you will ever get. Its default reporting interval sets battery life, data volume, and the shape of your platform bill for the next three years. Hardware makes all of those choices at once, and they are the hardest ones to reverse. Returning a dev kit is easy. Replacing four hundred installed sensors with the wrong radio is a project restart.

The fix is a scoping sequence that produces a one-page scope before any purchase order, then proves it on the platform with a simulated device. Hardware comes last, and by then you know what to order.

![Scope first, hardware last: seven scoping steps run from the decision and who makes it through variables, sites, device counts, users, integrations, and acceptance criteria into a one-page scope you simulate on a device, with the hardware order only at the end and a marker showing most teams start at the order instead](https://tago.io/images/blog/scope-an-iot-project-before-buying-hardware/scope-first-hardware-last.svg)

## Step 1: name the decision the data must change

Every IoT project that pays for itself changes a decision somebody makes today without data. Write it down in one sentence with a named role: "the site manager decides which cold rooms to inspect each morning," or "the maintenance lead decides when to replace pump seals." If the sentence needs the word "insights," it is not finished.

This step decides everything after it. A decision made once a day tolerates a sensor that reports hourly. A decision that stops a production line needs seconds. Teams that skip it end up with a dashboard nobody opens.

## Step 2: list the variables, units, and reporting interval

From the decision, work backwards to the minimum data: which variables, in which units, at which interval, with what accuracy. Temperature to 0.5 C every 15 minutes is a different sensor, battery budget, and data volume than temperature to 0.1 C every minute.

The interval is the number that hides the cost. A sensor reporting every minute produces 60 times the data of one reporting hourly, drains its battery in a fraction of the time, and pushes a fleet toward the higher tiers of any platform's data input pricing. Set the interval from the decision in Step 1, not from the sensor's default.

## Step 3: check the sites and their connectivity reality

List every site where a device will live, then answer for each one: what radio actually reaches it? LoRaWAN needs a gateway with a real path to the sensor location, and basements, metal enclosures, and dense concrete cut the datasheet range by a lot. Cellular needs carrier coverage inside the building, not outside it. Wi-Fi needs the customer's IT department to say yes, in writing, about a network you do not control.

A coverage test costs an afternoon and one borrowed gateway. Skipping it is how a project specced for LoRaWAN ends up on cellular at three times the unit cost. Read [LoRaWAN range in the real world](https://tago.io/blog/lorawan-range-in-the-real-world) before you assume a number.

## Step 4: count the devices at pilot and at year three

Two honest numbers: how many devices in the pilot, and how many if the pilot succeeds and rolls out for three years. The pilot number sizes your first order. The year-three number sizes everything else: which pricing model makes sense, and which platform limits you will hit first (data input, data output, storage, notifications).

A pricing model that is cheap at 30 devices can be the expensive one at 3,000. [IoT platform pricing models compared](https://tago.io/blog/iot-platform-pricing-models-compared) walks through the shapes. Write the year-three number down even if it is a guess; a guess on paper gets corrected, a guess in someone's head does not.

## Step 5: define who the users are and what they see

Separate the people who build the application from the people who use it. On TagoIO the builders work in Admin: they add devices, write Payload Parsers, build Dashboards, configure Actions. The end users, the site manager from Step 1, log into a TagoRUN portal under your brand, on the web or in the mobile app, and see only what their Access Management policy grants.

For each user role, write what they see and what they can do: which sites, which dashboards, which alerts on their phone, and whether they can change thresholds or only view. If a role needs push notifications on a job site, the mobile app is in scope from day one, which changes how you lay out the dashboards.

## Step 6: list the integrations that must exist

Most IoT projects end in another system. The alert has to become a ticket. The daily totals have to land in the ERP. Write each integration down with its direction (inbound or outbound), its trigger (on event, on schedule), and its protocol (webhook, REST API, file drop). On the platform these become an Action posting to a webhook or a scheduled Analysis calling the external API.

A missing integration is the most common reason a finished pilot never goes to production: the data was right, but it never reached the system that acts on it.

## Step 7: write the acceptance criteria for the pilot

Before hardware, agree on what "the pilot worked" means. Data delivery uptime per device. Alert latency from event to notification. Battery consumption against the projected life. The Step 1 decision, actually made from the dashboard, by the person named, for a set number of weeks.

Criteria written now are cheap. Criteria negotiated after a pilot that half-worked are expensive, because every stakeholder remembers a different promise. Put them on the scope next to the name of the person who signs off.

## Map the scope to platform objects, then simulate the first device

Every line on the one-page scope maps to something you can build on the platform today, without a sensor in hand:

- Variables and units (Step 2) become a Device with named variables. Its [Connector](https://docs.tago.io/docs/tagoio/devices/adding-devices-with-connectors) or Payload Parser decodes the payload the candidate hardware will send.
- Sites and connectivity (Step 3) become the Network for the device and the tags that group devices by site.
- Users and views (Step 5) become Dashboards and an [Access Management policy](https://docs.tago.io/docs/tagoio/tagorun/access-management) that shows each TagoRUN user their sites only.
- Integrations (Step 6) become [Actions](https://docs.tago.io/docs/tagoio/actions/defining-actions) with a condition and a webhook target, or a scheduled Analysis.
- Acceptance criteria (Step 7) become the alert thresholds and the widgets you will judge the pilot by.

Then create one device, take the sample payload from the candidate sensor's datasheet, and post it through the API at the Step 2 interval. Within an hour you have a dashboard showing the decision data, an alert on your phone through the TagoRUN app, and a webhook hitting a test endpoint. You also know whether the payload carries the variables you need, whether the interval reads well on a chart, and whether the end user understands the screen.

Now order the hardware. You are buying to a specification the team has seen working, and if the first real device disagrees with the simulation, you find out on day one instead of at rollout.

## Resources

- [Planning an IoT project as a non-technical project manager](https://tago.io/blog/planning-an-iot-project-non-technical-pm)
- [The true cost of a mid-market IoT deployment](https://tago.io/blog/true-cost-of-a-mid-market-iot-deployment)
- [LoRaWAN range in the real world](https://tago.io/blog/lorawan-range-in-the-real-world)
- [Adding devices with Connectors](https://docs.tago.io/docs/tagoio/devices/adding-devices-with-connectors)

[llms.txt](https://tago.io/llms.txt)