Should You Build That IoT Product?

By Alban Sanchez, CEO LMD - This article has been published on our LinkedIn page.

A rigorous, founder-friendly playbook to assess technical  and  economic  feasibility—before you spend serious money

IoT can be transformative—or a money pit. The difference isn’t the buzzword count in your deck; it’s whether the data your product creates is worth more than the system required to create it. That sounds obvious, but it’s exactly where otherwise solid ventures go sideways.

Years ago, our team explored a animal-monitoring wearable concept: tags for geolocation, body temperature, and theft deterrence. Technically viable. Connectively sound. But each tag cost roughly 20% of the value of an animal. Net: the annual loss avoided didn’t justify the hardware + service + ops stack. We killed it—rightly. The lesson: IoT is only as good as the economic value of the data it collects. If the data isn’t materially changing decisions, reducing risk, or generating revenue, you’re building an academic exercise, not a business.

This article distills a practical feasibility framework we use with founders and corporate innovators, adapted from Lantern’s Process / Deliverables / Timeline methodology and our co-creation approach with clients. We’ll show how to test both the physics and the finances—fast—and how to set kill criteria that protect your runway. 

Executive Snapshot: The 3 Questions That Decide Feasibility

1. Data Value: What is a single device’s annual data worth in avoided cost, new revenue, or reduced risk?

2. Unit Economics: Can you deliver, connect, power, secure, and support the device for less than the value above, with attractive payback (<12–18 months for B2B is common)?

3. Scale Reality: Can you manufacture, deploy, and service thousands of units with predictable quality, compliance, and margin?

Treat everything below as a way to answer those three questions quickly and defensibly.

Step 1 — Define the Decision the Data Will Change

The problem: Many IoT proposals start with “we can measure X,” then search for a buyer. That inverts the path to value. Begin by naming the high-stakes decision you will improve: dispatch, inventory turns, predictive maintenance, safety compliance, loss prevention, SLA penalties, energy costs, or throughput.

How to do it well:

• Write one sentence: “We will help [role] decide [action] to achieve [measured outcome] within [time window].”

• Attach an economic anchor (per site, per asset, per route). If you can’t quantify today’s cost, your buyer can’t either.

• Identify the moments of truth: alarms, thresholds, rules, and workflows that create savings or revenue.

Co-creation matters: Your domain partner knows the operations; you know the sensors, firmware, and cloud. Treat it as a joint venture from day one. Our co-creation approach is explicit about shared goals, transparency, and designing the business model together—not a vendor hierarchy. 

Step 2 — Model the Data Economics

IoT is a factory that prints data. Your feasibility test is: does the data sell for more than it costs to print?

Build a simple P&L per device (annualized):

• Value of data: avoided losses, new revenue, SLA credits avoided, insurance premium reduction, compliance cost reduction.

• Direct costs: hardware BOM + assembly; connectivity (cellular/LPWAN/Wi-Fi backhaul); cloud processing/storage; security & compliance; logistics & install; maintenance & replacements; customer support.

• Gross margin: (Value − Direct costs) / Value.

• Payback: total CAPEX / monthly net benefit.

Reality check with market scale: there are ~16.6B connected devices (2023) heading toward ~18.8B (2024), but most value is concentrated in specific, well-defined use cases—not “connect everything.” Choose your niche with ruthless clarity. 

Step 3 — Validate Sensing Feasibility (Physics Before PowerPoint)

Not everything that’s valuable is measurable—reliably, cheaply, and at scale.

Checklist:

• Measurand & environment: What are you measuring (force, temp, vibration, location, presence)? At what range, resolution, sampling rate? Indoors/outdoors, vibration, dust, chemicals, wash-downs?

• Sensor availability: Is there a proven COTS sensor? Custom silicon? Temperature drift? Calibration needs? MTBF?

• Mounting & tamper: Can you physically place and protect it? What’s the installation time and failure rate?

• Regulatory/safety: Any radio approvals, electrical safety, or environmental certifications needed for your segment?

Kill criteria example: “If we can’t get ±0.5°C accuracy across -20–50°C with <5% drift over 12 months at <$10 sensor cost, we stop.”

Step 4 — Power Budget & Enclosure Reality

