Why this alarm exists

The problem

Most alarm advice assumes the problem is willpower. It usually is not. For the first few minutes after waking, the brain is awake enough to act but not awake enough to reason or lay down memories. In that window, a person can reach out, dismiss an alarm, and go back to sleep with no recollection of any of it.

A single tap fits comfortably inside that window. That is the whole design flaw. It is not a volume problem, which is why buying a louder alarm buys a few weeks at best — you habituate to loud sounds the same way you habituate to quiet ones.

The fix is to require something the half-asleep brain cannot do: arithmetic, twenty steps, finding an object and pointing a camera at it. That is the entire idea, and plenty of apps have had it — the seventeen missions we ship are one implementation of it. What differs is what you build around it, which is set out in how the wake loop works.

What we build around it

An alarm is infrastructure. It has one job, it does that job while you are unconscious and cannot supervise it, and a single failure destroys trust permanently. That framing produced five rules that sit at the top of our engineering guidelines and are treated as non-negotiable rather than as preferences.

1. 1

   Never put alarm reliability behind JavaScript

   The operating system owns the schedule, the sound and the wake presentation. If the app and the system disagree about state, the system wins. Everything else in the product is negotiable; this is not.

2. 2

   Nothing on the ring path may require network

   No cloud inference, no remote config fetch, no auth refresh. A user with no signal must still wake up. This constraint is why camera missions run on-device, and why there is no advertising.

3. 3

   Never block the user permanently

   Every mission has a timeout and an escape hatch. "This app made me miss my flight" is a support ticket and a one-star review. Friction is the goal; entrapment is not.

4. 4

   Camera frames are never persisted or transmitted

   All inference is on-device. This is a privacy promise, not an implementation detail — and it is checkable, because the missions keep working with the network off.

5. 5

   The mascot never shames the user

   It encourages on success and shrugs on a snooze. Roosta is disappointed for you, never in you. The mechanic is already adversarial; the rooster is the counterweight.

Things we have got wrong

The alarm scheduler has been rewritten more than once. The first version kept the schedule inside the app, which worked perfectly in testing and failed in exactly the way our Android troubleshooting guide now warns about: battery optimisation suspended the process, and alarms did not fire. That failure is why the reliability rule is written the way it is, and why it is first on the list.

The mascot has also been reworked. An earlier direction leaned on the guilt-trip register that habit apps have made familiar. It tested as unpleasant in exactly the moment it mattered — a person who has just failed to get up does not need a cartoon being disappointed in them — and the tone rule exists because of it.

Who builds it

Roosta is made by a small independent team rather than a venture-funded company, which is why the business model is a subscription and not advertising. There is nobody to sell your data to, and no growth target that would make an ad on the dismiss screen look reasonable.

What we will not do

• Put advertising anywhere in the app, and especially not between you and a ringing alarm.
• Upload camera frames, audio, or location for any reason.
• Remove the escape hatch, however much it would improve our completion metrics.
• Use guilt as a retention mechanic.
• Claim the app treats a sleep disorder. It gets you out of bed; that is all.

The full detail of what leaves your device is on the security page.