SafeDrive
Años tomando un problema de seguridad vial genuinamente ambiguo y llevándolo por varias hipótesis de producto, un sistema completo, pruebas de campo y un pivot.
Los números provienen de material verificado del proyecto (registros de incubación y VIN).
Antes de ser una startup, fue una pregunta que llegó desde el mundo real.
SafeDrive empezó en la Universidad de Montevideo, dentro de Laboratorio TIC V. La oportunidad surgió a partir de un problema planteado alrededor de UNASEV —la Unidad Nacional de Seguridad Vial, el organismo del Estado uruguayo a cargo de la política nacional de seguridad vial—: explorar si tecnología accesible podía detectar síntomas de sueño y distracciones al volante.
En lugar de recibir un backlog, recibimos una pregunta abierta. Eso cambió completamente la naturaleza del trabajo.
UNASEV sugirió mirar especialmente el contexto de camioneros y flotas, donde las jornadas extensas y la operación real volvían el problema especialmente relevante. No fue un contrato: fue un problema, un interés y una colaboración que dieron origen al primer prototipo estudiantil.
SafeDrive no empezó como startup: empezó como materias de la carrera. Laboratorio TIC V, después TIC VI, después el proyecto final. Cada etapa era una entrega con nota, y cada entrega dejaba el problema un poco más resuelto que la anterior. Lo que cambió con el tiempo no fue el problema: fue cuánto del mundo real le habíamos dejado entrar.
Cada etapa hizo una pregunta más difícil que la anterior.
¿Se puede detectar?
Raspberry Pi + cámara + GPS y un visualizador web simple.
¿Esto puede ser un sistema?
React + Django + AWS: recorridos, perfiles de conductor, analítica de flota y reportes.
¿Funciona en empresas reales?
Pilotos multi-vehículo, diseño industrial y validación comercial.
¿Podemos dar el valor con menos hardware?
Un POC mobile-first apoyado en el teléfono que la gente ya lleva.
Antes del mobile, hubo hardware dentro del vehículo.
SafeDrive arrancó explorando un sistema dedicado: una Raspberry Pi 4B, una cámara y GPS, con procesamiento cerca del auto y experimentación de visión en Python. Convertir una hipótesis de computer vision en algo que pudiera existir físicamente dentro de un vehículo.
El hardware vuelve tangible un prototipo, pero también introduce restricciones que hay que tratar como parte del producto: instalación, alimentación, costo, mantenimiento, conectividad y escalabilidad. Ninguna desaparece con un buen algoritmo.
Hacer que la detección fuera lo bastante útil para seguir.
La pregunta que importaba no era “¿una cámara puede ver una cara?”. Era si tecnología accesible podía identificar señales útiles del estado del conductor —somnolencia, fatiga, distracción— mientras una persona realmente maneja.
Los experimentos tempranos de detección usaron landmarks faciales y señales como el estado de los ojos, el bostezo y la posición de la cabeza. Trabajo práctico alrededor de computer vision, no un modelo de ML de última generación.
Esto demuestra experiencia práctica trabajando alrededor de computer vision y análisis facial. No justifica el título de “experto en computer vision”.
Lo medimos: 20 pruebas por señal, de día y de noche. El bostezo era la señal más confiable (85%); los ojos cerrados, la más difícil (65-70%). No es validación científica ni una métrica de producción: es lo que sabíamos, con el tamaño de muestra que teníamos.
El modelo nunca fue todo el producto.
Mucho antes de hablar de agentes o IA aplicada, SafeDrive ya me había enseñado la misma lección: una capacidad técnica aislada no crea un sistema útil. El PFC hizo evolucionar el prototipo hacia un sistema de punta a punta.
Simplificada; no representa cada versión posterior.
Detectar un evento era solo una parte del producto.
Los gestores de flota necesitaban entender qué pasó a lo largo de un viaje, de un conductor y, eventualmente, de una flota. El objetivo dejó de ser únicamente “detectar sueño”: empezamos a convertir datos de conducción en información que alguien pudiera usar.
La primera prueba en camión también rompió cosas.
Y eso era parte del objetivo.
En una de las primeras pruebas del sistema completo aparecieron problemas en el flujo de subida de datos al servidor. Volvimos al código, debuggeamos el flujo principal, corregimos los problemas y repetimos las pruebas en otro vehículo, validando después la recolección de eventos y el comportamiento del GPS.
El valor de salir a campo no fue demostrar que todo funcionaba. Fue descubrir qué todavía no funcionaba. No reclamo validación científica formal.
El proyecto también tenía que poder explicarse fuera de Ingeniería.
A medida que el proyecto avanzó, dejamos de explicarlo solamente frente a docentes o compañeros. Fuimos invitados a presentar SafeDrive en Presidencia durante la XIV Semana Nacional de la Seguridad Vial, organizada por UNASEV, ante representantes vinculados a UNASEV, BSE y Caminera.
Para mí, esa parte también era ingeniería: poder explicar qué estábamos intentando hacer, qué funcionaba, qué no y por qué podía importar.
Construirlo nos hizo preguntar si había un negocio adentro.
Construirlo nos obligó a preguntarnos si había un negocio adentro. La respuesta no salió de nosotros: salió de hablar con gente de flotas, de seguros y de empresas que ya convivían con el problema. Ese contacto movió el foco hacia el análisis de flota, el costo y la utilidad real del producto.
Initium — nuestra IPE y puente producto/negocio
Initium, el centro de emprendimientos de la Universidad de Montevideo, fue nuestra IPE —Institución Patrocinadora de Emprendimientos— y nos acompañó durante todo el proceso: no solo la exploración comercial inicial, sino como la institución que respaldó formalmente el proyecto frente a los programas de financiamiento. La incubadora Ingenio también nos dio apoyo en el camino.
Incubaelectro — de proyecto a startup incubada
El equipo fue seleccionado para Incubaelectro, que aportó financiamiento y acceso a infraestructura y distintos tipos de apoyo durante la incubación.
UYU 150.000ANDE VIN — ¿sobrevive a una flota real?
La etapa VIN tuvo un objetivo claro: dejar de validar SafeDrive solo entre nosotros y llevarlo a organizaciones, vehículos y conductores reales.
UYU 222.000Del laboratorio a flotas reales.
Una etapa posterior del proyecto tuvo un objetivo muy concreto: dejar de validar SafeDrive solamente entre nosotros y llevarlo a organizaciones, vehículos y conductores reales.
“No marcamos la validación comercial como completa solo porque a las empresas les gustara la idea.”
La validación involucró organizaciones de áreas distintas, para probar contra la realidad y no contra un único vehículo amigable de demo.
Instalaciones en distintas empresas y vehículos.
Instalación, dispositivos dentro de distintos vehículos, cables, conductores y equipo trabajando.
Landmarks faciales sobre conductores de camión, en vivo.
Durante los pilotos accedíamos de forma remota a la Raspberry Pi de cada vehículo. Veíamos el frame procesado con los landmarks faciales sobre conductores reales y los registros de detección corriendo en el momento.
De la cinta al diseño impreso en 3D.
Instalar el producto con las manos nos enseñó que la carcasa era parte del problema. Pasamos de una cámara IR sujeta con cinta a un diseño propio: lo modelamos en 3D, lo imprimimos y lo montamos sobre el parabrisas.
La realidad empezó a escribir requerimientos que no habíamos imaginado.
Alimentación
Interacción del conductor
Diseño físico
Usabilidad
Una prueba de campo es product discovery con consecuencias.
Durante la validación también consideramos la normativa de visibilidad en camiones para que el dispositivo no se volviera una obstrucción física: pensamiento de sistema alrededor del entorno real, no experticia regulatoria.
La mejor solución técnica no era necesariamente el mejor producto.
Después de años intentando mejorar el dispositivo —hardware, PFC, pruebas de campo, pilotos y problemas físicos reales— empezamos a hacer una pregunta distinta: ¿qué parte del valor realmente requería hardware dedicado?
“¿Cómo hacemos mejor este dispositivo?” pasó a ser: “¿lo necesitamos para entregar valor?”
Dispositivo dedicado en el vehículo
El valor desde el teléfono
Ninguna de las dos versiones es objetivamente superior. Lo que cambió fue la hipótesis de producto, no solo el código. Con todo lo aprendido antes, el pivot se sintió inevitable, no un eslogan.
El pivot se implementó, no solo se discutió.
Avanzamos hasta una implementación mobile funcional. Un POC en Android orientado a detección de somnolencia llegó a un estado funcional avanzado, apoyado en React y Expo / React Native.
No fue un lanzamiento comercial: quedaba trabajo de testing, refinamiento y release. Pero el pivot dejó de ser una idea de slide y pasó a existir como algo que se podía abrir y usar.
Mi rol también evolucionó.
Éramos cuatro cofundadores, todos software engineers. El material formal temprano describe mi trabajo hands-on en frontend, web y Raspberry Pi. A medida que SafeDrive se volvió un proyecto emprendedor, mi aporte se amplió a producto, conversaciones comerciales, fondos, programas, presentaciones y la relación con la Universidad y las instituciones. Buena parte del trabajo físico también fue mío: armar el equipo e instalarlo en los vehículos, debajo del volante y con la linterna en la boca. Marcelo y Matías también estuvieron en esa parte. No es un detalle de color: instalar el producto con tus manos es la forma más rápida que conozco de entender por qué la instalación es un problema de producto y no un trámite.
Ingeniero
Trabajo técnico hands-on.
Product builder
¿Qué debería hacer realmente el sistema?
Cofundador
Que el proyecto existiera fuera del aula.
Interfaz producto/externa
Conectar equipo ↔ universidad ↔ programas ↔ instituciones ↔ empresas.
“Buena parte del recorrido fui una de las personas que conectaba al equipo con quienes podían ayudar al proyecto a avanzar.”
Ningún proyecto así se sostiene con una sola persona.
SafeDrive cambió de forma y de equipo a lo largo de sus etapas, con un origen académico y un grupo más amplio de estudiantes. La etapa emprendedora terminó consolidándose alrededor de cuatro cofundadores. Yo tomé especialmente el lado comercial, la relación con los fondos y el contacto hacia afuera; los demás sostuvieron la tecnología y la ejecución, y en las instalaciones estuvimos varios con las manos adentro del auto.
Cada actor estuvo por una razón distinta.
No todos los nombres representan la misma relación. Los separo para no sobre-reclamar: origen y colaboración, incubación y apoyo, y financiamiento de validación.
De dónde salió el problema y el primer contexto.
La institución que respaldó formalmente el proyecto ante los programas.
Infraestructura y acompañamiento durante la incubación.
ANDE no solo aportó financiamiento: también nos dio apoyo y asesoría durante la etapa de validación.
No se terminaron las ideas.
Faltaban las condiciones para hacer bien la siguiente etapa.
Con el tiempo, el equipo empezó a combinar SafeDrive con carreras profesionales cada vez más exigentes. Habíamos avanzado técnicamente y teníamos una dirección mobile, pero llevarla a una etapa seria requería dedicación y recursos que el proyecto no tenía asegurados. Preferimos pausarlo antes que mantenerlo artificialmente “activo”. No se detuvo porque el prototipo fallara ni porque el problema dejara de ser interesante.
Pausado. Por ahora…
El problema sigue siendo difícil. Las herramientas cambiaron.
Hoy podría probar varias de las hipótesis de SafeDrive con un costo y una velocidad de experimentación muy distintos, gracias a avances en visión, mobile e ingeniería asistida por IA. Eso cambia el costo de aprender.
No elimina la responsabilidad de validar una tecnología ligada a la seguridad: confiabilidad, falsos positivos, privacidad y responsabilidad siguen importando. La oportunidad interesante no es solo “mejor IA”: es que un equipo chico puede probar más hipótesis con mucho menos overhead de ejecución.
Cómo pienso la IA aplicada →SafeDrive cambió cómo pienso el producto.
Un prototipo prueba una hipótesis. Un producto tiene que sobrevivir a la gente, al negocio y a la realidad.
Antes de “¿se puede detectar?” están las preguntas que de verdad definen un producto: quién lo usa, quién paga y qué problema resuelve. La detección fue el punto de partida técnico, no la prioridad.
La prueba de campo cambia cómo se ve el problema.
La realidad expone restricciones que ninguna pizarra muestra, y le empieza a poner precio a la complejidad.
Más tecnología no es automáticamente mejor producto.
El pivot a mobile lo demuestra: a veces el mejor movimiento es sacar hardware, no agregar.
La disposición a pagar es distinta de la factibilidad técnica.
Que algo funcione no significa que alguien lo pague. Es la distancia más cara de recorrer, y la única que no se puede acortar programando mejor.
Qué me exigió SafeDrive.
¿Tenés un problema difícil y todavía no sabés qué producto hay adentro?
SafeDrive empezó exactamente ahí: una pregunta abierta, mucha incertidumbre y ninguna especificación perfecta. Es una de las etapas del producto que más disfruto: entender, probar, reducir incertidumbre y decidir qué vale la pena construir.