Your energy budget is destiny. It dictates battery size/chemistry, enclosure dimensions, and maintenance cycles.

• Calculate worst-case current draw (sensing + processing + radio Tx/Rx + sleep).

• Model duty cycles for real traffic patterns, not lab ideals (e.g., burst uploads at shift changes).

• Consider energy harvesting only with convincing field evidence.

• Enclosure: IP rating, UV stability, ingress, thermal management, agency labels.

If your business case assumes “never change batteries,” your technical plan must prove it.

Step 5 — Connectivity Choice is a Business Decision (Not Just RF)

Connectivity shapes TCO, coverage, and battery life. There is no one-size-fits-all:

• On-prem short-range (BLE, Wi-Fi, Zigbee): great for controlled environments with gateways.

• Low-power wide-area (LoRaWAN, NB-IoT, LTE-M): best for long battery life, sparse data, and wide coverage.

• Cellular broadband / 5G: for video/edge compute, mobile assets, or when you piggyback on existing SIM deals.

Tip: future market growth is real (e.g., cellular IoT connectivity projected to reach ~$30B revenue by 2030), but your bill is paid device by device. Negotiate hard and simulate traffic precisely. 

Step 6 — Edge vs. Cloud (Latency, Cost, and Resilience)

Push logic to the edge when you must (latency, bandwidth cost, offline operation), and keep your system of record in the cloud for auditability and analytics. Edge and cloud aren’t rivals; they’re a division of labor. Design for degraded networks and graceful recovery. (If your alarms only work with perfect connectivity, they don’t work.)

Step 7 — Security, Privacy, and Trust (Right-Sized for Your Market)

Security is not a premium feature; it’s table stakes for contracts and brand survival.

• Baseline controls for small/medium deployments: unique device identities, least-privilege access, encrypted transport/storage, patchable firmware, and audit trails. NIST’s IoT program and practice guides (e.g., MUD to constrain device traffic) are actionable starting points—even for startups. 

• Procurement reality: Many enterprise customers won’t move without a security questionnaire answered in depth. Document your controls early; it saves quarters later.

  
  

Step 8 — Compliance & Liability

Even outside healthcare, regulated processes and electronic records come with expectations (e.g., auditability similar in spirit to 21 CFR Part 11 in pharma/medical manufacturing contexts). If your product influences safety, quality, or regulated reporting, design for tamper-evident logs, role-based access, and durable retention from the start. Your legal exposure shrinks when your evidence is good.

Step 9 — Unit Economics & Pricing Scenarios

Price from outcomes, charge for deployments. But price discipline rests on credible cost models:

• CAPEX per device: enclosure + PCB + sensors + battery + assembly + test + packaging.

• OPEX per device per month: connectivity + cloud + observability + support + replacements + warranty accrual.

• Services: install time, provisioning, customer success.

• Overheads: R&D amortization, certification, channel margin.

Run three scenarios: conservative, expected, and best-case. Establish a kill line (e.g., if gross margin < 60% at expected volume, stop or redesign).

Step 10 — Field Validation Plan (Design Your Learning)

Your first 10–50 installs should answer questions, not just generate dashboards.

• Define learning objectives: accuracy, battery life, installation time, false positives, network coverage holes, user behavior.

• Pre-write your “red team” test cases (tamper, jamming, dead zones, firmware rollbacks).

• Put in telemetry for your telemetry: device health metrics, not just sensor data.

A Proven Delivery Cadence (So You Don’t Boil the Ocean)

Lantern’s delivery model is intentionally staged to learn fast, de-risk, and scale only when the math works:

1. Guided Innovation (Days → Weeks)

   • Design thinking, product scope, conceptual mockups, lifecycle mapping (supply chain, certifications, support, RMAs).

   • Outputs: decision narratives, early mockups, and a straw-man business model tied to the decision you’ll change. 

2. Rapid PoC/MVP (≈2–3 months)

   • Architecture, hardware selection/design, firmware/software, dashboards, limited deployment plans; iterate across learnings.

   • Goal: prove physics and unit economics; collect install times, failure modes, and battery curves in the real world. 

