Desarrollo IoT: coste, stack y proceso (guía 2026)

Marcus Chen Staff Engineer, Backend & Cloud, YuSMP Group · Crea plataformas conectadas y backends en la nube para equipos de producto de EE. UU. y la UE

¿Qué es el desarrollo de software IoT?

El desarrollo de software IoT es el proceso integral de crear el software que hay detrás de los productos del Internet de las cosas: dispositivos físicos (sensores, máquinas, wearables, vehículos o electrodomésticos) que recogen datos, los envían por una red y actúan según lo que se deduce de ellos. Abarca cuatro mundos distintos: el firmware embebido en el dispositivo, la conectividad que mueve los datos, la plataforma en la nube que los recibe y almacena, y las aplicaciones y paneles que las personas usan de verdad.

Como une esos mundos, el IoT es una de las categorías de software más difíciles de acertar: pocos equipos reúnen internamente competencias de sistemas embebidos, redes, nube y datos, así que la mayoría de las empresas que crean un producto conectado recurre a un partner para unos servicios de ingeniería de producto integrales que cubran todo el stack y no solo una parte. Esa amplitud es también la razón por la que tantos pilotos se estancan: una investigación de Cisco y McKinsey ha concluido que entre el 60 % y el 75 % de los proyectos IoT no logra escalar más allá de la fase piloto, normalmente porque los equipos subestiman la gestión de flotas, dan la conectividad por resuelta o dejan la seguridad y el cumplimiento para el final.

Esta guía recorre las capas de la arquitectura IoT, el stack moderno y el software de desarrollo, los protocolos de conectividad que importan, rangos realistas de coste y plazo en 2026, el proceso de desarrollo paso a paso y las normas de seguridad (con el Reglamento de Ciberresiliencia de la UE a la cabeza) que ya condicionan todo producto conectado que se vende en Europa. El objetivo es que tenga una idea clara de lo que va a encargar antes de redactar un briefing o firmar un contrato.

Las cuatro capas de la arquitectura IoT

Todo sistema IoT se construye con cuatro capas, y la salud de todo el producto depende de lo bien que encajen. Entenderlas es la forma más rápida de delimitar un proyecto con honestidad, porque cada capa tiene su propio coste, su propio riesgo y su propio perfil de especialistas.

1. Capa de dispositivo / percepción. El hardware físico (microcontroladores, sensores y actuadores) y el firmware que se ejecuta en él. Aquí nacen los datos y aquí son más estrictas las restricciones de energía, memoria y coste.
2. Capa de conectividad / red. Cómo viajan los datos del dispositivo a la nube: Wi-Fi, red móvil (LTE-M/NB-IoT), LoRaWAN o Bluetooth Low Energy, con un protocolo de mensajería como MQTT. Equivocarse aquí es el motivo más común de que las flotas no logren escalar.
3. Capa de nube / plataforma. La plataforma IoT que recibe los datos, mantiene un registro de dispositivos, almacena series temporales, ejecuta reglas y gestiona las actualizaciones por aire (OTA). Aquí se sitúan AWS IoT Core, Azure IoT Hub o Google Cloud.
4. Capa de aplicación. Las apps web y móviles, los paneles, las alertas y la analítica que convierten la telemetría en bruto en algo sobre lo que una persona u otro sistema puede actuar.

Una quinta cuestión, la computación en el edge, se sitúa entre las capas de dispositivo y de nube: ejecuta lógica cerca del hardware para que las decisiones se tomen en milisegundos y solo viaje a la nube lo que resulta útil. El procesamiento en el edge puede reducir el ancho de banda en torno al 95 % y los costes de nube hasta un 80 %, razón por la cual ha pasado de opcional a estándar en cualquier flota de cierto tamaño. Está muy relacionada con la tendencia de inteligencia en el dispositivo que tratamos en nuestra guía de IA en el dispositivo en apps móviles.

El stack tecnológico del desarrollo IoT en 2026

El stack IoT moderno se corresponde directamente con las cuatro capas, con una herramienta por defecto bien establecida en cada una. Cuando se busca «software de desarrollo IoT», esta es la respuesta práctica: no un único programa, sino un stack coordinado.

La elección que condiciona todo lo demás es la plataforma en la nube. Una plataforma IoT gestionada como AWS IoT Core o Azure IoT Hub ofrece de serie identidad de dispositivos, mensajería segura, un motor de reglas y actualizaciones OTA, lo que casi siempre sale más barato que construir esas primitivas por cuenta propia. Construir el producto conectado sobre esa plataforma es un esfuerzo clásico de desarrollo de producto de software: la misma disciplina de descubrimiento, arquitectura e iteración, aplicada a hardware más software en lugar de solo software.

