Agencia de desarrollo de apps IoT en España. Firmware embebido en ESP32, comunicación BLE/Wi-Fi, app Flutter y backend cloud en Go — construidos por un solo equipo, del prototipo a producto listo para fabricar.
Respuesta directa
Dribba desarrolla apps conectadas a hardware con firmware ESP32 (BLE, Wi-Fi y actualización OTA), app móvil en Flutter y backend en Go sobre Cloud Run. Al hacer firmware, app y nube con el mismo equipo, el protocolo de comunicación es un contrato interno y no una frontera entre proveedores. Del PoC a la industrialización.
3 capas
Firmware · App · Backend
BLE + Wi-Fi
Conectividad + OTA
1 equipo
Un solo interlocutor
¿Es tu caso?
Si tu producto tiene hardware, la app no es un proyecto aparte: es una capa más del mismo sistema.
Un dispositivo con ESP32, un wearable, un sensor o una máquina que necesita una app que lo controle, lo configure y lea sus datos. Buscas un equipo que domine firmware y app a la vez.
Emparejamiento, envío de comandos, lectura de características GATT, actualización de firmware OTA por BLE. Necesitas que la comunicación app ↔ dispositivo sea fiable y con buena batería.
Una startup de hardware o una marca que lanza un dispositivo conectado y necesita la app, el firmware y el backend cloud construidos de forma coherente por un solo interlocutor.
El proveedor de firmware y el de la app se echan la culpa cuando algo falla. Unificamos ambos lados para que el protocolo de comunicación sea un contrato, no una fuente de bugs.
El dispositivo publica telemetría, recibe configuración remota o se actualiza por OTA. Diseñamos el firmware ESP32 y el backend para que el flujo de datos sea seguro y escalable.
Un PoC con ESP32 funciona en tu mesa pero no está listo para producción. Lo llevamos a firmware robusto, app publicable y backend preparado para miles de dispositivos.
Qué construimos
Un dispositivo IoT solo funciona si las tres capas encajan. Por eso las construimos juntas.
Guía
El ESP32 se ha convertido en el microcontrolador de referencia para producto conectado: barato, con Wi-Fi y Bluetooth integrados, potente y con un ecosistema maduro. Pero un dispositivo con ESP32 no es un producto hasta que tiene una app que lo controle y un backend que recoja sus datos. Y ahí es donde la mayoría de proyectos de hardware se atascan: el firmware lo hace un proveedor, la app otro, el backend un tercero, y el protocolo de comunicación entre ellos se convierte en una tierra de nadie donde nadie asume los bugs.
Dribba resuelve eso construyendo las tres capas con el mismo equipo. Desarrollamos el firmware embebido en ESP32 —con ESP-IDF o Arduino según el caso— incluyendo conectividad BLE con perfiles GATT personalizados, Wi-Fi, y actualización OTA para poder actualizar los dispositivos sin recogerlos físicamente. Desarrollamos la app móvil en Flutter que empareja con el dispositivo, le envía comandos y lee sus datos, resolviendo las trampas conocidas del BLE: reconexión, negociación de MTU para transferencias grandes, colas de comandos y una máquina de estados de conexión clara. Y desarrollamos el backend en Go sobre Cloud Run que ingiere la telemetría por MQTT o HTTP, gestiona la flota de dispositivos y almacena las series de datos.
La diferencia de tener un solo equipo no es organizativa, es técnica. El protocolo de comunicación entre el firmware y la app deja de ser una frontera entre contratos y pasa a ser un contrato interno que evoluciona de forma coordinada. Cuando algo falla en producción —un dispositivo que se desconecta, un dato que no llega— la depuración es conjunta: no hay que enfrentar a dos proveedores para saber de qué lado está el problema. Y cuando el dispositivo genera datos sin cobertura, la app los guarda en local con una arquitectura offline-first y los sincroniza cuando vuelve la conexión, sin perder nada.
Trabajamos tanto desde cero como industrializando prototipos. Muchas startups de hardware llegan con un PoC sobre ESP32 que funciona en el laboratorio pero está lejos de producción: le falta robustez frente a cortes, gestión de energía, seguridad, OTA, una app publicable en las stores y un backend que aguante miles de dispositivos. Ese salto del prototipo al producto es exactamente donde aportamos, con oficinas en Barcelona y Andorra y clientes de toda España y Europa.
Preguntas frecuentes
Sí. Es precisamente nuestra diferencia: desarrollamos el firmware embebido sobre ESP32 (con ESP-IDF o Arduino), la app móvil en Flutter que lo controla y el backend cloud que recibe sus datos, todo con el mismo equipo. Esto elimina el problema clásico de tener un proveedor de firmware y otro de app que se echan la culpa cuando la comunicación falla: el protocolo entre dispositivo y app es un contrato interno que controlamos de punta a punta.
BLE (Bluetooth Low Energy) con perfiles GATT personalizados para comunicación app ↔ dispositivo de bajo consumo, y Wi-Fi para conexión directa a la nube. Sobre Wi-Fi implementamos MQTT o HTTP para telemetría y configuración remota, y actualización OTA del firmware. Elegimos la combinación según el caso: BLE cuando el dispositivo se controla desde el móvil, Wi-Fi cuando publica datos a la nube de forma autónoma, o ambos.
Sí. Implementamos actualización OTA (over-the-air) para que el firmware de los dispositivos se pueda actualizar sin recogerlos físicamente: desde la app por BLE cuando el dispositivo está cerca del usuario, o desde la nube por Wi-Fi para una flota entera. Esto es imprescindible en cualquier producto de hardware conectado que vaya a estar años en el mercado.
Sí, es uno de nuestros casos más habituales. Un PoC que funciona sobre la mesa está lejos de un producto industrializable: falta robustez del firmware frente a cortes y errores, gestión de energía, seguridad, actualización OTA, una app publicable en las stores y un backend que aguante miles de dispositivos. Auditamos el prototipo, definimos qué falta para producción y lo construimos de forma coherente en firmware, app y nube.
La comunicación BLE tiene trampas conocidas: pérdidas de conexión, límites de tamaño de paquete (MTU), timeouts, diferencias entre iOS y Android. Las resolvemos con reconexión automática, negociación de MTU para transferencias grandes, colas de comandos que reintentan hasta confirmarse y una máquina de estados de conexión clara que la app refleja al usuario. Combinado con un modo offline-first, los datos del dispositivo nunca se pierden aunque la conexión se caiga a mitad.
Dispositivos de consumo conectados (wearables, electrodomésticos inteligentes, gadgets), producto industrial y field service (sensores, maquinaria, monitorización), salud y bienestar (dispositivos médicos y de medición), energía y movilidad (puntos de carga OCPP, medidores), y startups de hardware que lanzan su primer producto conectado. Si tienes un dispositivo con ESP32 que necesita una app, encajamos.
Sí. Tenemos oficinas en Barcelona y Andorra, y trabajamos con clientes de toda España y Europa en remoto y presencial. Para proyectos de hardware, la coordinación firmware-app-backend funciona igual de bien en distribuido: lo que importa es que un solo equipo controle las tres capas, no dónde esté físicamente.
Depende de la complejidad del dispositivo, del protocolo de comunicación y de si partimos de un prototipo o de cero. Un proyecto de hardware conectado suma tres frentes —firmware, app y backend— por lo que el alcance es mayor que una app estándar. En la primera sesión revisamos tu dispositivo o prototipo y te damos un rango cerrado con hitos claros.
“Tráenos tu dispositivo o tu prototipo y te decimos qué necesita para ser un producto.”
Revisamos el hardware, el firmware y la app, y definimos el camino a producción. Primera sesión sin coste.