← All articles

ORBII Monthly Report: September 2026

How many people use ORBII, how many real emergencies it handled, and what we fixed. 1,255 users, up from 76. 219 emergencies. The numbers, the engineering, and the things we are not claiming yet.

This is the first of these. Every month we will publish what ORBII actually did: how many people use it, how many real emergencies it handled, what we shipped, and what we found wrong in our own work.

The numbers below come from our production database on 4 October 2026, covering the previous thirty days.

The month in numbers

A month agoTodayChange
People using ORBII761,255+1,179
Real emergencies handled11219+208
Voice protection sessions armed91639+548
Circles—554626 people in them

The thirty days before this one added 36 people. So this was not steady growth, it was a step change.

One number inside that deserves attention on its own. 174 of the 219 emergencies happened in the final seven days. Four out of five of the moments ORBII has ever been needed for happened in the last week of the month.

What ORBII does, briefly

A woman in danger often cannot reach her phone. It is in a bag, in a pocket, or someone is holding her arm. Every safety app built around a button assumes the one thing an emergency takes away: a free hand and a few calm seconds.

So ORBII listens instead. You say “bachao”, “मदद” or “help”, and a short countdown starts. If you do not cancel it, your circle is told where you are.

Two decisions make that work, and both are unusual.

The speech recognition runs on your phone. Not in our cloud. There is no server listening to Indian bedrooms and buses. The model sits on the device, in English and Hindi, which is also why it works with no signal at all. No audio is uploaded for recognition, ever.

The emergency does not depend on our server existing. If we are down, if the network is down, if the tower is gone, the alert still goes out by SMS and by relay through any nearby ORBII phone over Bluetooth.


What we found in our own code

Growth is flattering for about a day. Then it starts asking questions you cannot answer with optimism.

We had been collecting a number since launch and had never looked at it. Every voice countdown records whether the person let it finish or cancelled it. When we finally queried it, sorted by how confident the engine was that it heard a distress word, it said this:

Engine confidenceCountdowns cancelled
High8%
Normal42%
Low55%

That is a detector separating real from imagined. It also settled an argument we had been having about replacing the speech engine entirely. The answer was no, and we had evidence rather than opinions.

Then we went looking for the actual problem, and found it.

We reconciled every confirmed voice countdown against the emergencies our database held. They did not match.

Some alerts had been retried until a counter ran out, then discarded. A queue designed to give up after eight attempts was doing exactly that. Giving up is not a thing that belongs in a safety app.

Others existed in the database only because the person eventually cancelled. That means no record existed while the emergency was live, which means nobody could have been sent.

We had built something that could lose an emergency quietly, and we had not known, because nothing was watching.

What we rebuilt

The emergency is written to the phone first. Before the alert goes out, before the server is contacted, before anything asynchronous happens at all. A dropped signal, a restart, a dead battery or a killed app cannot erase something already on disk. That write is time-bounded, so making it durable can never delay the alert itself.

Retry exhaustion no longer deletes anything. When automatic retries end, the emergency moves to a held state and keeps trying, indefinitely, and immediately again the moment signal returns. Eight failed attempts means the network is bad. It does not mean the emergency stopped existing.

One piece of code writes an emergency record. There used to be four, and three of them disagreed about what to write.

The database refuses an incomplete emergency quietly. If any app version sends a record missing information, the server completes it and records that it had to. That protection reaches every phone immediately, including ones that will never install an update, which matters more than it sounds. Most users are never on your newest build.

Every alert channel reports its own outcome. Your circle, nearby helpers, the community: each records what happened independently, and one failing can no longer cause another to fire twice.

A word we refuse to use

There is no “delivered” state anywhere in ORBII, and that is deliberate.

A push provider accepting a request proves the request was accepted. It does not prove a phone rang. Nothing in this stack can prove that, so we do not have a state that claims it.

Naming something “delivered” because an API returned 200 is how you end up believing a system works when it does not. On a safety app, that belief is the dangerous part. We would rather say “we asked, and here is what each channel answered”.


The engineering behind it

  • 342 automated tests across the app and the Android service, including one that runs 7,200 randomised cases through the voice trigger decision to prove a refactor changed nothing
  • 186 database migrations, every one now accounted for as applied, deliberately waived with a written reason, or honestly marked unprovable
  • Zero audio uploaded for recognition, on any plan, at any time

What we are not claiming

Our automated tests prove this behaviour in simulation. Physical-device testing of the full emergency path is not finished. Until it is, we will describe what we have built rather than promise what it guarantees.

On a safety app, under-claiming is the only responsible setting. If we tell you it is unbreakable and you find out otherwise at the worst possible moment, we have done something worse than build it badly.

Next month

Device testing of the complete emergency path. Closing the remaining issues from our own internal audit. And this report again, with whatever we find.

Every safety feature in ORBII is free, including hands-free Voice SOS. Not a trial, no card, no tier.

1,255 people trusted this app last month. 219 of them actually needed it.

Get ORBII on Google Play · How Voice SOS works · हिंदी में पढ़ें

Frequently asked questions

How many people use ORBII?

1,255 as of 4 October 2026, up from 76 a month earlier. In that period ORBII handled 219 real emergencies, 174 of them in the final week.

Does ORBII's voice recognition work without internet?

Yes. Speech recognition runs entirely on the phone, in English and Hindi. No audio is uploaded for recognition at any point, so it works in a basement, on a dead network and in airplane mode.

What happens if the network fails during an emergency?

The emergency is saved to your phone before anything touches the network. If the server cannot be reached the alert keeps retrying, and it also goes out by SMS and by relay through nearby ORBII phones over Bluetooth.

Can an emergency be lost if the app is killed?

The record survives, because it is written locally before any network call and restored when the app next runs. Retry exhaustion no longer deletes anything. This is proven by automated tests. Physical-device testing of the full path is not finished, which is the honest limit of what we can claim today.

Is ORBII free?

Yes. Every safety feature is free, including hands-free Voice SOS. It is not a trial and no card is required.

Download on Google Play