Software para cámaras, drones y edificios.

Qué cambia en este terreno

Un hotel, un edificio de oficinas o una planta industrial compra cámaras, sensores, control de accesos, climatización e iluminación, muchas veces a proveedores distintos, y a menudo contrata además vuelos de dron. Cada uno de esos sistemas llega con su propia consola, y esa consola está pensada para gestionar sus dispositivos, no para llevar tu operación.

Lo que suele faltar es siempre lo mismo: una pantalla donde el evento cae en la cola correcta, un móvil que suena en el bolsillo de quien está de turno, un registro de qué vio cada persona y cuándo, y un aviso cuando un dispositivo deja de dar señal. Si las consolas que ya tienes cubren todos tus sistemas y a todas las personas que tienen que actuar, esta página te sobra.

Antes de que sigas leyendo, te decimos dónde se acaba la prueba. Esta capacidad es nueva. No hemos entregado ningún proyecto de cámaras, drones ni automatización de edificios, y la publicamos igual que publicamos los agentes de voz: una capacidad que declaramos, todavía sin ningún caso detrás. Lo que sí tenemos son las piezas de las que se compone este trabajo, cada una ya en producción en otros proyectos: conectores que leen de un sistema de terceros con una periodicidad fija, un panel de operaciones con una cola por departamento y la alarma sonando en el móvil de quien está de turno, captura de foto dentro de un proceso real de trabajo de campo, en una aplicación web mobile first, apps nativas publicadas en las dos tiendas en un proyecto distinto, roles que se comprueban en la base de datos y un registro de auditoría inmutable escrito por un trigger de base de datos. Esas piezas no se han montado nunca juntas en un proyecto de cámaras, drones ni edificios, y vigilar un dispositivo no está entre ellas. Si lo que necesitas es un proveedor con una cartera de instalaciones hechas, no somos nosotros, y preferimos escribirlo aquí antes que decirlo en la reunión de arranque.

Qué construimos

El panel donde cae el evento

Un único sitio para lo que pasa en el edificio, con una cola por departamento, un responsable por cada cosa y un estado de cierre. En la plataforma de operaciones que llevamos para un resort de convenciones del Caribe, cada departamento, seguridad incluida, ve su propia cola, se hace cargo y cierra con un estado, con la alarma sonando en los móviles de quien está de turno. Las cifras publicadas en la página de ese proyecto son peticiones de huéspedes, no eventos de dispositivos: unas 2.500 en cuatro meses, con una mediana de primera respuesta de 3 minutos y una mediana de resolución de 16 minutos. Las citamos como prueba de que la cola, el turno y la alarma funcionan, no como tráfico de sensores.

El conector con el sistema que ya tienes

Lo leemos con una periodicidad fija y lo escribimos en tu propia base de datos. Nuestro conector de Opera Cloud, conectado al PMS de un hotel, lleva meses en producción y sincroniza cada cinco minutos. En otro proyecto la sincronización va cada treinta minutos. Tareas programadas y webhooks con claves de idempotencia, reintentos y protección contra reenvíos, para que una llamada repetida se reconozca como repetida en lugar de escribirse dos veces, y un registro auditable de cada sincronización: qué se ejecutó, qué cambió, qué falló. Dirigir ese mismo mecanismo a una cámara, a una controladora o a un sistema del edificio es la parte que no hemos hecho, y el Discovery Sprint es donde averiguamos qué expone el tuyo.

El aviso cuando una fuente se queda callada

Lo que existe hoy es el registro auditable de cada sincronización, qué se ejecutó, qué cambió y qué falló, y un motor de tareas que manda a cada departamento su correo cada día hábil. El aviso en sí, que salte cuando una fuente deja de mandar, cuando caduca una credencial o cuando el proveedor cambia un endpoint, y que le llegue a quien está de turno, es algo que construiríamos aquí, no algo que tengamos funcionando. Tampoco hemos vigilado nunca el latido de una cámara, de un sensor ni de una controladora, así que dirigirlo a dispositivos sería la primera vez. Creemos que funciona igual con dispositivos, porque un aparato que ha dejado de dar señal es una fuente que ha dejado de mandar, pero eso es nuestro criterio de ingeniería y no algo que hayamos puesto en marcha. Una cámara que lleva tres días sin dar señal no te lo va a contar ella, y el día que necesitas la grabación es el peor día para enterarte.

