IoT Product Development: From Idea to MVP in 90 Days
The end-to-end process we use to take IoT products from concept to a working, deployable MVP — and what actually happens in each phase
Start your IoT project →
There is a wide gap between "I have an IoT idea" and "I have a product people can actually use." That gap contains PCB revisions, firmware bugs discovered at 3 AM, cloud pipelines that pass all tests and fail in the field, and hardware procurement delays nobody warned you about. We have been in that gap, repeatedly, across projects ranging from a smart vending machine deployed at Jersey Airport to a miniaturised golf ball with BLE telemetry running on a coin cell.
The 90-day IoT MVP framework we run at DigitalMonk is not a marketing promise — it is the actual sequence of work we execute on every new IoT product engagement. It is calibrated to a tightly scoped MVP: one primary use case, one hardware platform, one connectivity method. When scope holds, 90 days produces a working, deployable product that real users can interact with. When scope creep enters — and it always tries to — timelines slip proportionally. We will be direct about that throughout this article.
Below is the full playbook: seven overlapping phases, real deliverables at each stage, and the honest constraints that determine whether you hit the timeline or miss it. If you are a founder, CTO, or product leader evaluating how to bring an IoT product to market, this is the process we would walk you through as an IoT product development company that has done it across vending, sports tech, cold chain, and industrial monitoring.
The 90-Day IoT MVP Framework — Overview
The seven phases below are intentionally overlapping. Hardware prototyping starts before architecture is fully locked. Firmware development begins on dev boards while the custom PCB is still at the fab. Cloud work runs concurrently with field testing. That parallelism is what makes 90 days achievable — a purely sequential approach takes four to six months.
Phase 1: Discovery & Scoping (Weeks 1–2)
Every IoT project we have seen fail in month three failed in week one — specifically, in the conversation that didn't happen about what the product actually needs to do. Discovery is not a soft kick-off exercise. It is an engineering conversation about constraints that determines everything downstream.
In week one we map the actual problem against the assumed problem. These are often different. A client came to us wanting a "real-time cold chain monitor." What they actually needed was an alert when temperature exceeded a threshold for longer than 15 minutes — a fundamentally different data pipeline and power budget. That single clarification saved two hardware revisions and roughly three weeks.
- 1Use cases and environmental constraints
Who uses the device, where, how often, and under what conditions? Outdoor, industrial, or medical environments impose constraints that determine MCU selection, enclosure IP rating, and power budget before a line of firmware is written.
- 2Ruthless MVP scoping
We run a must-have vs. deferred exercise with the client. Every feature added to the MVP scope adds time. The MVP should do one thing reliably — additional features belong in version 1.1, not in the 90-day sprint.
- 3Connectivity and power budget
BLE, WiFi, cellular, or LoRa? Battery-powered or mains? These choices are locked here because they cascade into every subsequent decision — MCU, antenna, PCB area, firmware architecture, and cloud infrastructure.
Phase 2: Architecture & Component Selection (Weeks 2–4)
With the spec agreed, we design the system architecture and lock the bill of materials. This is the most consequential engineering decision point in the project — wrong choices here are expensive to reverse.
| Platform | Best For | Trade-off |
|---|---|---|
| ESP32 | WiFi + BLE, rapid prototyping, cost-sensitive products | Higher idle power draw; not ideal for coin-cell battery targets |
| nRF52 series | BLE-first, ultra-low-power wearables and sensors | No native WiFi; needs external modem for cellular |
| STM32 | Industrial control, precise timing, real-time determinism | More configuration overhead; steeper initial setup |
| Raspberry Pi CM | Linux-based edge compute, camera vision, complex UI | Overkill for simple sensor nodes; higher cost and power |
Component availability is a constraint most teams underestimate. Designing around a part with a 40-week lead time turns a 90-day MVP into a 12-month project. We cross-reference every architecture decision against real-time distributor stock levels before committing to a BOM, and we flag components with limited lifecycle visibility — a sensor one generation from EOL is a production re-spin risk hiding in your schematic.
Deliverable: A system architecture diagram that every engineer on the team can work from, plus a draft BOM with at least two approved alternatives for every critical component.
Phase 3: Prototyping & Hardware (Weeks 3–7)
Hardware development follows a deliberate progression: breadboard to dev board to custom PCB. Each step has a purpose, and skipping steps costs more time than it saves.
- 1Breadboard and dev board phase
We wire up the core functional loop using off-the-shelf dev boards — an ESP32-DevKitC, an nRF52 DK, or a Raspberry Pi CM4 carrier. The goal is to validate the sensor chain, connectivity, and data format before spending money on PCB fabrication. A mistake at this stage costs an afternoon; the same mistake on a custom PCB costs two weeks and a fabrication run.
- 2Custom PCB design and fabrication
Once the dev-board prototype is functional, we move to schematic capture and PCB layout. For MVP hardware we typically use a 2-layer board with conservative design rules — keeping fab costs low and yield high. PCB fabrication takes 5–10 days; assembly adds 3–7 days. That calendar time is not compressible, which is exactly why Phase 4 firmware work begins on dev boards in parallel.
- 3First functional prototype milestone
The first assembled PCB is a validation exercise, not a finished product. We test basic power-on, communication buses, and sensor responses. Finding a footprint error or an I²C address conflict here is a 48-hour setback. Finding it after 200 units are assembled is a crisis. Thorough bring-up procedures — including current draw measurement on every power rail — are not optional.
Phase 4: Firmware Development (Weeks 5–9)
Firmware is where IoT products live or die in the field. A technically correct hardware platform paired with unreliable firmware produces a product nobody wants to deploy. Our firmware development is structured around three non-negotiables: power management, OTA updates, and a reliable core product loop.
Bare metal vs. RTOS: Simple products with a single task (read sensor → transmit → sleep) work fine bare-metal. As soon as you add concurrent concerns — BLE stack management, power state transitions, sensor fusion, local storage — a real-time OS earns its keep in reliability. We default to Zephyr for Nordic-based products and FreeRTOS for ESP32 and STM32 targets.
OTA from day one: Build OTA update capability before you ship a single unit to a pilot user. The first firmware deployed to field hardware will have bugs. Without OTA, fixing them requires physical access to every device. With OTA, a firmware update pushes over BLE or WiFi in the background. We have never had a client regret building OTA in early. We have had clients regret not building it.
Power management: For battery products, power architecture is a first-class firmware concern, not an afterthought. We profile current draw across every operating mode — active, idle, deep sleep, peak transmit — and validate projected battery life against measured numbers. A device that reads "14-day battery" on the datasheet and delivers three days in the field fails on the metric that matters most to users.
Deliverable: Firmware that runs the core product loop reliably for 72 continuous hours on dev boards, with OTA update path proven at least once end-to-end.
Phase 5: Cloud & Connectivity (Weeks 6–10)
The cloud side of an IoT product is where hardware teams most often hit their blind spot. Device data arriving in a cloud database is not a product — it is infrastructure. A product also needs device provisioning, authentication, a data pipeline that handles intermittent connectivity gracefully, and an interface for users to actually see and act on the data.
Device Provisioning
Each device needs a secure identity at manufacture time. We use certificate-based authentication (mutual TLS or device certificates via AWS IoT Core / Azure IoT Hub) so a compromised device credential cannot impersonate others or escalate cloud access.
Data Pipeline
IoT devices disconnect — often. The pipeline must handle retransmission, deduplication, and out-of-order packets without losing data. We build MQTT or AMQP message queuing with local buffering on the device for offline resilience.
Dashboard & API
The MVP deliverable is data a human can act on — not a raw data table. We scope a minimal dashboard or API that turns sensor readings into actionable outputs, with alerts or rules the pilot users can configure themselves.
Phase 6: Integration & Testing (Weeks 9–12)
This is where a demo that worked perfectly on the bench meets conditions it was never designed to survive. Real-world integration testing is where most IoT projects discover their actual limitations — and where timelines slip most predictably.
- 1End-to-end system integration
Hardware, firmware, and cloud working together for the first time under realistic load. Latency numbers, packet loss rates, and reconnection behaviour are measured against spec. Timing races, cloud throttling, and RF interference in real environments appear here — not in unit testing.
- 2Field testing in realistic conditions
Temperature extremes, RF-hostile environments (metal enclosures, dense WiFi channels, multi-path reflection), physical shock, and continuous operation over 48–72 hours. A device that runs flawlessly for 20 minutes in a lab can fail after 6 hours in a warehouse. We find this before the pilot user does.
- 3Battery and power validation
We run the actual use-cycle profile against measured current draw to validate projected battery life. If the result doesn't match the spec, firmware power management gets a second pass before pilot deployment — not after the first batch of negative user feedback.
- 4EMC pre-compliance (if applicable)
If the product will need FCC, CE, or BIS certification, we run a desktop EMC pre-compliance scan during integration testing. A radiated emissions issue found here costs a week; the same issue at a formal test lab costs weeks plus lab fees plus travel. Pre-compliance is not box-ticking — it is cost control.
Phase 7: Deployment & Handoff (Weeks 11–13)
A working system in your office is not an MVP. An MVP is a working system in the hands of real users, operating under real conditions, with a defined process for monitoring, updating, and iterating it. Phase 7 is the bridge from "it works" to "it ships."
- 1Pilot deployment
We deploy to a small, controlled cohort — typically 5–20 devices. The pilot surfaces what testing couldn't: user provisioning friction, real-world connectivity edge cases, and the feature gaps that users care about but didn't appear in the requirements document.
- 2Documentation and knowledge transfer
Every project we hand off includes firmware build and flash instructions, hardware test procedures, cloud deployment runbooks, and OTA update procedures. A product whose development process lives only in one engineer's head is a liability, not an asset.
- 3Manufacturing readiness (if scaling)
For clients moving from MVP to an initial production run, we prepare production test fixtures, flash jigs, and a production test procedure. This is not required for the 90-day MVP, but it is scoped and planned at this stage so it doesn't become a surprise when volume ramp begins.
Real-World Timelines: Two DigitalMonk Projects
Abstract frameworks are useful. Concrete examples are more useful. Below are two IoT products we have shipped — with the honest version of how the 90-day phases applied to each. For a tighter example of what the process looks like at speed, see our custom air quality monitor case study — from initial brief to working, fabricated units in 16–18 days.
BudKoin Smart Vending Machine
BudKoin came to us with a clear concept: a smart vending machine that accepted cryptocurrency payments and operated at a licensed retail location. The hardware complexity was high — inventory sensors, a payment terminal integration, a cloud-connected stock management system, and a physical enclosure designed for a real commercial deployment.
Discovery took longer than two weeks here. The payment integration introduced regulatory and compliance constraints that had to be architected from the start — constraints that would have caused a full re-architecture if we had skipped Phase 1. We settled on an ESP32-based controller handling the sensor network, with a Raspberry Pi managing the display and payment terminal — a split that kept the critical payment path isolated from the sensor layer.
What made BudKoin complex was not any single technical challenge but the integration surface area: hardware, firmware, cloud, payment API, and a companion app all had to work together reliably enough for a public retail deployment. The parallel development structure — firmware on dev boards while PCBs were at the fab, cloud running alongside hardware assembly — kept the project from expanding to the six months a sequential approach would have taken.
Read the full BudKoin case study →Smart Golf Ball
The Smart Golf Ball was a constrained product in the most demanding sense: a sensor-laden device that had to fit inside a regulation golf ball, run on a coin cell, survive repeated impacts exceeding 150 g, and transmit launch telemetry over BLE within 500 ms of impact. There was no margin for anything.
We chose the nRF52840 for ultra-low-power operation and BLE 5 support. The PCB was a four-layer miniaturised board — roughly 25 mm across — with an IMU, power management IC, and antenna competing for space. Firmware was entirely interrupt-driven: the BLE stack woke on the impact event rather than polling continuously, which was the only architecture that met the coin-cell power budget.
Hardware prototyping took longer than average because of miniaturisation constraints — two PCB revisions to resolve thermal and antenna coupling issues. But because firmware development started on nRF52 dev boards during that wait, the total project timeline remained within the 90-day framework. The phased, parallel structure was not a convenience — it was a necessity.
Read the Smart Golf Ball case study →What Can Blow the 90-Day Timeline
This is a battle-tested playbook, which means we have also seen it break. The following are the real timeline killers, ranked roughly by how often we encounter them in practice.
- 1Scope creep mid-project
The single largest cause of blown timelines. Every feature addition mid-sprint re-opens architecture, firmware, and testing. The MVP scope document — agreed and signed off in Phase 1 — is the only effective protection. "Can we also add X?" is a question for version 1.1.
- 2Component shortages and long-lead parts
Post-2020 semiconductor supply chains remain unpredictable. A preferred MCU with a 26-week lead time is not a component choice — it is a project constraint. We cross-reference BOM components against real-time distributor stock at Phase 2, not when we are ready to place the production order.
- 3Underestimating certification
FCC, CE, BIS, and UKCA certifications are not rubber-stamp exercises. Pre-testing, formal lab time, and remediation can add 6–10 weeks to a project. If your product needs certification before commercial deployment, this must be in the project plan from Phase 1 — not treated as a post-MVP problem.
- 4Skipping the discovery phase
Covered above, worth repeating: projects that skip Phase 1 almost always hit a fundamental requirements conflict in Phase 4 or 5. Reworking the architecture at week seven is not a setback — it is a restart, with a team that is already six weeks invested in the wrong direction.
- 5Hardware iteration loops
A PCB revision takes 10–14 calendar days minimum. Two unplanned revisions is a month of slip on its own. Thorough design reviews before fabrication — checking power rails, signal integrity, antenna keep-outs, and mechanical fit — are the only mitigation. Budget for at least one revision regardless; no design review catches everything.
Frequently Asked Questions
Can any IoT product really be built in 90 days?
An IoT MVP — one core use case, one hardware platform, one connectivity method — yes. A full commercial product with multiple hardware variants, enterprise cloud dashboards, and regulatory certification across multiple markets? No. Ninety days scopes to a deployable MVP that proves the concept with real users. The path from MVP to commercial product is a separate engagement, informed by what the pilot teaches you.
What is the difference between an IoT prototype and an MVP?
A prototype demonstrates that the technology works in a controlled environment. An MVP is a product that works reliably enough for real users to depend on it — with OTA update capability, cloud connectivity, device provisioning, basic monitoring, and a known failure mode for the issues not yet solved. The gap between the two is where most IoT projects stall indefinitely.
How much does IoT product development cost?
A 90-day IoT MVP engagement with a full-stack team — hardware design, firmware, cloud, and testing — typically ranges from $25,000 to $80,000 USD depending on hardware complexity, connectivity, and cloud infrastructure scope. A simple BLE sensor with a mobile companion app sits at the lower end. A payment-integrated vending machine with a cloud management dashboard sits at the upper end. We scope fixed-price engagements after the discovery phase, not before.
Should I build custom hardware or use off-the-shelf modules for my MVP?
Off-the-shelf modules for the MVP, almost always. Development modules and reference boards let you validate firmware and cloud infrastructure while your custom PCB is still in design review. Custom hardware integration — removing the module and going direct to silicon — is a production cost optimisation, not an MVP requirement. The BOM savings at 10,000 units are irrelevant when you are building 20 pilot units.
What connectivity should my IoT product use?
It depends on three factors: range, power budget, and available infrastructure. BLE works for short-range (10–100 m) battery devices that pair with a phone or local gateway. WiFi works for mains-powered devices in fixed locations with reliable network coverage. Cellular (LTE-M or NB-IoT) works for wide-area or mobile deployments with no local network. LoRa works for long-range, low-data-rate sensors in areas without cellular. We help clients make this decision in Phase 1 — because the answer cascades into every hardware and firmware decision downstream.
How do I handle IoT security from the start?
Four basics: unique device identity (certificates or hardware-rooted keys, not shared secrets), encrypted transport (TLS for MQTT/HTTPS, never plaintext), firmware signature verification for OTA updates, and network segmentation that isolates IoT devices from your main corporate network. These are architecture decisions that belong in Phase 2. Every week they are deferred adds rework cost and audit surface.
What happens after the 90-day MVP is done?
The MVP delivers a deployed, monitored product with real pilot users and real feedback. Post-MVP work typically covers three tracks: feature expansion (based on what the pilot actually told you users need), production scale preparation (custom PCB miniaturisation, BOM cost reduction, manufacturing test fixtures), and certification (FCC, CE, BIS if not already completed). Most clients continue with our team into this phase — the engineering context built during the MVP sprint is genuinely valuable and expensive to rebuild with a new team.
Do I need certification for my IoT product?
If your product uses radio (BLE, WiFi, cellular, LoRa), yes — eventually. FCC (US), CE (EU), BIS (India), and UKCA (UK) are mandatory for commercial sale in those markets. For a pilot deployment with a small known cohort, most markets allow pre-certification testing under a research or pilot exemption. Plan for certification before you plan for commercial launch, and factor 6–10 weeks and $5,000–$25,000 in lab and remediation costs into the budget.
Have an IoT Product Idea?
We have taken products from napkin sketch to deployed hardware across vending, sports tech, cold chain, and industrial monitoring. Let us map out your 90 days.
Talk to our IoT team →