¿Cuál es el mejor protocolo para la comunicación IoT?

MQTT es el protocolo por defecto para la comunicación IoT entre dispositivo y nube en 2026, porque es ligero, usa un modelo de publicación/suscripción que escala a flotas grandes y se defiende bien en redes inestables. Funciona sobre TCP con cifrado TLS y ofrece tres niveles de calidad de servicio (0, 1 y 2) para intercambiar fiabilidad por carga adicional en cada mensaje. En la mayoría de los proyectos, lo acertado es estandarizar en MQTT y añadir otros protocolos solo donde un dispositivo o una integración concretos lo necesiten.

El medio de conectividad importa tanto como el protocolo. Wi-Fi es barato en interiores, la red móvil (LTE-M y NB-IoT) encaja con dispositivos móviles o de área amplia, LoRaWAN transporta cargas diminutas a kilómetros con una pila de botón y BLE sirve para wearables de corto alcance. Elegir pronto el medio, antes de cerrar el hardware, evita los costosos rediseños que hunden tantos pilotos.

¿Cuánto cuesta el desarrollo de software IoT en 2026?

El desarrollo de software IoT cuesta desde unos $40,000 para una app básica de monitorización hasta $200,000 o más para una plataforma empresarial en 2026, y los grandes despliegues en varios emplazamientos pueden superar con creces esa cifra. El software es solo una parte del cuadro: el número de dispositivos, el hardware, los planes de conectividad y el cumplimiento suman un coste real y recurrente que una estimación puramente de software pasa por alto.

Dos factores de coste sorprenden a los equipos que se estrenan en IoT. El primero es el coste de la nube a escala: cada dispositivo envía datos de forma continua, así que las facturas de ingesta, almacenamiento y salida crecen con la flota, que es precisamente la razón por la que la computación en el edge, al reducir el ancho de banda ~95 %, se amortiza sola. El segundo es la larga cola: las actualizaciones de firmware, los parches de seguridad, las suscripciones de conectividad y la sustitución de dispositivos son continuos, no puntuales. Construir de antemano un modelo realista de ambos es el núcleo de una buena estimación de proyectos de software para productos conectados.

¿Cuánto se tarda en crear una plataforma IoT?

Crear una plataforma IoT suele llevar de 4 a 9 meses en 2026, según el alcance, y el plazo real de principio a fin es más largo cuando se cuentan los plazos de entrega del hardware, la certificación y las pruebas de campo, porque, a diferencia del software puro, no se puede enviar una corrección de la noche a la mañana a un almacén lleno de dispositivos sellados.

• Piloto / MVP (3–4 meses): un tipo de dispositivo conectado y datos que fluyen a un panel básico, suficiente para validar la idea sobre el terreno.
• Plataforma de producción (6–9 meses): gestión de dispositivos, alertas, integraciones de terceros, un backend en la nube reforzado y seguridad de verdad.
• Empresarial / varios emplazamientos (9–12+ meses): computación en el edge, analítica predictiva, certificación regulatoria y despliegue en distintas ubicaciones.

El hardware es la carta salvaje. Los errores de firmware que se descubren una vez enviados los dispositivos son caros de corregir, la certificación (radio, seguridad, ciberseguridad) puede añadir semanas y las condiciones de campo rara vez coinciden con las del laboratorio. Reservar tiempo para un piloto real antes de la producción en serie es lo que mantiene la fecha de entrega cerca de la prevista.

El proceso de desarrollo IoT, paso a paso

Un proyecto IoT bien dirigido pasa por seis etapas, cada una con un resultado que alimenta la siguiente. Las primeras etapas pesan más que en el software convencional, porque una mala elección de hardware o de conectividad es mucho más difícil de deshacer después.

1. Descubrimiento y caso de uso. Defina qué debe detectar, decidir y hacer el producto conectado, y la métrica de negocio que mueve. Aquí se deciden el alcance, el hardware y la conectividad.
2. Selección de hardware y conectividad. Elija a la vez el microcontrolador, los sensores, el medio de conectividad y el protocolo, ya que cada uno condiciona a los demás.
3. Arquitectura y puesta en marcha de la plataforma. Monte la plataforma IoT en la nube, el registro de dispositivos, el modelo de seguridad y el pipeline de datos antes de empezar con las funciones.
4. Desarrollo de firmware y aplicación. Desarrolle en paralelo el firmware del dispositivo y las capas de nube y de aplicación, integrándolas mediante el protocolo elegido.
5. Pruebas y piloto de campo. Pruebe en el banco y después realice un piloto real con las condiciones de dispositivo que encontrará de verdad: caídas de red, límites de energía, entorno.
6. Despliegue, monitorización y actualización. Despliegue a escala con actualizaciones por aire (OTA), monitorización de la flota y un proceso de parches de seguridad integrado desde el primer día.

