The Context
We build Live Draw Togel Pewaristoto — an Android app covering the 5 most popular lottery markets in Indonesia: Toto Macau, HK Pools, Sydney Pools, Singapore 4D, and Singapore Toto. The same infrastructure also powers pewaristotoprediksi.com, the web version that covers 70 markets worldwide for users who prefer browser over app. No ads, no gambling features, just data. Built by Pewarisgroup as a free reference tool for the Indonesian togel community.
The core feature is simple: when a new draw result comes in, users should know about it.
So naturally, we built push notifications.
V1: Notify on Every Result
The first implementation was straightforward. Our backend scrapes result data from official lottery websites on a scheduled basis. When we detect a new result — by comparing against the last stored data — we fire a push notification to all users who follow that market.
Simple. Obvious. Makes sense.
Then we added Toto Macau.
Macau draws 6 times a day — at 00:01, 13:00, 16:00, 19:00, 22:00, and 23:00. Users who followed Macau were getting 6 notifications a day from that market alone. Users who followed multiple markets — Macau, HK Pools, Singapore 4D, Sydney — were getting anywhere from 10 to 15+ push notifications daily.
We'd built an interruption machine.
The Problem With "Real-Time" for Scheduled Events
Here's the thing about lottery draws: they're not unexpected events. Users know Macau draws at 13:00. They know HK Pools draws in the evening. The information isn't surprising — it's just data they want to see when it's available.
Push notifications make sense for genuinely unpredictable events. "Your package arrived." "Someone replied to your message." These are things you couldn't have anticipated.
But "Macau 13:00 result is out" — the user already knew this was coming. They don't need to be interrupted. They just need the data to be there when they check.
We were solving the wrong problem.
What We Built Instead
Homescreen widget
The widget sits on the user's Android homescreen and updates automatically. No notification, no interruption. The result is just there the next time they look at their phone. For users who check frequently, this is actually better than a notification — it's always visible, always current, zero friction.
Daily digest
An opt-in notification that fires once a day — default at 21:00, but configurable by the user — summarizing every market that had a new result that day. One notification instead of fifteen. For casual users who just want a daily recap, this is enough.
We were pretty happy with this. Two elegant solutions for two different user types.
Then we ran into reality.
Our Users Are Not Who We Imagined
Indonesian togel players skew older. A significant portion of our users are not particularly tech-savvy — and we mean that with genuine respect, not condescension. They found our app, they use it daily, they care about the data. But asking them to add a widget to their homescreen is not a trivial request.
When we first introduced the widget, we had users asking us why their notifications stopped working. We explained: there's a widget now, and a daily digest. Some understood. Some didn't. Some just wanted their notifications back.
We learned something important: you can't replace a familiar behavior with a better one and expect users to immediately adopt it. Especially when the "better" option requires them to do something they've never done before — like long-pressing their homescreen, finding the widget menu, and figuring out how to place it.
The Current State: Still Figuring It Out
So here's where we are now.
For a while we had all three options: per-result notifications (still available but not default), daily digest, and widget. Users could choose based on their preference and comfort level.
Recently we removed per-result notifications entirely. Not permanently — we're running it as an experiment. We want to hear what users actually say when the option is gone. Do they switch to digest? Do they figure out the widget? Do they complain loud enough that we need to bring it back?
The feedback is still coming in. Some users noticed immediately. Some haven't said anything. We're listening.
What We'd Do Differently
If we were starting over, we wouldn't default to "notify on every event" just because we technically can. The question isn't "can we send a notification" — it's "does the user actually want to be interrupted right now?"
For scheduled, predictable events, the answer is usually no. Passive delivery — widget, digest, in-app badge — is almost always better than active interruption.
We'd also think harder about who our actual users are before designing the delivery mechanism. A homescreen widget is a great solution for a 25-year-old developer. It's a confusing abstraction for a 55-year-old who's never added a widget to their phone.
The most technically elegant solution is worthless if your users can't use it.
The Honest Conclusion
We don't have a neat ending to this story because we're still in the middle of it. We made a product decision, iterated on it, discovered our assumptions about users were wrong, and are now running an experiment to figure out what they actually need.
That's what building for a real community looks like. Not a clean arc from problem to solution, but an ongoing conversation between what you build and how people actually use it.
We'll write a follow-up when we know more.
Top comments (0)