SafeDrive
Years taking a genuinely ambiguous road-safety problem through several product hypotheses, a complete system, field testing and a pivot.
Numbers come from verified project material (incubation and VIN records).
Before it was a startup, it was a question that came from the real world.
SafeDrive started at Universidad de Montevideo, inside Laboratorio TIC V. The opportunity emerged from a problem framed around UNASEV —Uruguay’s National Road Safety Unit, the state agency in charge of national road-safety policy—: to explore whether accessible technology could detect signs of sleep and distraction while driving.
Instead of receiving a backlog, we received an open question. That completely changed the nature of the work.
UNASEV suggested looking especially at the trucking and fleet context, where long shifts and real operation made the problem particularly relevant. It wasn’t a contract: it was a problem, an interest and a collaboration that seeded the first student prototype.
SafeDrive didn’t start as a startup: it started as coursework. Laboratorio TIC V, then TIC VI, then the final project. Each stage was a graded deliverable, and each one left the problem a bit more solved than the last. What changed over time wasn’t the problem: it was how much of the real world we had let into it.
Each stage asked a harder question than the last.
Can we detect it?
Raspberry Pi + camera + GPS and a simple web viewer.
Can this become a system?
React + Django + AWS: routes, driver profiles, fleet analytics and reports.
Can it work in real companies?
Multi-vehicle pilots, industrial design and commercial validation.
Can we deliver the value with less hardware?
A mobile-first POC leaning on the phone people already carry.
Before mobile, there was in-vehicle hardware.
SafeDrive started by exploring a dedicated system: a Raspberry Pi 4B, a camera and GPS, with processing near the car and vision experimentation in Python. Turning a computer-vision hypothesis into something that could physically exist inside a vehicle.
Hardware makes a prototype tangible, but it also introduces constraints you have to treat as part of the product: installation, power, cost, maintenance, connectivity and scaling. None go away with a good algorithm.
Making detection useful enough to continue.
The question that mattered wasn’t “can a camera see a face?”. It was whether accessible technology could identify useful signals of driver state — drowsiness, fatigue, distraction — while a person is actually driving.
Early detection experiments used facial landmarks and signals such as eye state, yawning and head position. Practical work around computer vision, not a state-of-the-art ML model.
This demonstrates practical experience working around computer vision and facial analysis. It does not justify the title “computer vision expert”.
We measured it: 20 trials per signal, day and night. Yawning was the most reliable signal (85%); closed eyes the hardest (65-70%). This is not scientific validation or a production metric: it’s what we knew, with the sample size we had.
The model was never the whole product.
Long before talking about agents or applied AI, SafeDrive had already taught me the same lesson: an isolated technical capability doesn’t create a useful system. The PFC evolved the prototype into an end-to-end system.
Simplified; it doesn’t represent every later version.
Detecting an event was only one part of the product.
Fleet managers needed to understand what happened across a trip, a driver and eventually a fleet. The goal stopped being only “detect sleep”: we started turning driving data into information someone could use.
The first truck test broke things too.
And that was part of the goal.
On one of the first full-system tests, problems appeared in the data-upload flow to the server. We went back to the code, debugged the main flow, fixed the issues and repeated testing on another vehicle, then validated event collection and GPS behavior.
The value of going to the field wasn’t proving everything worked. It was discovering what didn’t yet. I don’t claim formal scientific validation.
The project also had to be explainable outside Engineering.
As the project advanced, we stopped explaining it only to professors or classmates. We were invited to present SafeDrive at Presidencia during the XIV National Road Safety Week, organized by UNASEV, before representatives associated with UNASEV, BSE and Caminera.
For me, that part was engineering too: being able to explain what we were trying to do, what worked, what didn’t and why it could matter.
Building it made us ask whether there was a business inside it.
Building it forced us to ask whether there was a business inside. The answer didn’t come from us: it came from talking to fleet people, insurance professionals and companies already living with the problem. That contact shifted the focus toward fleet analytics, cost and real product usefulness.
Initium — our sponsoring institution and product/business bridge
Initium, Universidad de Montevideo’s entrepreneurship center, was our sponsoring institution (IPE) and supported us through the whole process: not only the early commercial exploration, but as the institution that formally backed the project before the funding programs. The Ingenio incubator also supported us along the way.
Incubaelectro — from project to incubated startup
The team was selected for Incubaelectro, which provided funding plus access to infrastructure and different kinds of support during incubation.
UYU 150,000ANDE VIN — does it survive a real fleet?
The VIN stage had a clear objective: move beyond validating SafeDrive among ourselves and into real organizations, vehicles and drivers.
UYU 222,000From the lab to real fleets.
A later stage of the project had a very concrete goal: to stop validating SafeDrive only among ourselves and take it to real organizations, vehicles and drivers.
“We didn’t mark commercial validation as complete just because companies liked the idea.”
Validation involved organizations from different areas, to test against reality rather than one friendly demo vehicle.
Installations across different companies and vehicles.
Installation, devices inside different vehicles, cables, drivers and team at work.
Facial landmarks over truck drivers, live.
During the pilots we accessed each vehicle’s Raspberry Pi remotely. We could watch the processed frame with facial landmarks over real drivers and the detection logs running in the moment.
From tape to a 3D-printed design.
Installing the product by hand taught us the housing was part of the problem. We went from an IR camera held on with tape to our own design: we modeled it in 3D, printed it and mounted it on the windshield.
Reality started writing requirements we had never imagined.
Power
Driver interaction
Physical design
Usability
A field test is product discovery with consequences.
During validation we also considered truck visibility regulations so the device wouldn’t become a physical obstruction: systems thinking around the real environment, not regulatory expertise.
The best technical solution wasn’t necessarily the best product.
After years trying to improve the device — hardware, PFC, field testing, pilots and real physical problems — we started asking a different question: what part of the value actually required dedicated hardware?
“How do we make this device better?” became: “do we need it to deliver value?”
Dedicated vehicle device
Value from the phone
Neither version is objectively superior. What changed was the product hypothesis, not just the code. With everything learned before, the pivot felt inevitable, not a slogan.
The pivot was implemented, not just discussed.
We progressed to a functional mobile implementation. An Android POC focused on drowsiness detection reached an advanced functional state, built with React and Expo / React Native.
It wasn’t a commercial launch: testing, refinement and release work remained. But the pivot stopped being a slide idea and started existing as something you could open and use.
My role evolved too.
We were four cofounders, all software engineers. Early formal material describes my hands-on work in frontend, web and Raspberry Pi. As SafeDrive became an entrepreneurial project, my contribution expanded into product, commercial conversations, funding, programs, presentations and the relationship with the university and institutions. A good part of the physical work was mine too: building the device and installing it in the vehicles, under the steering wheel with a flashlight in my mouth. Marcelo and Matías were in that part as well. It’s not a colorful detail: installing the product with your own hands is the fastest way I know to understand why installation is a product problem and not a formality.
Engineer
Hands-on technical work.
Product builder
What should the system actually do?
Cofounder
Making the project exist beyond the classroom.
Product/external interface
Connecting team ↔ university ↔ programs ↔ institutions ↔ companies.
“For much of the journey I was one of the people connecting the team with those who could help the project move forward.”
No project like this holds up on one person.
SafeDrive changed shape and team across its stages, with an academic origin and a broader group of students. The entrepreneurial stage consolidated around four cofounders. I especially took on the commercial side, the relationship with the funds and the outward contact; the others carried technology and execution — and on the installs, several of us had our hands inside the vehicle.
Each actor was there for a different reason.
Not every name represents the same relationship. I separate them to avoid overclaiming: origin and collaboration, incubation and support, and validation funding.
Where the problem and first context came from.
The institution that formally backed the project before the programs.
Infrastructure and support during incubation.
ANDE didn’t only provide funding: it also gave us support and mentoring during the validation stage.
We didn’t run out of ideas.
We ran out of the conditions to do the next stage properly.
Over time, the team began combining SafeDrive with increasingly demanding professional careers. We had progressed technically and had a mobile direction, but taking it to a serious stage required dedication and resources the project didn’t have secured. We preferred to pause it rather than keep it artificially “active”. It didn’t stop because the prototype failed or because the problem stopped being interesting.
Paused. For now…
The problem stayed hard. The tools changed.
Today I could test several of SafeDrive’s hypotheses at a very different cost and speed of experimentation, thanks to advances in vision, mobile and AI-assisted engineering. That changes the cost of learning.
It doesn’t remove the responsibility of validating a safety-related technology: reliability, false positives, privacy and responsibility still matter. The interesting opportunity isn’t only “better AI”: it’s that a small team can test more hypotheses with far less execution overhead.
How I think about applied AI →SafeDrive changed how I think about product.
A prototype proves a hypothesis. A product has to survive people, business and reality.
Before “can we detect it?” come the questions that actually define a product: who uses it, who pays and what problem it solves. Detection was the technical starting point, not the priority.
Field testing changes what the problem looks like.
Reality exposes constraints no whiteboard shows, and it starts putting a price on complexity.
More technology is not automatically a better product.
The mobile pivot proves it: sometimes the best move is to remove hardware, not add it.
Willingness to pay is different from technical feasibility.
Something working doesn’t mean anyone will pay for it. That’s the most expensive distance to cover, and the only one you can’t shorten by coding better.
What SafeDrive required from me.
Have a hard problem and don’t yet know what product is inside it?
SafeDrive started exactly there: an open question, a lot of uncertainty and no perfect spec. It’s one of the product stages I enjoy most: understand, test, reduce uncertainty and decide what’s worth building.