El proceso está deliberadamente por etapas para que las decisiones más arriesgadas y más difíciles de revertir (hardware y conectividad) se tomen y validen antes de comprometerse con el volumen. Esa disciplina es lo que separa a los productos conectados que escalan del 60–75 % de pilotos que nunca lo hacen.

Seguridad IoT y cumplimiento en 2026

La seguridad es ya un requisito legal, no un extra, y 2026 es el año en que las normas adquieren fuerza. Todo dispositivo conectado es una superficie de ataque, y los reguladores de la UE, el Reino Unido y EE. UU. han optado por hacer responsables a los fabricantes de su seguridad durante toda la vida del producto.

• Reglamento de Ciberresiliencia de la UE (CRA). A partir del 11 de septiembre de 2026, los fabricantes de productos con elementos digitales deben notificar a las autoridades de la UE las vulnerabilidades explotadas activamente: una alerta temprana en 24 horas y una notificación detallada en 72 horas. La conformidad plena con el CRA será obligatoria para los productos comercializados en el mercado de la UE a partir del 11 de diciembre de 2027, e incluye obligaciones de seguridad desde el diseño, gestión de vulnerabilidades y actualizaciones.
• Ley PSTI del Reino Unido. En vigor desde abril de 2024, prohíbe las contraseñas por defecto, exige un contacto para la divulgación de vulnerabilidades e impone un periodo mínimo declarado de actualizaciones de seguridad para los productos conectables de consumo.
• Cyber Trust Mark de EE. UU. Una etiqueta voluntaria que indica que un dispositivo IoT de consumo cumple unos criterios básicos de seguridad; cada vez es más una expectativa del comprador, aunque no sea obligatoria.
• Seguridad desde el diseño. Dé a cada dispositivo una identidad única (un ID de dispositivo más un certificado X.509), cifre todo el tráfico con TLS, firme el firmware y distribuya actualizaciones por aire (OTA) para poder parchear una flota sobre el terreno.

La consecuencia práctica es sencilla: diseñe pensando en estas obligaciones desde el primer diagrama de arquitectura. Adaptar la identidad de dispositivo, el cifrado y un mecanismo de actualización a una flota ya desplegada cuesta mucho más que incorporarlos desde el principio, la misma lección que los equipos de producto aprendieron sobre la privacidad en nuestra guía de seguridad de apps móviles y cumplimiento del RGPD.

Cómo elegir una empresa de desarrollo de software IoT

Elija una empresa de desarrollo de software IoT capaz de trabajar en las cuatro capas (firmware, conectividad, nube y aplicación), porque un partner fuerte en una sola capa trasladará discretamente a usted el difícil trabajo de integración. Los fallos del IoT rara vez provienen de un solo componente defectuoso; provienen de las juntas entre componentes de las que nadie era responsable.

Al evaluar a un partner de desarrollo de software IoT, busque productos conectados ya publicados (no solo apps), una postura clara sobre la gestión de dispositivos y las actualizaciones OTA, prácticas reales de seguridad y de preparación para el CRA, y un modelo de costes de nube que pueda defender a escala de flota. Pregunte cómo ejecuta un piloto de campo, cómo gestiona la reversión del firmware y quién es responsable de la junta entre hardware y software. Un buen partner hablará de esos riesgos antes que usted, y empezará con un piloto pequeño y honesto en lugar de con un pedido de nueve mil unidades.

Preguntas frecuentes

¿Qué hace una empresa de desarrollo de software IoT?

Una empresa de desarrollo de software IoT diseña y crea el software que hace útiles los dispositivos conectados: el firmware del dispositivo, la capa de conectividad que mueve los datos, la plataforma en la nube que los recibe y almacena, y las aplicaciones y paneles que usan las personas. Una empresa de desarrollo de software IoT de servicio completo se ocupa también de la gestión de dispositivos, las actualizaciones por aire (OTA), la seguridad y la integración con los sistemas de negocio existentes, de modo que una flota de sensores se convierta en un producto y no en un proyecto de laboratorio. Muchos equipos contratan a un partner externo para esto porque el IoT abarca competencias de sistemas embebidos, redes, nube y datos que rara vez están todas internamente.

