Inspiration
Billi began with a simple question:
What if help did not have to begin after something bad had already happened?
The original idea came from thinking about children experiencing bullying. Too often, a parent, teacher, or trusted adult learns about an incident only after the child has already been hurt. I wanted to explore whether the technology people already carry could help close that gap—so the people who care could know sooner, understand more, and begin responding while the situation was still happening.
As I worked on the idea, I realized the same communication gap appears far beyond bullying.
A child can become separated from their family. An older adult can wander beyond a familiar place. Someone can fall and become unable to reach a phone. A driver can crash. A student can feel unsafe. A rideshare driver, contractor, home-health aide, courier, real-estate agent, or other person working alone can find themselves in a situation where nobody who cares about them knows what is happening.
That became especially important to me because emergencies do not always begin with someone calling for help.
Sometimes the person cannot speak. Sometimes they are injured. Sometimes they are confused or nonverbal. Sometimes openly reaching for a phone could make the situation more dangerous.
Billi was built around that moment.
Today, Billi is positioned especially around people who work alone and the families they go home to. I did not want a sole proprietor or independent worker to need an enterprise safety department to have access to coordinated protection. The same person who needs protection while driving, making deliveries, entering customers' homes, working a job site, or closing a business late at night may also want to protect their child or another family member. Billi is designed so those worlds do not have to be separate.
What Billi Does
Billi is a Safety Coordination Platform.
Instead of sending one isolated alert, Billi creates a shared, evolving incident that the protected person, their trusted network, and authorized responders can participate in together.
A person can configure their safety plan before an emergency: who should be contacted, in what order, what information can be shared, which emergency actions are authorized, safe words, duress behavior, medical information, safe zones, and available devices.
Billi can then be activated through multiple paths, including a spoken safe word, a hold-to-activate control, sensor events such as a fall or crash, a duress condition, or other configured signals.
When an emergency activates, Billi is designed around four immediate actions:
Acquire and continue updating location Begin authorized audio evidence capture Begin authorized visual evidence capture where supported Notify the user's Trusted Network
But the important part is what happens after the alert.
Billi maintains one live incident so everyone involved can understand:
Where is the person? Are they moving? What triggered the emergency? What information is available from their devices? Who has been notified? Who acknowledged? Who is responding?
A guardian can press “I AM RESPONDING,” and that confirmed state is shared back to the protected person's device. Billi can then speak a verified message such as:
“Your guardian received your alert.”
or:
“Your mother is responding.”
The goal is to move the person from “I am alone” to “someone knows.”
How I Built It
Billi was built rapidly, with a very limited budget, by combining modern agentic development tools with technologies that already exist in phones, browsers, Android devices, cloud infrastructure, and AI systems.
I did not set out to invent GPS, microphones, accelerometers, geofencing, Bluetooth, cameras, text messaging, or wearable sensors. Those technologies are already mature.
The innovation is in how they are orchestrated around one emergency and one protected person.
The current platform includes a 13-service domain-driven backend architecture responsible for identity, safety protocols, orchestration, communication, incident timelines, emergency packets, telemetry, device capabilities, AI context, action execution, observability, feedback, and gateway routing.
The platform also includes role-specific front-end experiences for protected people, guardians, responders, onboarding, safety-contract configuration, hardware management, incident history, and live demonstrations.
Billi now supports shared incident state across multiple sessions. A protected person can activate Billi on one device, a guardian can join the same incident from another device, acknowledge that they are responding, and the protected person's device receives that confirmed update. Responder activity can also enter the same shared incident.
The project also includes a native Android path that can use real device capabilities such as GPS, motion, audio, and SMS from the phone itself.
Google Gemini is the AI inside the product. It is used for incident-context synthesis, risk interpretation, translation, and recommendations. Billi does not allow AI to independently override the user's pre-authorized Safety Contract: Gemini can recommend an action, while a separate rules layer determines whether that action is permitted.
I used several development tools to build the system:
Google Antigravity — approximately 50%: architecture, the 13-service backend, front-end surfaces, and substantial implementation work. Codex — approximately 30%: implementation across backend services and front-end components. Claude Code — approximately 20%: onboarding reconstruction, product repositioning, demonstration scenarios, deployment tooling, documentation, and additional implementation. Gemini — inside the production product: live AI routes for incident understanding and reasoning, with deterministic fallback behavior when live AI is unavailable.
I used multiple tools because I did not have an engineering team or a large development budget. When one environment or usage limit became a constraint, I kept building with the tools available to me.
In roughly a month, that process took Billi from an idea and earlier prototype into a public platform with a domain-driven backend, shared incident coordination, real-device capabilities, live Gemini integration, Android support, deployed demonstrations, and a working subscription checkout.
Challenges I Faced
The hardest challenge was not simply writing code.
It was deciding what must actually happen when someone's safety is at stake.
Emergency technology involves sensitive information: location, medical records, microphone access, cameras, trusted contacts, evidence, and potentially information intended for responders. That forced me to think carefully about permissions, privacy, consent, coercion, false alarms, and how much authority AI should have.
One major design principle emerged from that challenge:
Onboarding is the Safety Contract.
The emergency is not the time to ask someone whether Billi may access their location, share medical information, record audio, or notify a particular person. Those decisions should be made beforehand, while the person is safe and able to think clearly.
Another challenge was avoiding false confidence.
For example, Billi distinguishes between an alert being queued, sent, delivered, and acknowledged. The system should not tell a protected person that their mother received an alert unless that state has actually been confirmed.
The same principle applies throughout the product. Billi does not claim that a simulated BLE relay is a functioning physical mesh network. It does not claim to replace 911. It does not claim professional monitoring when no monitoring center exists. Where hardware or external integrations are incomplete, the platform identifies those boundaries.
Another major challenge was designing Billi so that it could support very different emergencies without becoming nine different applications.
A fall, a crash, a coerced cancellation, a wandering child, a lone worker in danger, and a medical emergency look very different—but the coordination problem underneath them is remarkably similar.
Someone needs help.
Information needs to start moving.
The right people need to know.
The situation may continue changing.
And someone needs to respond.
That realization became the foundation of Billi's shared incident architecture.
What I Learned
The biggest thing I learned is that emergency response is fundamentally a coordination problem.
GPS by itself is not enough.
A panic button by itself is not enough.
A recording by itself is not enough.
A text message by itself is not enough.
AI by itself is not enough.
Each can provide part of the answer, but the real value appears when those pieces work together around one person and one evolving situation.
I also learned that AI is most useful when it reduces confusion rather than replaces human judgment. Gemini can help transform location, movement, audio, device state, and incident history into understandable context, but guardians and responders still need to make the critical human decisions.
I learned that transparency matters just as much as capability. In a safety product, saying something worked when it did not can be worse than not having the feature at all.
And on a personal level, I learned how much a single person can now build with modern AI-assisted development tools.
I built Billi without the engineering budget, staff, or infrastructure normally associated with a platform of this scope. That constraint shaped the product itself.
Many of the people Billi is intended for—independent drivers, contractors, home-health workers, sole proprietors, caregivers, small operators, and families—also do not have enterprise resources behind them.
That connection became part of the mission.
What Comes Next
The next stage is turning the current early-access platform into an increasingly production-ready safety system.
That includes expanding real-device support, strengthening Android execution, improving cross-device notification delivery, connecting additional wearable and partner-device capabilities, expanding evidence capture, continuing Gemini integration, and pursuing appropriate emergency-service and responder integrations.
I also want to continue validating Billi with the people it is intended to serve—especially people who work alone and families who need a more coordinated way to protect the people they care about.
Billi began with a child who might need help before it was too late.
It became something larger:
A way to reduce the distance between something going wrong—and the right people knowing enough to act.
Because in an emergency, the question should not have to be:
“How do I explain everything that's happening?”
It should become:
“Who knows I need help—and who is coming?”
That is what Billi is being built to answer
Log in or sign up for Devpost to join the conversation.