What If Your Screen Time Had a Bank Account? I Spent 6 Months Building One

Rakovskyy — Wed, 23 Sep 2026 16:53:03 +0000

Opal stopped working for me during the second week—not because the app was broken, but because I kept finding ways around the rules I had created for myself. Sometimes I forgot to start a focus session. Other times, when a scheduled block appeared at an inconvenient moment, I simply removed the limit.

I was both the person creating the restriction and the person who could disable it, and the second version of me usually appeared exactly when my self-control was at its lowest. This is not really a criticism of Opal. It simply made me notice a more fundamental problem with how I was trying to manage screen time.

Most screen time tools begin with the same assumption:

If you use an app too much, block it.

But blocking did not make my time feel more valuable. It only created another rule that I could eventually ignore. Money is limited too, yet we do not manage it by permanently blocking every store. We earn it, keep it in an account, decide how to spend it, and notice when the balance approaches zero.

That led me to a slightly strange question: what if screen time worked the same way? What if leisure time had to be earned first, stored in a balance, and consciously spent?

That question eventually became Ravelo.

Time as currency came first

The idea of treating time as a currency existed from the beginning. The first model was simple: complete a focus session, earn minutes, add them to your balance, and spend those minutes to access selected apps. Instead of receiving an arbitrary daily limit, you would create your own allowance through focused work.

The banking appearance came later, when I had to answer a difficult product question: why would anyone remember Ravelo when the App Store already had dozens of screen time tools? The earning and spending model was different, but the interface still looked like another productivity app.

That was when I decided to make the metaphor visible. The balance became an account, the main screen started resembling a bank card, purchases became transactions, and focus sessions became deposits.

These elements were not added only as decoration. They gave people a familiar mental model for understanding something abstract. You do not need a long tutorial to understand that a balance can increase, decrease, or run out.

The first prototype was barely a product

The first Ravelo prototype was rough, visually inconsistent, and dangerously easy to crash. It could block apps, and that was approximately the entire product. There was no polished banking interface, no proper transaction history, and very little protection against unusual states. It was the core mechanism wrapped in just enough UI to let someone try it.

Opening the beta made the difference between a working mechanism and a usable product painfully obvious. Testers immediately found assumptions I had never questioned.

There was no way to pause purchased time. If someone unlocked an app for 20 minutes, used it briefly, and put the phone away, the remaining minutes continued disappearing. The available purchase intervals were also too large. Sometimes a person did not want a full 15- or 20-minute session; they only wanted to reply to one message or check something for five minutes.

The first versions were more forgiving about interrupted focus sessions. If someone planned a 30-minute session but stopped after ten minutes, those ten minutes were still added to the balance.

At first, this seemed fair: the user had focused for ten minutes, so why should that effort disappear? But it weakened the meaning of the session. A focus session was supposed to be an investment in future leisure time, not a counter that could be stopped as soon as the accumulated reward felt sufficient.

I eventually reversed the rule. Now, the planned session must be completed successfully before any minutes are added to the balance. When it is completed, the full reward is deposited at once.

This made the relationship much clearer: you commit to a focus session, complete it, and receive the time you earned. The reward is no longer based only on how long the timer happened to run, but on keeping the commitment you made to yourself.

The beta taught me that people were not evaluating Ravelo as an interesting experiment. They were trusting it with something they already felt they lacked: time. That made every lost minute, delayed block, and unclear state much more important.

The feature testers preferred was the one I could not trust

During development, I experimented with two ways of spending time.

The first was usage-based. If you purchased 20 minutes for an app, the balance decreased only while you were actually using it. You could open the app for three minutes, leave, and still have 17 minutes available later. Testers liked this model because it felt fair and natural: the system charged for actual usage rather than time passing in the background.

The second model was time-based. If you purchased 20 minutes, the app stayed available for a 20-minute clock window. The session could be paused, but while it was active, time continued to pass whether the selected app was open or not.

On paper, usage-based was clearly the better experience. In practice, it depended on something I could not guarantee.

Ravelo uses Apple’s Screen Time frameworks, including FamilyControls, DeviceActivity, and ManagedSettings. The usage-based model required the system to notify Ravelo when an app reached an exact usage threshold. If someone purchased 15 minutes, the rule was simple: at minute 15, access should end.

But DeviceActivity callbacks are not hard real-time events. In my testing, I could not rely on the selected app being blocked at the exact moment the purchased usage ran out, especially while the user was actively inside it.