¿Cuánto cuesta el desarrollo de software IoT en 2026?

El desarrollo de software IoT cuesta normalmente desde unos $40,000 para una app básica de monitorización hasta $200,000 o más para una plataforma empresarial en 2026, y los despliegues en varios emplazamientos con miles de dispositivos pueden superar entre $500,000 y $1.6 millones. Una app básica que lee una flota pequeña de sensores cuesta $40,000–$80,000; una plataforma de complejidad media con gestión de dispositivos, alertas y paneles, $80,000–$150,000; y un sistema empresarial con computación en el edge, analítica predictiva y actualizaciones de firmware por aire, $150,000–$200,000+. El hardware, el número de dispositivos, la conectividad y el cumplimiento son los mayores factores de coste, además del propio software.

¿Cuál es el stack tecnológico del desarrollo de software IoT?

Un stack IoT moderno tiene cuatro capas. En el dispositivo, un firmware en C o C++ (o MicroPython/Rust) se ejecuta en el microcontrolador. La capa de conectividad usa un protocolo ligero (casi siempre MQTT sobre TLS) para mover los datos por Wi-Fi, red móvil, LoRaWAN o BLE. La capa de nube es una plataforma IoT como AWS IoT Core, Azure IoT Hub o Google Cloud IoT que gestiona la ingesta, un registro de dispositivos, el almacenamiento y las reglas. La capa de aplicación es una app web o móvil, normalmente en React, Node.js o Python, con almacenamiento de series temporales y analítica. La computación en el edge se sitúa entre el dispositivo y la nube para el procesamiento de baja latencia.

¿Cuánto se tarda en crear una plataforma IoT?

Crear una plataforma IoT suele llevar de 4 a 9 meses en 2026, según el alcance. Un piloto o MVP bien acotado que conecta un tipo de dispositivo y muestra datos en un panel puede publicarse en 3–4 meses; una plataforma de producción con gestión de dispositivos, alertas e integraciones lleva 6–9 meses; y un gran sistema empresarial con varios emplazamientos, computación en el edge y requisitos estrictos de cumplimiento, 9–12 meses o más. Los plazos de entrega del hardware, la certificación y las pruebas de campo añaden tiempo de calendario que las estimaciones de software puro pasan por alto.

¿Cuál es el mejor protocolo para la comunicación de dispositivos IoT?

MQTT es el protocolo por defecto para la comunicación IoT entre dispositivo y nube en 2026 porque es ligero, usa un modelo de publicación/suscripción que escala a flotas grandes y gestiona con soltura las redes poco fiables con los niveles de calidad de servicio 0, 1 y 2. Funciona sobre TCP con cifrado TLS. CoAP es una buena alternativa para dispositivos muy limitados y de bajo consumo, HTTP/REST encaja con actualizaciones ocasionales e integraciones sencillas y AMQP sirve para mensajería empresarial en la que la fiabilidad pesa más que la huella del dispositivo. La mayoría de las flotas estandariza en MQTT y añade otros solo donde un dispositivo o una integración los necesita.

¿Qué normativas de seguridad se aplican a los dispositivos IoT en 2026?

La nueva norma más importante es el Reglamento de Ciberresiliencia de la UE (CRA): desde el 11 de septiembre de 2026, los fabricantes de productos con elementos digitales deben notificar a las autoridades de la UE las vulnerabilidades explotadas activamente (una alerta temprana en 24 horas y una notificación detallada en 72 horas), y la conformidad plena con el CRA es obligatoria para los productos comercializados en el mercado de la UE a partir del 11 de diciembre de 2027. La ley PSTI del Reino Unido está en vigor desde abril de 2024 con requisitos básicos de seguridad de los dispositivos, y EE. UU. promueve la etiqueta voluntaria Cyber Trust Mark. Todo producto conectado que se venda en estos mercados debería diseñarse desde el principio pensando en estas normas, en lugar de adaptarse después.

Última actualización: 23 de julio de 2026. Los rangos de coste y de plazo reflejan datos habituales del mercado de EE. UU. y la UE en 2026 y varían según el alcance, el hardware, la región y el número de dispositivos; las fechas regulatorias reflejan el Reglamento de Ciberresiliencia de la UE (notificación de vulnerabilidades desde el 11 de septiembre de 2026, conformidad plena desde el 11 de diciembre de 2027) y la ley PSTI del Reino Unido. Considere las cifras como rangos de planificación, no como presupuestos: pida una estimación delimitada para su proyecto concreto.