Para comparar presupuestos de desarrollo de aplicaciones Bluetooth, entrega a cada proveedor los mismos detalles del dispositivo y el firmware, el flujo de conexión, la lista de teléfonos y sistemas operativos de destino, y las pruebas de aceptación. Una propuesta que cubre un dispositivo durante una sesión en primer plano no es directamente comparable con otra que también incluye la recuperación de la conexión, el uso en segundo plano y varias versiones de plataforma.
Documenta el dispositivo, el protocolo y el firmware
Empieza con el modelo exacto del dispositivo y la revisión del hardware. Indica si utiliza Bluetooth de baja energía (BLE), Bluetooth Classic u otro perfil especificado, y comparte la documentación del protocolo o de integración. Para BLE, incluye los UUID pertinentes de servicios y características, el comportamiento de lectura, escritura y notificaciones, y los requisitos de seguridad o vinculación. Si utilizas un SDK del proveedor, proporciona su versión, las plataformas compatibles, las condiciones de licencia y las instrucciones de configuración.
Incluye las versiones de firmware contempladas y explica cómo se identifican o actualizan. Adjunta ejemplos de cargas útiles, definiciones de comandos, códigos de error y cualquier limitación conocida del dispositivo. Si la documentación está incompleta, indica qué se desconoce en vez de dejar que los proveedores partan de supuestos diferentes. Pídeles que detallen por separado cualquier cambio necesario en el hardware o el firmware respecto al trabajo de la aplicación.
Describe los flujos de conexión y datos
Describe el recorrido del usuario desde el primer inicio hasta el funcionamiento correcto: detectar un dispositivo, seleccionarlo, emparejarlo o vincularlo, conectarlo y llegar a un estado listo. Después, enumera cada acción de la aplicación y la respuesta del dispositivo, incluidos los datos que se leen, escriben o envían mediante notificaciones. Una lista de pantallas por sí sola no define el comportamiento de Bluetooth.
Especifica qué debe ocurrir si el usuario rechaza un permiso, selecciona el dispositivo equivocado, deja el Bluetooth desactivado, se aleja del alcance o cierra y vuelve a abrir la aplicación. Indica qué funciones deben operar en primer o segundo plano, si la aplicación debe conservar la selección del dispositivo y qué estado o instrucción de recuperación debería mostrarse al usuario. Pide a los proveedores que identifiquen los supuestos sobre el funcionamiento en segundo plano para cada plataforma.
| Requisito que se debe proporcionar | Evidencia o detalle que se debe adjuntar | Cómo verificarlo en la propuesta |
|---|---|---|
| Dispositivo y protocolo | Modelo, revisión del hardware, documentación del protocolo, versiones de firmware, detalles del SDK | Confirma que se enumeren las combinaciones exactas de dispositivos y firmware compatibles |
| Emparejamiento y datos | Diagrama del flujo, ejemplos de comandos y respuestas, comportamiento de seguridad y vinculación | Comprueba que cada acción de la aplicación tenga una respuesta esperada del dispositivo o un estado de error |
| Alcance de las plataformas | Modelos de teléfono y versiones del sistema operativo necesarios para el lanzamiento | Solicita una lista de las combinaciones incluidas, excluidas y probadas físicamente |
| Comportamiento de recuperación | Resultado esperado ante una desconexión, pérdida de vinculación, reinicio de la aplicación o sustitución del dispositivo | Asocia cada caso con un criterio de aprobación definido y evidencia de prueba |
| Entrega | Código fuente, instrucciones de compilación, registros de pruebas y documentos de integración requeridos | Confirma que la propuesta identifique cada entregable y a su responsable |
Acuerda los teléfonos y sistemas operativos
Entrega a los proveedores la lista de plataformas de destino, incluidos los modelos de teléfono y las versiones del sistema operativo que usarán tus clientes o tu personal. Incluye compatibilidad con tabletas solo si es necesaria. Indica si la aplicación será solo para Android, solo para iOS o si se necesita para ambos; no des por sentado que una base de código compartida implica que el comportamiento de Bluetooth será idéntico en todas las plataformas.
Pide al proveedor que indique si la capa de Bluetooth será nativa, compartida o mixta, y que explique cómo probará la opción elegida con tu dispositivo. El desarrollo de aplicaciones para Android y el desarrollo de aplicaciones para iOS son opciones pertinentes si estás definiendo el alcance de una sola plataforma a la vez. Para un producto conectado que requiera trabajo específico para cada plataforma en el dispositivo, el desarrollo de aplicaciones nativas incluye las integraciones con dispositivos y las pruebas entre sus áreas de alcance.
Define las pruebas de desconexión y pérdida de vinculación
Trata la recuperación de la conexión como un área de pruebas de aceptación definida, no como una expectativa informal. Solicita casos de prueba que cubran el primer emparejamiento, una desconexión normal, la pérdida de alimentación del dispositivo, la desactivación y posterior reactivación del Bluetooth del teléfono, el reinicio de la aplicación y la eliminación o pérdida de la vinculación. Para cada caso, especifica el estado que verá el usuario, si se espera una reconexión automática y qué acción debe realizar el usuario si la recuperación no se produce. Define el tiempo aceptable para cada resultado como requisito del proyecto, en lugar de dar por sentado un valor.
Una nota sobre cambios de comportamiento de Android 17, fechada el 1 de octubre de 2026, describe el reemparejamiento autónomo por Bluetooth tras la pérdida de vinculación y recomienda que los equipos de la aplicación y del hardware verifiquen las transiciones de vinculación y simulen su pérdida. Consulta la documentación actual de Android y confirma si se aplica a tus versiones de destino antes de adoptarla como requisito de aceptación.
Solicita evidencia de pruebas que identifique el dispositivo y el firmware, el teléfono y la versión del sistema operativo, los pasos realizados, el resultado esperado, el resultado real y cualquier limitación conocida. Pregunta cuáles de las pruebas se ejecutaron en dispositivos físicos y cuáles se simularon. Si ya existe una aplicación, incluye en los materiales informativos el acceso al repositorio o a la compilación, los problemas conocidos actuales y los resultados de pruebas previas con el dispositivo.
Compara el alcance del presupuesto y la entrega
Compara las propuestas línea por línea. Comprueba que todas cubran las mismas variantes del dispositivo, los flujos de conexión y recuperación, las combinaciones de plataformas, los estados de la interfaz, el trabajo de backend si se necesita y los casos de prueba. Pide a cada proveedor que enumere las exclusiones, las dependencias de los equipos del dispositivo o del firmware, los supuestos sobre el acceso al SDK y cualquier elemento para el que tu equipo deba proporcionar hardware o credenciales.
Deja claro qué se considera aceptación, cómo se registrarán los defectos del dispositivo que queden sin resolver y qué código fuente, instrucciones de compilación, registros de pruebas y documentos técnicos se entregarán. Si se requieren el envío a la tienda de aplicaciones, servicios de backend, analítica o mantenimiento continuo, enuméralos explícitamente en lugar de tratarlos como incluidos por defecto.
Preguntas frecuentes
¿Debería elegir un desarrollo nativo o multiplataforma para una aplicación Bluetooth?
Toma la decisión después de documentar el protocolo del dispositivo, el comportamiento requerido en segundo plano y la matriz de plataformas de destino. Pide a los proveedores que expliquen cómo probarán la implementación propuesta en tu dispositivo real para cada plataforma y, después, compara el alcance y la evidencia en vez de elegir únicamente por el nombre del framework.
¿Qué pasa si el firmware del dispositivo sigue cambiando?
Identifica las versiones de firmware disponibles ahora, las previstas para el lanzamiento y quién controla los cambios de firmware. Pide al proveedor que indique qué versión presupone el presupuesto y cómo afectarán al alcance los cambios en los comandos, la seguridad o el comportamiento de conexión.
¿Cuántos dispositivos debería proporcionar para las pruebas?
Pregunta al proveedor cuántas unidades físicas se necesitan para el plan de pruebas acordado y qué revisiones de hardware o versiones de firmware deben estar representadas. Indica cuántas unidades puedes poner a disposición y señala cualquier limitación antes de comparar presupuestos.
Para preparar un documento de solicitud de propuestas, comparte las especificaciones del dispositivo, la documentación del protocolo y del firmware, la cantidad de unidades de prueba, el destino de cualquier hardware que tengas previsto enviar, los teléfonos y versiones del sistema operativo de destino, y los detalles de la aplicación, la API o el repositorio existentes. Los servicios de aplicaciones de Manboo Studio pueden definirse según esos requisitos; comenta tus requisitos para definir el alcance del proyecto.