A gap worth working on after the hackathon
FallBack began at the Straight Up! social hackathon. My co-founder, Moiz Khambhati, and I wanted to use AI to solve a practical social problem. We found a clear gap in senior monitoring. Cameras make it possible to see what is happening, but at the cost of privacy. Wearable alerts only work when they are worn, charged, and within reach.
We tested the idea through a directional survey of 43 caregivers recruited through online and personal channels. Thirty-four respondents, or 79% of the sample, preferred passive radar over cameras and wearables. Caregivers repeatedly brought up privacy and peace of mind together. They wanted useful awareness without making the person they cared for feel watched.
That gave us one constraint we would not compromise on: FallBack would detect safety events without recording images or requiring the senior to remember another device.
The opportunity was useful awareness with less intrusion.
Proving the signal before polishing the story
The prototype pairs a wall-mounted mmWave radar sensor with an ESP32 relay. It detects motion and fall events without capturing a video feed, then passes that signal into the software experience. When the hardware is unavailable, we can trigger the same event path manually. This let us demonstrate the complete response flow during the hackathon without depending on a perfect live sensor demonstration.
In controlled prototype testing, the model detected 41 of 50 fall trials, an accuracy of 82%. That was enough to show that the concept could work, but it is not a production benchmark. We still need broader testing across rooms, people, fall types, and daily activity.
Once an event is created, FallBack records it, surfaces it on the caregiver dashboard, and can escalate it through Telegram and an automated phone call. A detection model without a reliable path to human action is just a technical demonstration, so we built the full loop.
Making a dense dashboard answer one urgent question first
I was responsible for the product design and software development across the frontend and backend, as well as the slides and technical preparation for the pitch. The dashboard was the hardest interface. It had to hold immediate fall alerts, sensor status, recent incidents, movement patterns, risk flags, and weekly summaries without turning a family-safety product into a wall of telemetry.
The hierarchy starts with the question a caregiver opens the product to answer: does someone need help now? Active incidents interrupt the normal dashboard and remain in history after they are acknowledged or resolved. Sensor health and recent context help with that decision. Longer-term trends sit behind the immediate state instead of competing with it.
The interface stays calm during ordinary use and becomes direct when action is required. Most days have no emergency. If the interface signals an emergency all the time, caregivers either become anxious or learn to ignore it.
The dashboard can contain many signals, but the caregiver should never have to decide which one matters first.
Keeping the dependable demo separate from production guardrails
The first repository connected the experience to Clerk authentication and Supabase persistence. That architecture was a step toward a real deployment, but it also made the hackathon demonstration depend on several external services and credentials.
We now keep those needs separate instead of asking one build to do both jobs. The demo repository uses local persistence and a constant demo identity. This lets judges, collaborators, and the team exercise onboarding, fall creation, the dashboard, and alert history without configuring production infrastructure. A separate production path keeps the authentication, durable storage, webhook, retry, and security guardrails required for real use.
The production system is not finished. We treat the two builds differently: the demo should be easy to run and difficult to break, while the production product should meet a different operational standard.
Awards created momentum; the prototype had to back them up
FallBack won Best in Category and Crowd Favourite at the hackathon, along with sponsor-credit packages worth more than 8,000 for each co-founder. The project later received approximately SGD 4,000 in school funding. That gave us room to keep developing the sensor, software, and commercial direction after the event.
Those outcomes validated the problem and our ability to explain it, but they did not validate the product in real homes. FallBack is still a functional prototype. We have tested the sensing and response loop ourselves, and structured testing with caregivers and older adults is still planned.
The project left me with a simple lesson: product is king. Funding, awards, and a strong pitch can create momentum, but none of them replaces a working system that people can see, test, and challenge. Our next job is to turn the early technical proof and the positive response from judges into evidence that FallBack works reliably for the people it is meant to protect.
Funding can extend the runway, but it cannot replace a functional product.