3. Scale (≈6+ months and beyond)

   • Manufacturing docs, pricing, business modeling, enterprise integrations, logistics, tech support, and feedback loops for continuous improvement.

   • Only proceed if the per-device P&L and operational metrics hit thresholds you pre-defined in Steps 2 and 9. 

This rhythm isn’t theory—it’s how we translate inventions into scalable products while protecting capital, matching what we lay out publicly in Lantern’s Process / Deliverables / Timeline methodology. 

The Co-Creation Contract (With Your Customer, Not Just Us)

IoT rarely wins as a pure “build it and they will come” play. The diversity of “things,” environments, and business cases means specialization wins. The fastest path to ROI is partnering deeply with the domain owner—designing the solution, the deployment playbook, and the business model together. That’s why we treat product creation as a co-creation venture with shared objectives and transparent economics. 

A Founder’s Feasibility Scorecard (print this)

Data Value

• We can quantify the annual value per device/site in dollars.

• The decision our data changes is clear, frequent, and high-stakes.

Physics & Power

• A COTS sensor exists (or we have a credible path to custom).

• Power budget meets battery/service targets with field-representative duty cycles.

Connectivity

• Coverage exists where we need it (measured, not assumed).

• The traffic model matches our cost envelope.

Security & Compliance

• Devices have unique identities, encrypted comms, and a patch path.

• We log who/what/when/where in a tamper-evident way. (Borrow from NIST practice guides if you’re early.) 

Unit Economics

• Hardware, connectivity, cloud, and ops costs modeled in three scenarios.

• Gross margin ≥ target; payback within 12–18 months (B2B benchmark).

Field Validation

• A 10–50 unit pilot plan with pre-agreed success/kill criteria.

• Instrumentation for reliability, install time, and failure modes.

Scale Readiness

• Manufacturing docs, certification path, install & support playbooks defined.

• Enterprise integrations and pricing aligned with buyer procurement.

Case Study (Hypothetical): Cold-Room Compliance for Food Distribution

• Decision to change: stop spoilage and audit failures across 120 warehouses.

• Data value: current losses ~$2.4M/year; audits cause ~$300k in remediation.

• Design: battery sensors with door-open correlation; LoRaWAN + gateways; rules engine for supervisors.

• Unit economics: $28 BOM, $2.50/month connectivity & cloud, $1.25/month support. Expected benefit: $8–12/month per cold room (loss avoidance + labor savings).

• Pilot (30 days, 20 sites): 11 critical excursions caught; two compressor failures predicted. Battery model shows 2.8-year life.

• Go/no-go: pass (payback < 9 months).

• Scale: manufacturing docs, installer training, immutable compliance logs—designed with retention and auditability from day one (inspired by regulated-industry recordkeeping discipline).

• Security baseline: unique device certs, least-privilege access, encrypted transport/storage, and network behavior controls aligned with NIST guidance. 

Red Flags That Kill Feasibility Early (and Should)

• Unpriced value: “We’ll figure out the ROI after the pilot.” (You won’t.)

• Sensor optimism: Physics that only works in the lab.

• Battery fantasy: Claims of “five years” with a daily video clip.

• Connectivity hand-wave: “There’s coverage everywhere.” (There isn’t.)

• Security later: No device identities or update path.

• Scaling afterthought: No plan for manufacturing tolerances, field replacements, or audit-proof logs.

The Market Is Big. Your Niche Must Be Precise.

Analysts estimate IoT could enable trillions in value by 2030—but that value isn’t generic; it accrues to specific jobs-to-be-done where data changes money decisions. Pick a sharp use case, co-create with domain experts, and run a disciplined roadmap from guided ideation → PoC/MVP → scale. 

That’s how you avoid the trap we saw in livestock monitoring: a technically elegant solution that fails the data economics test.

If You’re Starting Now

• Begin with one decision you can measurably improve.

• Put a price on your data.

• Prove the physics, power, and connectivity in the field—fast.

• Instrument everything so your evidence is ready for customers, auditors, and investors.

• Co-create the business model with the people who own the problem.

At Lantern/LMDlogic, we’ve formalized this into a paced delivery model because the fastest way to win in IoT is to say no early to what won’t scale—and double down where the data pays for itself. 

What decision do you want your data to change—and what’s that decision worth?