A small delay might sound harmless, but it broke the central promise of the product. If the balance says zero while the app remains available, even briefly, the balance is no longer something the user can fully trust.

I had to choose between a more convenient model that behaved unpredictably in edge cases and a slightly less elegant model whose rules I could enforce consistently. I chose the second one, and Ravelo moved to the time-based system.

It was difficult to remove the model users preferred, but a reliable promise was more important than a theoretically perfect experience.

Apple’s 15-minute minimum met a five-minute user need

The time-based model solved one problem and exposed another. Apple’s DeviceActivity scheduling system expects an interval of at least 15 minutes, so 15 minutes became the natural minimum purchase inside Ravelo.

Then testers asked a very reasonable question:

What if I only need five minutes?

Fifteen minutes can be a long time inside an app you are actively trying to use less. Someone might only want to reply to a message, publish something, or check one piece of information. Forcing them to purchase 15 minutes meant they either spent more time than intended or watched the unused part of the purchase disappear.

I did not want a framework limitation to become a product rule, so I added a translation layer. From the framework’s point of view, the interval is still 15 minutes long, but when someone chooses five minutes, the first ten minutes are treated as already elapsed.

The framework gets the minimum interval it expects, while the user gets the five-minute window they requested. There is no complicated algorithm behind it, but this small workaround represents a large part of building Ravelo: translating rigid system constraints into rules that feel reasonable to a person.

Ravelo is still an experiment

Ravelo is available on iPhone, but I still see it as an experiment rather than a finished answer to screen time. The app works, the banking model is understandable, and the feedback from testers has already shaped many of its rules. What I do not know yet is whether this way of thinking about time can produce a lasting change instead of becoming another system people eventually learn to ignore.

That is what I want to understand next: whether earning and spending time can remain useful after the novelty disappears, which parts of the model feel natural, and which ones still create unnecessary friction.

For now, I am keeping the experiment focused on iPhone. If the model proves useful and people continue using it, I would like to bring Ravelo to Mac and eventually Android. A shared balance across devices could make the idea much more meaningful, but first I want to make sure the idea itself deserves to grow.

A bank cannot be “mostly correct”

Turning Ravelo into a bank for time helped distinguish the product, but it also raised the standard users applied to it. People might tolerate an occasional inconsistency in a productivity timer, but they do not tolerate an incorrect balance.

Once the interface includes a card, transactions, purchases, and deposits, every change starts to feel financial—even though no real money is involved. If a focus session completes, users expect the deposit to appear. If five minutes are purchased, they expect access to last five minutes. If a session is paused, they expect the remaining balance to stop moving.

The banking metaphor made Ravelo easier to understand, but it also made reliability part of the design. I could not treat the interface and the underlying Screen Time logic as separate problems. A beautiful balance that is occasionally wrong is worse than an ugly balance that can be trusted.

Open beta changed the product more than I expected

I initially thought the beta would mostly uncover crashes. It did uncover crashes, but the more valuable feedback was about the rules themselves.

Testers did not describe problems using technical terms. They talked about moments when purchased time continued disappearing after they had put the phone away, when the minimum purchase felt too large, or when an app did not lock again exactly when they expected it to.

Their feedback also forced me to think more carefully about what a completed focus session should mean. Should every minute spent focusing produce an immediate reward, or should the reward represent a commitment carried through to the end?

Those questions exposed gaps that code reviews could not. I was testing whether Ravelo performed the actions I had programmed. Users were testing whether Ravelo behaved according to rules they could understand and accept.

Those are not the same thing.

Six months later

Ravelo did not emerge from a perfect product plan. It grew from a personal failure with app blocking, a slightly strange analogy, an unstable prototype, and many conversations with testers who used the product differently from how I expected.

The original question is still at its center:

What if screen time was something you earned and consciously spent?

At first, I thought the difficult part would be tracking minutes. Later, I thought it would be enforcing restrictions. Eventually, I realized the hardest part was creating a system that felt fair, remained predictable under iOS constraints, and was simple enough for someone to trust without understanding how it worked.

I still think usage-based spending is the more natural model. But I would rather ship a slightly less elegant promise that Ravelo can keep than a perfect idea it can only enforce most of the time.

Ravelo is now available on iPhone, and I am still learning where this model works, where it fails, and whether thinking about time as a balance can actually change the way people use it.

Learn more at ravelo.app.

Or download Ravelo directly from the App Store.

If you were making the same decision, which would you choose: usage-based access with occasional timing uncertainty, or a predictable time window that may charge for minutes you do not use?

DEV Community: Rakovskyy