La app que tu equipo lleva encima

La prueba del flujo de campo es web. En el sistema de reformas que construimos para una constructora, una aplicación web mobile first, la recepción de material se comprueba línea a línea y un descuadre genera automáticamente una incidencia con foto. La capacidad nativa también es real, pero viene de otro proyecto y sin ese flujo: para un cliente de festivales, en la temporada 2026, una app de Android publicada en 177 países y una app de iOS relanzada, con el push integrado en la capa nativa. Eso es trabajo a nivel de dispositivo, no una web envuelta en una app. Juntar las dos cosas, una app nativa con la cámara como una superficie nativa más, construida por nosotros para que un hallazgo se convierta en una incidencia con foto en el momento en que ocurre, es lo que construiríamos aquí, y no es algo que hayamos entregado ya como una sola pieza.

Quién puede ver qué

Roles que se comprueban en la base de datos y no en la interfaz, row level security activado y forzado, un registro de auditoría inmutable escrito por un trigger de base de datos con un visor de auditoría solo para administradores, y acceso con la cuenta de Microsoft (Entra ID) cuando la organización va sobre Microsoft 365. Dos clientes distintos enseñan los dos extremos: un portal corporativo de empleados sincronizado desde Microsoft Graph, cuyo diagnóstico de agosto de 2026 mostraba 39 tablas con row level security, y un sistema de gestión para una constructora sobre 23 tablas, con row level security forzado en las 23. Aplicado a este terreno, es lo que te permite decir que ese contratista ve solo la tercera planta, que el turno de noche ve solo su cola, y que cada cambio dejó rastro.

Con qué nos integramos

El hardware, la instalación y las licencias del fabricante son tuyos, comprados a quien tú elijas y a tu nombre, y nos parece el orden correcto. No nos llevamos margen de distribución de ningún fabricante, así que en tu instalación no prescribimos ningún equipo porque nos convenga a nosotros. La lógica vive en tu propio proyecto de Supabase, el repositorio queda a tu nombre, y si dentro de tres años cambias de marca de cámara, la capa de encima no hay que volver a comprarla.

No publicamos una lista de protocolos soportados ni prometemos integrarnos con cualquier cosa. Lo que hacemos es leer la documentación de los sistemas que tienes, probarlos sobre el equipamiento real durante el Discovery Sprint y decirte por escrito qué se puede leer, qué se puede escribir y qué no. Enumerar siglas que no hemos manejado en producción sería una invitación a llevarse un disgusto a los tres meses de proyecto.

Si tu equipamiento solo habla con su propia consola cerrada, te lo decimos antes de firmar, no después.

Qué no hacemos

• Fabricar, diseñar, ensamblar ni vender hardware. Ni cámaras, ni drones, ni sensores, ni gateways, ni controladoras, ni firmware propio.
• Instalar, cablear ni poner en marcha nada en sitio, ni mantenimiento en campo. De eso se encarga tu instalador o tu integrador.
• Operar drones. Ni inscripción como operador, ni pilotos, ni seguro de vuelo, ni horas de vuelo.
• Analítica de vídeo ni biometría: ni detección de personas, ni conteo, ni lectura de matrículas, ni reconocimiento facial.
• Vigilancia 24/7, sala de control ni operador de guardia. Nuestra cuota de Care son horas de mantenimiento, no un puesto atendido.
• La cámara en continuo ni sensores en segundo plano dentro de una app. Nuestra propia página de apps dice que ahí es donde compensa el nativo puro, y no vamos a contradecirla para ganar un proyecto.
• Certificaciones y homologaciones. No tenemos ninguna, y no vamos a insinuar lo contrario.

Cómo empieza un proyecto

Con un Discovery Sprint: qué equipamiento tienes, qué expone cada sistema, probado sobre el sistema real y no sobre su folleto, qué eventos importan, quién tiene que verlos y qué debe quedar registrado. Termina con un alcance por escrito, y a veces la conclusión es que tu cuello de botella no es el software.

La primera fase de construcción va a precio cerrado, en un presupuesto privado al terminar el sprint, y, una vez está viva, pasa a una cuota mensual de Care. No hay precio por cámara ni por dispositivo, porque no vendemos dispositivos.